# Use different AWS accounts for test and production

---

Many teams keep production in its own AWS account. Test work can't touch production resources, and permissions and billing stay separate.

Deployment.io supports this with one runner per AWS account.

## How it works

- A runner is installed in one AWS account and one region. Deployment.io creates everything it deploys in that account and region.
- An organization can have several runners: one per AWS account and region. Another account, or another region of the same account, is another runner.
- Every environment is tied to one runner when it's created. Its region comes from that runner, and the runner can't be changed afterwards.

So "test and production in different accounts" means: a runner in each account, and environments that use them.

## Steps

1. Install a runner in your test account. Sign in to the AWS console with the test account. In Deployment.io, open **Org Settings** → **Agents** → **Runners** and click **Add runner**. Choose **I have AWS Administrator access**, pick the region, and launch the CloudFormation stack. Choose a subnet and create the stack. Installation takes about 5 minutes. See [AWS Setup](/docs/runner-installation/aws-setup/) for what gets installed and what it costs.
2. Install a runner in your production account the same way. Before you click **Add runner** again, sign in to the AWS console with the production account. The stack is created in whichever account the console is signed into.
3. Check both on the **Runners** page. Each row shows its **AWS Account** and **Region**.
4. Create the test environment. Open **Resources** → **Environments** and click **Environment +**. Enter a **Name** (for example "staging"). Choose the test account's runner under **Runner**; the **Region** fills in from the runner. Set **Classification** to **Staging** (or **Development**). Click **Create Environment**. See [Creating an Environment](/docs/dashboard/creating-an-environment/).
5. Create the production environment the same way, with the production account's runner and **Classification** set to **Production**.
6. Deploy each service into each environment. A service belongs to one environment, so create it once in the test environment and once in the production environment. Each deploys into its own environment's AWS account.

## Protecting production

- An environment's classification is chosen when you create it and can't be changed later. Set it carefully.
- Coding agents connected through MCP: every tool call that targets a **Production** environment needs a human approval. Only organization owners can approve it, on the **Approvals** page in the sidebar. **Staging** and **Development** environments can be auto-approved, per MCP key. See [Available MCP tools](/docs/coding-agents/available-mcp-tools/).
- A Task can deploy its change after the pull request merges, to the static site in the environment classified **Production**. See [Deploy after merge](/docs/tasks/deploy-after-merge/).
- Share environments with teammates as **Read**, **Write** or **Admin** to control who can view, edit or delete them. See [Sharing Environments](/docs/role-based-access-controls/sharing-environments/).

## Good to know

- One runner per AWS account and region. To deploy to another region of the same account, install a runner there too.
- Each runner is its own small set of AWS resources in its account. See [AWS Setup](/docs/runner-installation/aws-setup/) for its cost.

---

Source: https://deployment.io/docs/guides/how-to-use-different-aws-accounts-for-test-and-production-environments/