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
- 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 for what gets installed and what it costs.
- 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.
- Check both on the Runners page. Each row shows its AWS Account and Region.
- 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.
- Create the production environment the same way, with the production account's runner and Classification set to Production.
- 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.
- A Task can deploy its change after the pull request merges, to the static site in the environment classified Production. See Deploy after merge.
- Share environments with teammates as Read, Write or Admin to control who can view, edit or delete them. See 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 for its cost.