> For the complete documentation index, see [llms.txt](https://docs.emseapea.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.emseapea.ai/setting-up-your-accounts/somewhere-to-deploy-apps.md).

# Somewhere to deploy apps: AWS and Azure

**Settings → Deployments** offers three clouds for your approved apps to run in. One of them works.

| Cloud                | Status                                                                                        |
| -------------------- | --------------------------------------------------------------------------------------------- |
| Cloudflare Workers   | **Working today** — see [Cloudflare](/setting-up-your-accounts/cloudflare-for-the-gateway.md) |
| AWS Lambda           | **Not built yet**                                                                             |
| Azure Container Apps | **Not built yet**                                                                             |

## Read this before you raise a ticket for AWS or Azure access

> **Emseapea cannot deploy an app to AWS or to Azure, and no credential you supply will change that.**

The gap is not permissions. Three pieces of work simply do not exist on our side:

* Nothing packages a governed app into the shape AWS Lambda expects.
* Nothing signs a request to the AWS control plane, so there is no call to make even with a role to assume.
* Nothing builds a container image, which is what Azure Container Apps runs.

The product refuses both targets before it even tries — the radio buttons are disabled, and the deploy route refuses them a second time. That refusal is deliberate and it is the honest behaviour. It also means an AWS role or an Azure service principal created for this today is an unused credential on your estate, which is a small liability and no benefit.

**Our recommendation: do not create machine credentials for deploying to AWS or Azure yet.** Come back when this page says something different.

**If you already hold AWS or Azure accounts, they are still worth having** — for storage, not for deploying. See [Somewhere to keep files and data](/setting-up-your-accounts/somewhere-to-keep-files-and-data.md), and note the honest caveats there too.

## What "Test connection" will tell you, and how much to trust it

The two clouds behave differently on this screen, and the difference is worth knowing before it misleads somebody.

**AWS never contacts AWS at all.** There is no signer, so there is nothing to send. It answers "unreachable" and says outright that this is on our side and not something to fix in your AWS account. That is accurate.

**Azure does make real calls** — it requests a token from Microsoft Entra and reads the resource group you named. So a correctly configured service principal gets a genuine green result, worded:

> Connected — this service principal can deploy container apps to this resource group.

**That sentence overstates what it proves.** It is true about your Azure account and false about Emseapea: nothing here can build the container image that would be deployed. A second badge on the same screen reads "credentials added — not usable yet", so the screen as a whole is not lying — but if somebody quotes you the green line on its own, this is the paragraph to read back to them.

## What you would create, when it becomes worth creating

Kept here so you know the shape of the ask, and so a security review can start early. None of it does anything yet.

### AWS Lambda

The console is the **IAM** section of the AWS Management Console, and what you create is a **role**, not a user and not an access key.

1. **IAM → Roles → Create role**, with a trust policy that lets Emseapea's own AWS identity assume it. Add an **external ID** if your policy requires one — a shared value that has to be presented alongside the role.
2. Give the role only what a deploy needs — creating and updating the functions Emseapea manages — rather than a broad administrative policy.
3. Copy the **role ARN**, e.g. `arn:aws:iam::000000000000:role/emseapea-deploy`, and note the region.

**You end up with:** a role ARN, a region, and optionally an external ID.

**Where it goes:** Settings → Deployments → AWS Lambda.

There is deliberately **no access-key field on that screen** — Emseapea assumes the role rather than holding a long-lived key, and anything shaped like an access key is rejected before it is saved. That part of the design is real, even though the deploy is not.

> One more thing that has never been established: Emseapea has never had an AWS identity of its own for your role to trust. So even the trust policy above has no counterparty to name today.

### Azure Container Apps

The console is [entra.microsoft.com](https://entra.microsoft.com) for the identity, and the Azure portal for the subscription and resource group.

1. **App registrations → New registration.** Name it something recognizable, choose single tenant, leave the redirect URI blank. This is an application identity — a machine, not a person.
2. **Certificates & secrets → New client secret.** Copy the **Value** immediately; Azure shows it once. Note the expiry date.
3. In the Azure portal, give that service principal a role on **the one resource group** you want apps deployed into — not the subscription.
4. Collect the **tenant ID**, **application (client) ID**, **client secret**, **subscription ID**, **resource group** and **region**.

**You end up with:** six values, one of which is a secret with an expiry date nothing in Emseapea will remind you about.

**Where it goes:** Settings → Deployments → Azure Container Apps.

If you create this today, diary the secret's expiry yourself, and expect the green "Connected" result described above to be the only thing that ever happens with it.

## Where to go next

* [Configuring deployment targets](/admin-guide/deployment-targets.md) — what the screen does with all of this.
* [Deploying through the gate](/builder-guide/deploying.md) — what a builder sees when an app is deployed.