Regions

You choose the region the engine runs in. Your content, your index and your agents stay in it. This page says what that choice pins, and, separately, where each kind of model call is served from, because the two are not always the same.

Choosing a region

Choose in LightHouse under Setup and admin → Where agents run, or with PUT /api/v1/run-targets. The stack LightHouse hands your pipeline is generated for that region. The regions offered are the ones the infrastructure’s guardrails allow:

Where it runs	Regions offered
AWS	eu-west-1 (Ireland), eu-west-2 (London), eu-central-1 (Frankfurt), us-east-1 (N. Virginia), us-west-2 (Oregon)
Azure	westeurope, northeurope, uksouth, eastus, westus2
Google Cloud	europe-west2 (London), europe-west1 (Belgium), europe-west4 (Netherlands), us-east4, us-central1
Atlantic-hosted	eu-west-1, eu-west-2, eu-central-1, us-east-1
On premises	Your own machines, wherever they are

A region outside the list is refused when you save, naming the field. See the run targets reference.

What is pinned to it

Everything the stack creates is created in your region: the engine’s compute, the gateway and its store, the index, the content reader and the handler, the secrets and the logs.

Guardrail policies for each cloud (service control policies on AWS, Azure Policy on Azure, organisation policy on Google Cloud) refuse resources outside the contract’s regions in the platform itself, so an account built without the engine, or a bug in it, still cannot create them elsewhere. They are applied at the organisation level that holds the account.

LightHouse is not in your region. It runs in AWS eu-west-1 (Ireland) for every tenant. Only operational telemetry goes there; see the rule.

The inference geography of each model path

A model call is processed where the model service runs it, which can be wider than one region. Here is each path, disclosed.

Path	Where inference runs	What holds it there
Amazon Bedrock, regional model ID	The region named	Your gateway policy’s allow list
Amazon Bedrock, EU cross-region profile (eu. model IDs)	Any EU region in AWS’s profile for that model	The eu. prefix. The router’s residency: eu rule admits only models whose residency is eu
Amazon Bedrock, US cross-region profile (us. model IDs)	Any US region in AWS’s profile	As above, us.
Amazon Bedrock, global cross-region profile (global. model IDs)	Any commercial region with capacity	Refused by the gateway in code, whatever the configuration says, and by the AWS guardrail policy
Vertex AI	The location your stack’s gateway calls	Your gateway policy and the stack’s settings. Google Cloud’s organisation policy cannot restrict where a prediction is served, so this is held by the gateway and the stack
Azure OpenAI	Your Azure OpenAI deployment’s region	The deployment you create, reachable only by the gateway’s managed identity
The Claude API, with your key	Where Anthropic processes it	Anthropic’s terms with you
Managed model access through Atlantic	Per provider, as listed on Sub-processors	Atlantic’s contract with each provider

Setting the Claude API’s own inference geography from the engine, per call: Coming

Running models on your own hardware on premises (self-hosted inference servers): Coming. On premises today, the engine calls the Claude API with your own key.

Residency in LightHouse, and in your account

There are two residency settings, and only one of them binds:

• In your account, your gateway policy’s allow list and the router’s residency rule decide which models a call may use. They are your engineers’ configuration. LightHouse cannot widen them: a portal that could widen residency would be a sovereignty breach reachable from a browser.
• In LightHouse, your residency choice (Setup and admin → Models) filters which models the model picker offers you, so you are not shown choices you cannot use.

See Inputs for how the router applies the rule on every call.