> 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/admin-guide/deployment-targets.md).

# Configuring deployment targets

**Settings → Deployments** is where you decide which cloud your organization's approved apps actually run on, and give Emseapea the account details it needs to deploy there on your behalf.

This page assumes the cloud account already exists and you have a machine credential for it. For how to create one — and for why we currently suggest **not** creating AWS or Azure credentials yet — see [Somewhere to deploy apps](/setting-up-your-accounts/somewhere-to-deploy-apps.md).

## Org default and per-app override

Approved apps deploy to your chosen default unless a specific app is pointed somewhere else — useful when one app needs to sit closer to the data it reads. Only a target you've added working credentials for is selectable.

## Adding cloud credentials

Three targets, each asking for what that cloud actually needs — never more:

**Cloudflare Workers**

| Field                 | What it is                                                           |
| --------------------- | -------------------------------------------------------------------- |
| Cloudflare account ID | Your account identifier                                              |
| API token             | Scoped to `Workers Scripts: Edit` only — not your account-wide token |

**AWS Lambda**

| Field                  | What it is                                                      |
| ---------------------- | --------------------------------------------------------------- |
| Role to assume         | An IAM role ARN, e.g. `arn:aws:iam::123456789012:role/emseapea` |
| Region                 | e.g. `eu-west-2`                                                |
| External ID (optional) | Only if your role's trust policy requires one                   |

Emseapea **assumes this role** rather than holding a long-lived key — there's deliberately no access-key field here at all; anything shaped like one is rejected before it's ever saved.

**Azure Container Apps**

| Field                   | What it is                                                            |
| ----------------------- | --------------------------------------------------------------------- |
| Tenant ID               | Your Azure AD tenant                                                  |
| Application (client) ID | From the app registration (service principal) you create for Emseapea |
| Client secret           | From that same app registration                                       |
| Subscription ID         | Which subscription to deploy into                                     |
| Resource group          | e.g. `emseapea-apps`                                                  |
| Region                  | e.g. `uksouth`                                                        |

## Test connection

Tells you exactly where you stand for each target: not configured yet, credentials present but the vendor rejects the permissions, unreachable, or genuinely working — four different situations that need different people to act on them, so they're never collapsed into one flat "failed."

## Removing a target

Blocked, and named, if a live app still depends on it — deal with that first rather than orphaning a running app's deployment.

## Honest about what this doesn't guarantee

The credential you enter is not stored the way most of Emseapea's own data is: it lives in a separate table nothing but the deploy step and "Test connection" ever reads from, never returned by any list or detail view. That's a real protection against ordinary use, but it is **not** the same guarantee as never touching Emseapea's database at all — a connector's own vendor secret does that (it's supplied fresh to your gateway and never stored here), but a deploy target's credential has to be available long after you last opened this page, so it has to be stored somewhere. It is not encrypted at rest today.

Cloudflare is the target this product has actually deployed real governed apps to. AWS and Azure give your organization a genuine place to enter your own account details, and "Test connection" is honest about what it finds — but neither has been exercised end to end against a live AWS or Azure account in this product yet. Treat "Test connection" passing as proof the credentials are valid and reachable, not as proof a full deploy will succeed.