Choose your setup

Four decisions shape a deployment. Three can be changed later. The fourth, the region, is hard to change. Each section below links to the page with the full detail.

Decision	Changeable later?
Where agents run: your cloud, your servers, or Atlantic’s	Yes. The old deployment keeps running until your own pipeline takes it down; nothing moves.
Which deployment profile: ephemeral or always-on	Yes, by changing one Terraform variable. No data moves.
Which models: and Direct or Managed	Yes, per use case, at any time.
Your region	Not easily. Your content, index and model calls stay in the region you pick. Moving region means a new deployment and re-indexing.

1. Choose where agents run

AWS

You will need: an AWS account you can run CloudFormation in, and a pipeline that can apply Terraform.

LightHouse gives you a CloudFormation bootstrap and then a Terraform stack. LightHouse does not apply anything in your account. Your own pipeline applies it, so each change is reviewed and logged with your other infrastructure changes.

• Models: Amazon Bedrock.
• Regions offered: eu-west-1, eu-west-2, eu-central-1, us-east-1, us-west-2.
• Both profiles are supported, and ephemeral saves the most here of any cloud.

Next: AWS.

Azure

You will need: an Azure subscription, and a pipeline that can apply Terraform.

Two Bicep files bootstrap it, then a Terraform stack.

• Models: Azure OpenAI.
• Regions offered: westeurope, northeurope, uksouth, eastus, westus2.
• Both profiles are supported. Ephemeral saves least here of the three clouds, because Azure’s managed PostgreSQL cannot pause when idle.

Next: Azure.

Google Cloud

You will need: a Google Cloud project, and a pipeline that can apply Terraform.

Terraform bootstraps it, then a Terraform stack.

• Models: Vertex AI.
• Regions offered: europe-west2, europe-west1, europe-west4, us-east4, us-central1.
• Both profiles are supported.

Next: Google Cloud.

Your own servers

You will need: a host that runs Docker or Podman (rootless or rootful) with Compose, and somewhere to keep secret files beside the stack.

There is no cloud bootstrap: the deployment’s key is a secret file you place on the host. Everything else is the same engine.

• Runtime: Docker, or Podman 5. Rootless Podman runs no daemon as root.
• Models: any backend the gateway supports, including a model you host.
• Region: wherever your hardware is.
• Both profiles are supported. There is no cloud bill to compare a saving against. Under Podman, the ephemeral profile uses the two Podman settings in the generated file.

Next: Your own servers.

Atlantic-hosted

You will need: nothing to run. Atlantic runs the account.

Choose this to use the engine without operating it. The account belongs to Atlantic, so the data-sovereignty position differs from the other options; read Data sovereignty before choosing it.

• Models: Amazon Bedrock.
• Regions offered: eu-west-1, eu-west-2, eu-central-1, us-east-1.
• Infrastructure is quoted as a managed service rather than compared against a cloud bill.

Next: Atlantic-hosted.

2. Choose a deployment profile

Both profiles run the same engine and the same agents. They differ in what is left running when nothing is happening.

Ephemeral

Infrastructure starts when there is work and stops when there is none.

• Choose it when agent work is bursty or scheduled: overnight ingests, business-hours triage, or anything that is idle more often than busy.
• The trade-off: the first request after a quiet spell waits while the deployment wakes. A read that needs the deployment returns 503 deployment_waking with Retry-After: 5. The portal shows “Waking your deployment…” and retries. Integrations must retry on that status.
• Estimated saving on the lines the profile changes: around 95% on AWS, 87% on Google Cloud and 72% on Azure. These are proportions; the amount depends on your region, currency and any committed-use pricing.

Always-on

Infrastructure stays up.

• Choose it when requests arrive unpredictably all day, or your users cannot accept a waking delay.
• The trade-off: you pay for capacity while it is idle.
• It is the infrastructure module’s default, so always-on applies if no profile is chosen.

Changing profile later is one Terraform variable, planned and applied by your own pipeline. No data moves: the key, the database, the file system and the secrets are kept. Resizing a database is a separate change. See Deployment profiles.

3. Choose models, and who pays the provider

A model is chosen for each use case. Setup and admin → Models only offers models available in the cloud you picked and allowed by your data-residency rule.

Direct

Calls go to your own provider account: your Amazon Bedrock, Azure OpenAI or Vertex AI, your Claude API organisation, or your OpenAI project. You pay the provider.

LightHouse records which account a call is attributed to, and does not hold a provider key. Your gateway authenticates as itself through workload identity, so no long-lived credential exists.

Managed

Calls go through Atlantic’s provider account. Atlantic bills you at the price card. The model picker shows the managed price beside the direct price, with the margin stated as a percentage.

Choose Managed to start without setting up a provider account. You can move to Direct later without changing an agent.

See Models for how a model is chosen per call, and Cost for what you are charged.

4. Choose the channels your people use

The portal, the API, MCP and the CLI read the same data. Choose per audience; most tenants use all four.

The portal (UI)For people: approvals, the run map, spend, settings. Sign-in is through your own identity provider, with MFA required.

The APIFor your systems: everything the portal shows, read-only, with a machine key scoped to one tenant. Start at Authentication.

MCPFor an assistant: read-only tools, so a person can ask about agents, runs and spend in plain words.

The CLIFor engineers: sign in by device code, read the estate, follow live runs and scaffold an agent.

Each channel has its own security page, because the controls differ. A browser session, a machine key and a delegated token are checked in different places and fail in different ways:

• Security: the portal
• Security: the API
• Security: MCP
• Security: the engine

Next steps

1. Set up the tenant. The set-up mission covers the seven steps. You can leave any of them for later.

2. Try the API and MCP. The Quickstart issues a key, reads the API and connects an assistant over MCP in about ten minutes.

3. Connect one source. One connector, read only by default, with its credential sealed to your deployment and kept in your own secrets store once your deployment can keep it. See Connect your estate.

4. Put one agent to work. Add one from the library to your deployment. See From the library and Agents.