# Deployment profiles

> Ephemeral or always-on: how the engine's infrastructure runs, and what each costs.

A **deployment profile** says how your deployment’s infrastructure runs: **always-on**, with its services warm all the time, or **ephemeral**, where they start only when something is asked of them (a scheduled job, a model call, a read) and sleep otherwise.

## The profiles

| Profile     | What runs                                                                           | Costs                                 |
| ----------- | ----------------------------------------------------------------------------------- | ------------------------------------- |
| `always_on` | Every service warm. The gateway runs at least two copies                            | The most, with no wake time           |
| `ephemeral` | Services scale to zero and start on demand. The product’s own service keeps running | Less: you pay mostly for what is used |

A third profile, `scheduled` (services awake in a set window, asleep outside it), is reserved and not built \[Coming].

What changes by cloud, for example the gateway as an AWS Lambda function or a Cloud Run service with no minimum instances, is on each cloud’s page: [AWS](/clouds/aws/#deployment-profiles), [Azure](/clouds/azure/#deployment-profiles), [Google Cloud](/clouds/google-cloud/#deployment-profiles), [on-premises](/clouds/on-premises/#deployment-profiles).

## Wakes and cold starts

A sleeping service wakes on its first request. Each component reports when it starts (with how long it took to be ready, and whether it was a cold start), an hourly heartbeat while it runs, and when it stops. LightHouse shows wake times at the median and the 95th percentile over 30 days.

While an ephemeral deployment wakes, a read that needs it answers `503 deployment_waking` with `Retry-After: 5`. LightHouse shows “Waking your deployment…” and retries. See [Errors](/api/errors/).

## Estimated savings against always-on

LightHouse estimates the saving of ephemeral against always-on from Atlantic’s versioned cost model, at list prices for one region per cloud. For a small deployment:

| Cloud (priced region)       | Always-on | Ephemeral | Estimated saving a month |
| --------------------------- | --------- | --------- | ------------------------ |
| AWS (eu-west-1)             | $329.87   | $15.09    | $314.78                  |
| Azure (westeurope)          | $247.77   | $68.15    | $179.62                  |
| Google Cloud (europe-west2) | $293.74   | $39.64    | $254.10                  |

Only the lines that differ between the profiles are counted; what both share (the load balancer, logs, keys) is left out of both. Another region is priced at its cloud’s priced region, and LightHouse says so. On-premises has no cloud bill to compare. Once your deployment reports its own infrastructure cost, the saving is computed from that. Every figure is **estimated**. See [How a saving is calculated](/cost/savings/).

## Changing profile

The profile is a setting in your deployment’s Terraform (`deployment_profile`), applied by your own pipeline. LightHouse can record a request to switch (**Settings → Deployments**, or `POST /api/v1/deployments/{deployment}/profile-requests` as a `client_admin`), and shows it applied once your deployment reports the new profile. LightHouse never applies it for you.

## In the API

- `GET /api/v1/deployments/profiles`: each deployment’s profile, wake times, uptime, infrastructure cost and estimated saving.
- See the [Deployments reference](/api/reference/deployments/), and the MCP tools [`deployment_profiles`](/mcp/tools/deployment-profiles/) and [`deployment_wakes`](/mcp/tools/deployment-wakes/).

Source: https://docs.atlanticagenticlabs.com/concepts/deployment-profiles/