# Choose your setup > The four decisions that shape a LightHouse deployment — where agents run, which profile, which models, and which channel your people use — and what each one commits you to. 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](/clouds/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](/clouds/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](/clouds/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](/clouds/on-premises/). **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](/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](/clouds/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](/concepts/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](/router/) for how a model is chosen per call, and [Cost](/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)](/security/ui/)For people: approvals, the run map, spend, settings. Sign-in is through your own identity provider, with MFA required. [The API](/api/)For your systems: everything the portal shows, read-only, with a machine key scoped to one tenant. Start at Authentication. [MCP](/mcp/)For an assistant: read-only tools, so a person can ask about agents, runs and spend in plain words. [The CLI](/cli/)For 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/ui/) - [Security: the API](/security/api/) - [Security: MCP](/security/mcp/) - [Security: the engine](/security/engine/) ## Next steps 1. **Set up the tenant.** [The set-up mission](/start/setup/) covers the seven steps. You can leave any of them for later. 2. **Try the API and MCP.** The [Quickstart](/start/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](/connect/). 4. **Put one agent to work.** Add one from the library to your deployment. See [From the library](/build/library/) and [Agents](/concepts/agents/). Source: https://docs.atlanticagenticlabs.com/start/choose/