Residency by cloud

The rule is the same everywhere: your content stays where the engine runs, and only operational telemetry reaches LightHouse. What differs between clouds is which model services are available privately, and what each platform can enforce on its own. The setup for each cloud is under Clouds.

AWS

• Where it runs: your AWS account, in the region you choose. The engine runs in a private network, and only its gateway may call a model.
• Models: Amazon Bedrock in your own account, by an assumed role, or the Claude API with your own key by workload identity. Bedrock’s eu. and us. cross-region profiles keep inference inside that geography; global. profiles are refused by the gateway.
• Platform enforcement: a service control policy refuses requests to regions outside the contract’s list, and refuses global inference profiles again in IAM, so the rule holds even if code is wrong.
• Your keys: your content and secrets are encrypted under keys in your account.

Azure

• Where it runs: your Azure subscription, in the region you choose.
• Models: Azure OpenAI in your own subscription, reachable by the gateway’s managed identity alone and with no public endpoint, or the Claude API with your own key.
• Platform enforcement: Azure Policy definitions, assigned at the management group that holds your subscription, so an Owner of the subscription cannot remove them. Every rule denies; none only audits.

Google Cloud

• Where it runs: your Google Cloud project, in the region you choose.
• Models: Vertex AI in your own project, reachable by the gateway’s service account alone, or the Claude API with your own key.
• Platform enforcement: organisation policy, set on the folder that holds your project, refuses resources outside the contract’s regions. Organisation policy has no rule for where a Vertex AI prediction is served, so the named locations are held by the gateway and the stack’s own validation.

On premises

• Where it runs: your own machines, under Docker Compose, wherever they are.
• Models: the Claude API with your own key. On your own machines there is no private cloud model service to reach.
• Network: nothing of Atlantic’s listens on your network. The content reader and the command handler dial out to one Atlantic hostname, so the engine works behind NAT, a proxy or a firewall that admits no inbound connection.

Self-hosted models on your own hardware: Coming. Fully air-gapped operation, with no connection to LightHouse at all: Coming

Atlantic-hosted

• What it is: the same engine, run for you in a dedicated account in Atlantic’s AWS organisation. It holds your data and no other client’s.
• Where: the region you choose, from eu-west-1, eu-west-2, eu-central-1 and us-east-1.
• Models: Amazon Bedrock in that account.
• Who manages it: Atlantic, who also bills for it. The account is requested in LightHouse, approved and provisioned by a person; LightHouse cannot create one on its own.
• What changes for sovereignty: your content is in an account Atlantic operates rather than one you own. The rule about LightHouse does not change: LightHouse still receives operational telemetry only, and still reads content in place. What changes is who administers the account the content is in, which your agreement with Atlantic sets out.

Moving from Atlantic-hosted to your own cloud later: see Atlantic-hosted.

What is the same on every cloud

• The engine, its gateway and its controls.
• The telemetry contract: counts and timings, never content.
• Content read in place, signed by Atlantic, logged in your account, and cut off by you alone.
• The guardrail on global routing, in code.
• LightHouse never applies infrastructure in your account. It hands your pipeline a stack pinned to a release tag; your pipeline applies it as a reviewed change.