#
Coding agents work well in parallel. One can write the API while others handle messaging and the database. Problems begin when they share the same cloud environment. They may create resources with the same name or overwrite state that another agent needs. A fast parallel build can quickly turn into a mess.
We saw this while helping a team run several agents against AWS. The agents wrote solid infrastructure code, but they all deployed to a single shared LocalStack instance and interfered with one another. The team needed a fresh, isolated cloud environment for every agent.
Ephemeral Instances provide that isolation. In this post, I use Claude Code and the LocalStack MCP server to build a small AWS application as three separate stacks. Each agent works in its own Git worktree and deploys to its own ephemeral instance. They run simultaneously without conflicts, and a final agent connects the stacks and tests the complete application.
#
An ephemeral instance is a full LocalStack environment that runs in the cloud instead of on your laptop. Each instance has a unique endpoint, such as https://ls-<id>.sandbox.localstack.cloud. You deploy to it and delete it when you are done.
The LocalStack MCP server lets agents manage these instances with four tools:
localstack-ephemeral-instancescreates, lists, checks, and deletes cloud instances.localstack-deployerdeploys infrastructure built with Terraform, CDK, SAM, or CloudFormation.localstack-aws-clientruns AWS CLI commands to verify deployed resources.localstack-managementmanages the local LocalStack container.
Two layers of isolation make parallel work safe. Git worktrees give each agent a separate copy of the repository, preventing file conflicts. Ephemeral instances give each agent a separate cloud environment, preventing resource conflicts. Each agent connects its MCP server to its own instance, so its deployments and checks stay isolated.
The example application processes webhook events. It is split into three stacks:
- data : a DynamoDB table that stores events.
- messaging : an SQS queue and a Lambda that writes queued events to the table.
- api : an API Gateway endpoint and a Lambda that sends webhooks to the queue.
The stacks find each other through SSM Parameter Store. This allows three agents to build and deploy them separately, then connect them at the end.
#
- Docker installed and running.
- A valid
LOCALSTACK_AUTH_TOKENfrom aLocalStack account , on a plan or trial that includes Ephemeral Instances.
- [Node.js 22+](https://nodejs.org/) to run the MCP server with`npx` .
- [Terraform](https://developer.hashicorp.com/terraform/install) for the infrastructure code.
- [Claude Code](https://www.claude.com/product/claude-code) or another MCP client.
#
Run the setup wizard and point it at your MCP client:
The wizard reads LOCALSTACK_AUTH_TOKEN and finds your installed MCP clients. It also checks Docker, although Ephemeral Instances do not require it. Choose the clients to configure, then restart your agent to use the LocalStack tools.
#
Use git worktree to give each stack its own branch and working directory. This prevents agents from editing the same files.
Each worktree includes a short contract that lists its resource names and SSM keys. This contract gives the agents all the shared information they need. They handle everything else independently.
#
Rather than start three agents by hand, I gave the whole job to one orchestrator agent running claude-opus-5 and pointed it at a single spec file. The spec describes the three stacks and the shared contract between them, and it tells the agent to do the work through the LocalStack MCP server. You can read or copy the full file here: webhook-event-processor.md.
The prompt that kicks it off is short:
The orchestrator read the spec and started three sub-agents, one per stack, each in its own worktree:
Each sub-agent created its own ephemeral instance, deployed its stack, and tested it. Here is a shortened view of the messaging sub-agent’s work:
The sub-agents worked in parallel on separate endpoints. The data sub-agent wrote an item to its table and read it back. The API sub-agent sent a request and received a 202 response. The messaging sub-agent sent a message to its queue and confirmed that the worker processed it. Because each instance was isolated, no sub-agent saw or changed another’s resources.
Each stack also worked without its dependencies. The worker had no table yet, and the API had no queue. This was intentional, letting the sub-agents build the stacks separately before connecting them.
#
Isolation becomes especially useful when something goes wrong. One agent deployed a Lambda with an incorrect import. When it tested the function, the invocation failed:
The function failed on every call, leaving the sandbox in a broken state. Instead of cleaning up the environment, the agent deleted the instance and created a new one:
A new instance cannot fix a code bug, so the agent also corrected the import:
The agent then deployed to the new instance and tested the function again:
The agent recovered by replacing its environment and fixing the code. The other agents were not affected because they had their own instances. With one shared instance, deleting the environment would have stopped everyone.
#
After merging the three stacks, the orchestrator started another agent on a new instance. The agent deployed the complete application and sent a real event through it.
Both events passed through the API Lambda, the queue, and the worker before reaching DynamoDB. The three independently built stacks worked together on the first try because the agents followed the same contract.
After the tests passed, the agents deleted their instances. A final list confirmed that no instances or resources were still running.
#
The agents used claude-opus-5 and cost about $4 in total.
| Phase | What happened | Cost | Time |
|---|---|---|---|
| Build three stacks | Three agents built in parallel | $2.14 | ~4 min |
| Recover from failure | Replace the instance and fix the code | $0.78 | ~3 min |
| Test the application | Deploy all stacks and send an event | $1.21 | 5 min |
The instances ran for about 25 minutes in total, including the failed deployment and a few retries. LocalStack bills by the ephemeral minute, so a clean run would use even less of the monthly allowance.
An instance only needs to stay active long enough to deploy and test its stack. Set a short lifetime and delete it as soon as the test passes. This keeps costs low while giving every agent an isolated cloud environment.
#
Parallel agents work best in separate environments. Git worktrees prevent code conflicts, ephemeral instances isolate cloud resources, and a shared contract connects the pieces. Together, these tools let agents build different parts of an application at the same time and recover from failures without affecting one another.
The LocalStack MCP server lets each agent create an instance, deploy and test its work, then delete the instance when finished. This approach makes it simple and affordable to run several agents in parallel.
#
- [Ephemeral Instances](https://docs.localstack.cloud/aws/developer-tools/cloud-sandbox/ephemeral-instances/) : temporary LocalStack instances in the cloud.
- [LocalStack MCP server](https://github.com/localstack/localstack-mcp-server) : the server, its tools, and setup.
- [Git worktrees](https://git-scm.com/docs/git-worktree) : multiple working trees from one repository.
- [LocalStack Slack Community](https://localstack.cloud/slack) : join for questions and discussion.