Many teams believe that simply placing a server in a geographic zone guarantees that every line of code they run will stay within that zone, but data residency rules are often ignored. In practice, shared SSH keys, ad‑hoc scripts, and unmanaged containers routinely move data across borders without any visibility.
In a typical legacy workflow, an engineer checks a repository, SSHs into a bastion host, and runs a deployment script that pulls secrets from a central vault. The same private key may be used by dozens of users, and the bastion itself often has outbound internet access. When the script contacts a third‑party API or writes logs to a cloud bucket, the data can cross regional boundaries instantly. No audit trail records where the code executed, what data was read, or whether the operation complied with residency requirements. The result is a blind spot that regulators and auditors flag as non‑compliant.
What organizations really need is a way to enforce data residency at the moment code is invoked, not after the fact. Adding an identity provider or tightening IAM policies limits who can start a session, but it does not stop the session from reaching a target that resides outside the approved region. The request still travels directly to the compute node, bypassing any residency guard, and there is no built‑in mechanism to block or log cross‑border data movement.
Why data residency matters for code execution
Data residency regulations, such as GDPR, CCPA, and local sovereign cloud mandates, require that personal or regulated data never leave a defined geographic boundary. When code runs, it may read databases, write logs, or stream files. If the execution environment sits in a different jurisdiction, the data implicitly migrates, creating compliance risk. Moreover, modern workloads often span multiple services; a single command can trigger a chain of network calls that silently cross borders. Without a central enforcement point, each service would need its own residency checks, leading to inconsistent policies and gaps.
Enforcing residency at the network edge solves two problems at once. First, it guarantees that any request that would cause data to leave the approved zone is rejected before it reaches the target. Second, it provides a single source of truth for auditors: a complete, immutable record of every command, the originating identity, and the outcome of the residency check.
Placing the residency guard in the data path
hoop.dev acts as a Layer 7 gateway that sits between the identity layer and the compute resources that actually run the code. The gateway verifies the user’s OIDC or SAML token, extracts group membership, and then applies a residency policy before forwarding the request to the target server. Because the policy enforcement lives in the data path, hoop.dev can block any operation that would violate the defined geographic constraints.
When a developer initiates a code execution request, hoop.dev inspects the protocol, determines the target region of the resource, and compares it to the organization’s residency rules. If the request complies, the gateway forwards the traffic to the agent that runs inside the customer network. If the request would cross a forbidden border, hoop.dev terminates the connection and returns a clear denial message.
Beyond blocking, hoop.dev records each session, captures the full command stream, and masks any sensitive fields that appear in responses. These enforcement outcomes exist only because hoop.dev sits in the data path; the underlying compute node never sees the raw credential or the unmasked data. The recorded session can be replayed for forensic analysis, and the masked logs satisfy audit requirements without exposing regulated information. hoop.dev provides a complete, immutable record of every command, the originating identity, and the outcome of the residency check.
Because the gateway is deployed as a container or Kubernetes pod, it can be placed in any region where the organization operates. The same policy engine governs all supported connection types, SSH, database clients, Kubernetes exec, and HTTP APIs, so the residency guard is uniformly applied across the entire runtime surface.
To get started, follow the getting‑started guide and review the learn section for deeper coverage of policy definitions and session replay. The open‑source repository on GitHub provides the full implementation details and a community for extending the residency checks to custom workloads.
Explore the open‑source code on GitHub to see how the gateway integrates with your identity provider and how you can tailor residency rules to your regulatory landscape.
FAQ
- Does hoop.dev move data between regions? No. The gateway only forwards traffic that complies with the configured residency policy; disallowed traffic is blocked at the edge.
- Can I use existing IAM roles with hoop.dev? Yes. The gateway consumes the identity token from your OIDC or SAML provider and applies residency checks before any role‑based permission is evaluated.
- How are audit logs stored? hoop.dev records each session and retains the logs for audit, masking regulated fields.
