Give Every AI Agent Its Own Ephemeral Instance

Introduction

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.

How ephemeral instances work

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-instances creates, lists, checks, and deletes cloud instances.
• localstack-deployer deploys infrastructure built with Terraform, CDK, SAM, or CloudFormation.
• localstack-aws-client runs AWS CLI commands to verify deployed resources.
• localstack-management manages 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.

Prerequisites

• Docker installed and running.
• A valid LOCALSTACK_AUTH_TOKEN from a LocalStack account, on a plan or trial that includes Ephemeral Instances.
• Node.js 22+ to run the MCP server with npx.
• Terraform for the infrastructure code.
• Claude Code or another MCP client.

Step 1: Set up the MCP server

Run the setup wizard and point it at your MCP client:

npx -y @localstack/localstack-mcp-server init

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.

Step 2: Create one worktree for each stack

Use git worktree to give each stack its own branch and working directory. This prevents agents from editing the same files.

git worktree add -b stack/data      ../wt-data      main
git worktree add -b stack/messaging ../wt-messaging main
git worktree add -b stack/api       ../wt-api       main

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.

Step 3: Build the stacks in parallel

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:

Read the spec at specs/webhook-event-processor.md and build it. Start a separate
sub-agent for each stack, give each one its own ephemeral instance, and have it
deploy and verify its stack through the LocalStack MCP server.

The orchestrator read the spec and started three sub-agents, one per stack, each in its own worktree:

● Task(sub-agent: data stack)        ⎿ started
● Task(sub-agent: messaging stack)   ⎿ started
● Task(sub-agent: api stack)         ⎿ started

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:

● localstack-ephemeral-instances(action: "create", name: "messaging-box", lifetime: 20)
  ⎿ running   https://ls-63970o5tv1822.sandbox.localstack.cloud

● localstack-deployer(action: "deploy", projectType: "terraform", directory: "stacks/messaging")
  ⎿ Apply complete! Resources: 7 added, 0 changed, 0 destroyed.
     webhook-events-queue, webhook-events-dlq, webhook-worker + event source mapping

● Bash(aws --endpoint-url=https://ls-63970o5tv1822... sqs send-message ...)
  ⎿ MessageId: 0dce64ef-...

● localstack-ephemeral-instances(action: "logs", name: "messaging-box")
  ⎿ webhook-worker processed message id=smoke-1

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.

Step 4: Replace a broken instance

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:

● localstack-deployer(action: "deploy", projectType: "terraform", directory: "stacks/notify")
  ⎿ Apply complete! Resources: 2 added

● Bash(aws --endpoint-url=... lambda invoke --function-name webhook-notifier ...)
  ⎿ "FunctionError": "Unhandled"
     { "errorType": "Runtime.ImportModuleError",
       "errorMessage": "Unable to import module 'notifier': No module named 'boto4'" }

● localstack-ephemeral-instances(action: "logs", name: "recovery-box")
  ⎿ [ERROR] Runtime.ImportModuleError: Unable to import module 'notifier': No module named 'boto4'

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:

● localstack-ephemeral-instances(action: "delete", name: "recovery-box")
  ⎿ Successfully deleted instance: recovery-box

● localstack-ephemeral-instances(action: "create", name: "recovery-box2", lifetime: 20)
  ⎿ running   https://ls-1a0f8vrvpaa4k.sandbox.localstack.cloud

A new instance cannot fix a code bug, so the agent also corrected the import:

import boto4
import boto3

The agent then deployed to the new instance and tested the function again:

● localstack-deployer(action: "deploy", projectType: "terraform", directory: "stacks/notify")
  ⎿ Apply complete! Resources: 2 added

● Bash(aws --endpoint-url=https://ls-1a0f8vrvpaa4k... lambda invoke ...)
  ⎿ StatusCode: 200   { "ok": true }

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.

Step 5: Connect and test the stacks

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.

● localstack-deployer(deploy stacks/data)       ⎿ Apply complete! Resources: 4 added
● localstack-deployer(deploy stacks/messaging)  ⎿ Apply complete! Resources: 7 added
● localstack-deployer(deploy stacks/api)        ⎿ Apply complete! Resources: 11 added

● Bash(curl -X POST .../local/events -d '{"id":"evt-order-001","type":"order.created"}')
  ⎿ 202  { "id": "evt-order-001", "queued": true }

● Bash(aws --endpoint-url=... dynamodb scan --table-name webhook-events --select COUNT)
  ⎿ { "Count": 2 }

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.

What it cost

The agents used claude-opus-5 and cost about $4 in total.

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.

Conclusion

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.

Learn More

• Ephemeral Instances: temporary LocalStack instances in the cloud.
• LocalStack MCP server: the server, its tools, and setup.
• Git worktrees: multiple working trees from one repository.
• LocalStack Slack Community: join for questions and discussion.