Best Local Development Setup for AI Coding Agents in 2026
How to run real Postgres, queues and buckets on the machine where Claude Code, Cursor or Codex works, so the agent can test its own changes, comparing Encore, Docker Compose, LocalStack, Testcontainers and cloud emulators.
A coding agent depends on the checks it can run, and Anthropic's guidance for Claude Code is to give the agent a check it can run, because without one the agent stops when the work looks done.
For a backend, the check that matters is the app running against the database, queue and bucket it uses, since unit tests with mocks pass when the code calls an interface the way the test expects, and still miss a migration that runs in the wrong order or a subscriber that never receives the message.
A local setup for agents has to start those services with one command, start the same ones every time, and keep working when the agent adds a new one in the middle of a task.
What to look for:
- One command that starts the app and its services, which the agent can find in a rules file.
- Real services, such as an actual Postgres, rather than in-memory fakes.
- A local definition that comes from the same source as production, so a new resource does not need two edits.
- Isolation between parallel agent sessions, since Claude Code can run parallel sessions, each in its own worktree.
Local setups for AI coding agents at a glance
Compare what each setup gives an agent
Encore: local infrastructure from the application code
Encore combines an open source SDK, in which databases, Pub/Sub topics, buckets, cron jobs and secrets are declared in TypeScript or Go application code, with a platform that provisions the same declarations in your own AWS or GCP account. Because the infrastructure is read from the code, the local environment is too: encore run starts Postgres locally, applies the migrations, runs Pub/Sub and object storage, and starts every service, with no YAML to keep in step with production.
When an agent adds receipt storage to an orders service, the bucket is part of the change, and the next encore run has it:
import { api } from "encore.dev/api";
import { Bucket } from "encore.dev/storage/objects";
// Local object storage with encore run, S3 or GCS when deployed.
export const receipts = new Bucket("receipts", { versioned: false });
export const storeReceipt = api(
{ expose: true, method: "POST", path: "/orders/:id/receipt" },
async ({ id, body }: { id: string; body: string }): Promise<void> => {
await receipts.upload(`${id}.txt`, Buffer.from(body));
},
);
encore test runs the test suite against the same local infrastructure, as described in the testing docs, so the check the agent runs is a real one. The AI integration generates CLAUDE.md, Cursor rules or AGENTS.md with these commands and connects a local MCP server, through which the agent can call the endpoint, query the local database, list objects in the bucket and read the trace of the request. The same declarations run in a preview environment hosted by Encore for each pull request, and become S3 and RDS in production, provisioned in your AWS account by Encore's IAM role rather than by the agent.
Key features
- One command starts all services and the infrastructure they declare.
- Adding a database, topic or bucket is one declaration, with no second file to edit.
- Local traces show every API call, query and published message.
- The local MCP server lets the agent inspect what it just ran.
encore run. The same bucket declaration is used in preview environments and production.Good to know
Local infrastructure covers what the app declares through the SDK, so a third-party API the app calls still needs a sandbox key or a stub. TypeScript and Go are supported today, and Python and Rust are in beta.
Run in your terminal to get started locally.
Docker Compose: the general-purpose local stack
Docker ComposeDocker Compose starts a set of containers from one YAML file, and most backend repos already have one. An agent can run docker compose up -d, read the connection settings from the file and run integration tests against a real Postgres.
services:
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: postgres
ports:
- "5432:5432"
Good to know
The Compose file is a second definition of the infrastructure. When the agent adds a queue, it has to add a container, environment variables for the app and the production resource in Terraform, and a mismatch between them shows up only after deploy. Fixed host ports also collide when two agent sessions run at once. See replacing Docker Compose and Terraform for how teams consolidate the two.
LocalStack: AWS APIs on a laptop
LocalStackLocalStack emulates S3, SQS, SNS, Lambda and many other AWS services behind one local endpoint, so code that uses the AWS SDK can run without an account. It is usually added as a service in the Compose file, and resources are created by an init script or by running Terraform against the emulator.
Good to know
LocalStack gives the agent a realistic AWS surface, though the resources still have to be created in two places. The LocalStack alternatives guide compares other emulators.
Testcontainers: containers from test code
TestcontainersTestcontainers starts a fresh container for each test run from inside the test code, with random ports, which avoids the port collisions that hit parallel agent sessions using a shared Compose stack.
import sqlalchemy
from testcontainers.postgres import PostgresContainer
def test_select_one():
with PostgresContainer("postgres:16") as pg:
engine = sqlalchemy.create_engine(pg.get_connection_url())
with engine.connect() as conn:
assert conn.execute(sqlalchemy.text("select 1")).scalar() == 1
Good to know
Testcontainers covers tests, not running the app for manual checks, and every service the app uses needs its own setup code that mirrors production config by hand.
Cloud emulators: single-service fidelity
Cloud emulatorsCloud vendors ship emulators for individual services, such as Google's Pub/Sub emulator, which the client libraries connect to through an environment variable. They are accurate for the one service they cover and leave the rest of the stack to Compose or Testcontainers.
Good to know
Emulators fill specific gaps, and an agent working across several services needs the startup commands and environment variables for each one written into its rules file.
How to choose
- Encore when agents add infrastructure as part of features and should test it locally with one command, using the same definition as production.
- Docker Compose for a general local stack next to production IaC kept elsewhere.
- LocalStack when the app calls many AWS APIs directly.
- Testcontainers for isolated integration tests, including parallel agent runs.
- Cloud emulators for a single managed service that needs a local stand-in.
For why mocks are not enough and how to isolate agent sessions, see how to give AI coding agents real infrastructure.
Related guides
Frequently asked questions
What is the best local development setup for AI coding agents?
One where a single command starts the app with the real services it uses, defined by the same code that defines production, so an agent can add a table or a queue and test it right away. Encore does this: databases, Pub/Sub topics and buckets are declared in TypeScript or Go, and encore run starts Postgres, Pub/Sub and object storage locally. Docker Compose with LocalStack gives similar local services, but the local definition is a separate file from production and has to be kept in sync by hand.
How do I let an AI coding agent test against a real database?
Run the database locally and give the agent one command that starts it together with the app. With Encore, the agent declares the database in code and runs encore run, which starts Postgres locally and applies the migrations, and encore test runs the tests against it. With Docker Compose or Testcontainers, write the startup command and the connection settings into CLAUDE.md or AGENTS.md so the agent uses them every time.
Is LocalStack enough for AI agents working on AWS apps?
LocalStack emulates S3, SQS, SNS and many other AWS APIs, which lets an agent run integration tests without an AWS account. The production resources are still defined somewhere else, usually Terraform, so every new queue has to be added to the LocalStack setup and the production config separately, and nothing checks that the two match.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.