Development Workflow

Declare once, then run and validate the same application at every stage

An Encore change follows one path from a developer's laptop to production: declare what the application needs, run it locally, test it in isolation, review it in a preview environment, and deploy it.

The resource declarations do not change between those stages. A database declaration can become Postgres in Docker locally, an isolated test database during encore test, and RDS or Cloud SQL in production. Each environment supplies a different implementation of the same logical resource.

Declare what the application needs

Encore's infrastructure primitives are SDK types for common backend resources: SQL databases, Pub/Sub, object storage, caches, cron jobs, and secrets. You declare them in the application code that uses them. Services and APIs are defined in code as well.

These declarations describe the application's logical requirements, not a particular cloud setup. A database declaration gives the resource a name and a migrations directory; it does not choose an instance size or database engine. Those physical properties belong to the environment's infrastructure configuration.

Encore uses static analysis to connect each declaration with the services that use it. The resulting application model drives local infrastructure, validation, service discovery, tracing, IAM, and cloud provisioning.

See the Encore.ts and Encore.go overviews for the complete set of primitives and code examples. Infrastructure on AWS and GCP shows what each primitive becomes in every environment.

Run locally

encore run starts the application and the local infrastructure its declarations require. That includes Postgres in Docker, an in-memory Pub/Sub broker and cache, and object storage on the local filesystem. There is no separate Docker Compose file or emulator configuration to keep in sync.

It also starts the local development dashboard, where you can call APIs and inspect the application's services, databases, logs, and distributed traces.

Cron jobs are not triggered automatically in local or preview environments. You can invoke their endpoints from the dashboard.

When several developers or coding agents work on the same application, infrastructure namespaces isolate their local state. Each namespace has its own databases and other resources, and switching back restores the state you left behind:

encore namespace switch --create pr:123

Test in isolation

encore test starts infrastructure in test mode, then hands control to Vitest or Jest for TypeScript, or go test for Go. Each run gets isolated databases tuned for test speed, and object storage runs in memory.

Tests can exercise database queries, Pub/Sub handlers, and calls between services without separate test infrastructure. See automated testing for TypeScript or Go.

Review in a preview environment

For applications connected to GitHub, Encore can create a preview environment for each pull request. It deploys the proposed code with the same resource declarations as production, giving the change its own URL, infrastructure, logs, and traces.

Preview environments run on Encore-managed infrastructure by default. Enterprise teams can instead host them in their own cloud. You can also branch a database from a seed environment when a preview needs representative data.

This is the first stage that exercises the change against cloud infrastructure, while keeping it isolated from production and other pull requests.

Deploy to production

Deploying reads the same application model that was validated locally and in preview. Encore provisions the matching resources in your AWS or GCP account and deploys the application services that use them. Adding a declaration adds the corresponding cloud resource on the next deploy.

Environment-specific settings such as compute, capacity, networking, backups, and database engines remain outside the application code. You manage them through Encore while retaining access to the resources in your cloud provider's console.

Because the application model records resource usage and service calls, Encore can derive least-privilege IAM policies for the deployed application.

Why the loop works well for coding agents

Coding agents are most useful when they can check their own work. Encore gives an agent feedback at every stage:

  1. The compiler reports invalid declarations and resource usage.
  2. encore run provides the application and its infrastructure for local inspection.
  3. encore test runs the change against isolated test infrastructure.
  4. A preview environment validates it against cloud services before merge.
  5. Production uses the declarations already exercised in the earlier stages.

AI Integration covers the rules and MCP server that give an agent access to services, schemas, and traces. AI infrastructure provisioning covers the controls on infrastructure changes.

Where to go next