{"slug": "give-every-ai-agent-its-own-ephemeral-instance", "title": "Give Every AI Agent Its Own Ephemeral Instance", "summary": "LocalStack published a walkthrough showing how to run multiple coding agents in parallel by giving each its own ephemeral LocalStack cloud instance and Git worktree, using Claude Code and the LocalStack MCP server. In the example, three agents build separate data (DynamoDB), messaging (SQS plus Lambda) and api (API Gateway plus Lambda) stacks that connect through SSM Parameter Store, avoiding the resource-name collisions and overwritten state that occurred when a team ran several agents against a single shared LocalStack instance. The LocalStack MCP server exposes four tools — localstack-ephemeral-instances, localstack-deployer, localstack-aws-client and localstack-management — and setup requires Docker, a LOCALSTACK_AUTH_TOKEN on a plan or trial that includes Ephemeral Instances, Node.js 22+ and Terraform.", "body_md": "## \n\nCoding 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.\n\nWe 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.\n\n[Ephemeral Instances](https://docs.localstack.cloud/aws/developer-tools/cloud-sandbox/ephemeral-instances/) provide that isolation. In this post, I use [Claude Code](https://www.claude.com/product/claude-code) and the [LocalStack MCP server](https://github.com/localstack/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.\n\n## \n\nAn 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.\n\nThe LocalStack MCP server lets agents manage these instances with four tools:\n\n- `localstack-ephemeral-instances` creates, lists, checks, and deletes cloud instances.\n- `localstack-deployer` deploys infrastructure built with Terraform, CDK, SAM, or CloudFormation.\n- `localstack-aws-client` runs AWS CLI commands to verify deployed resources.\n- `localstack-management` manages the local LocalStack container.\n\nTwo 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.\n\nThe example application processes webhook events. It is split into three stacks:\n\n- **data** : a DynamoDB table that stores events.\n- **messaging** : an SQS queue and a Lambda that writes queued events to the table.\n- **api** : an API Gateway endpoint and a Lambda that sends webhooks to the queue.\n\nThe stacks find each other through SSM Parameter Store. This allows three agents to build and deploy them separately, then connect them at the end.\n\n## \n\n- [Docker](https://docs.docker.com/get-docker/) installed and running.\n- A valid `LOCALSTACK_AUTH_TOKEN` from a[LocalStack account](https://app.localstack.cloud/sign-up) , on a plan or trial that includes Ephemeral Instances.\n- [Node.js 22+](https://nodejs.org/) to run the MCP server with`npx` .\n- [Terraform](https://developer.hashicorp.com/terraform/install) for the infrastructure code.\n- [Claude Code](https://www.claude.com/product/claude-code) or another MCP client.\n\n## \n\nRun the setup wizard and point it at your MCP client:\n\nThe 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.\n\n## \n\nUse `git worktree` to give each stack its own branch and working directory. This prevents agents from editing the same files.\n\nEach 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.\n\n## \n\nRather 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](https://blog.localstack.cloud/specs/webhook-event-processor.md).\n\nThe prompt that kicks it off is short:\n\nThe orchestrator read the spec and started three sub-agents, one per stack, each in its own worktree:\n\nEach 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:\n\nThe 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.\n\nEach 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.\n\n## \n\nIsolation becomes especially useful when something goes wrong. One agent deployed a Lambda with an incorrect import. When it tested the function, the invocation failed:\n\nThe 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:\n\nA new instance cannot fix a code bug, so the agent also corrected the import:\n\nThe agent then deployed to the new instance and tested the function again:\n\nThe 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.\n\n## \n\nAfter 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.\n\nBoth 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.\n\nAfter the tests passed, the agents deleted their instances. A final `list` confirmed that no instances or resources were still running.\n\n## \n\nThe agents used `claude-opus-5` and cost about **$4 in total**.\n\n| Phase | What happened | Cost | Time | \n|---|---|---|---|\n| Build three stacks | Three agents built in parallel | $2.14 | ~4 min | \n| Recover from failure | Replace the instance and fix the code | $0.78 | ~3 min | \n| Test the application | Deploy all stacks and send an event | $1.21 | 5 min | \n\nThe 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.\n\nAn 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.\n\n## \n\nParallel 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.\n\nThe 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.\n\n## \n\n- [Ephemeral Instances](https://docs.localstack.cloud/aws/developer-tools/cloud-sandbox/ephemeral-instances/) : temporary LocalStack instances in the cloud.\n- [LocalStack MCP server](https://github.com/localstack/localstack-mcp-server) : the server, its tools, and setup.\n- [Git worktrees](https://git-scm.com/docs/git-worktree) : multiple working trees from one repository.\n- [LocalStack Slack Community](https://localstack.cloud/slack) : join for questions and discussion.", "url": "https://wpnews.pro/news/give-every-ai-agent-its-own-ephemeral-instance", "canonical_source": "https://blog.localstack.cloud/give-every-ai-agent-its-own-ephemeral-instance/", "published_at": "2026-10-27 00:00:00+00:00", "updated_at": "2026-10-27 14:43:53.817443+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["LocalStack", "Claude Code", "LocalStack MCP server", "AWS", "DynamoDB", "Amazon SQS", "API Gateway", "Terraform"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/give-every-ai-agent-its-own-ephemeral-instance", "markdown": "https://wpnews.pro/news/give-every-ai-agent-its-own-ephemeral-instance.md", "text": "https://wpnews.pro/news/give-every-ai-agent-its-own-ephemeral-instance.txt", "jsonld": "https://wpnews.pro/news/give-every-ai-agent-its-own-ephemeral-instance.jsonld"}}