Encore
Backend framework and infra SDK that turns declared resources into real local and cloud infrastructure
Repository Health
Technical Analysis
Encore is a TypeScript and Go backend framework and infrastructure SDK that lets you declare the resources your application needs (databases, Pub/Sub topics, object storage buckets, caches, cron jobs, secrets) directly inside your application code. Running encore run spins up a fully working local environment with real Postgres, real Pub/Sub semantics, type-safe service-to-service calls, and a local dashboard with distributed tracing - no Docker Compose files or manually wired mocks required.
On deploy, the same declared resources map onto real cloud infrastructure in your own AWS or GCP account: SQL Database becomes RDS or Cloud SQL, Pub/Sub becomes SNS+SQS or Cloud Pub/Sub, object storage becomes S3 or GCS. The open-source SDK, compiler, parser, and CLI are what you clone from this repo; Encore Cloud is a separate optional managed platform for provisioning and per-PR preview environments, but the framework itself works standalone with any IaC tool.
What You Get
- A TypeScript (and Go) SDK for declaring SQL databases, Pub/Sub topics and subscriptions, object storage buckets, cache clusters, cron jobs, and secrets directly in application code
encore runfor a fully local environment with real Postgres, real Pub/Sub semantics, type-safe service-to-service calls, and a local dashboard at localhost:9400 with distributed tracing- A static analysis compiler/parser (Go + Rust) that reads your declared resources and application graph, then provisions the matching managed service in AWS or GCP on deploy (RDS/Cloud SQL, SNS+SQS/Cloud Pub/Sub, S3/GCS, ElastiCache/Memorystore)
- Built-in request validation types (Header, Query, Cookie), auth handlers, middleware, and typed pub/sub message attributes so cross-service calls stay type-safe end to end
- Optional Encore Cloud managed platform for per-PR preview environments, least-privilege IAM derived from code paths, and cost analytics — entirely separate from the open-source SDK/CLI
Common Use Cases
- Standing up a new backend service with a Postgres database, a Pub/Sub topic, and a cron job without writing any Terraform or docker-compose config
- Running integration tests locally against real Postgres and Pub/Sub semantics instead of mocks, then validating the same code path in a per-PR preview environment before merge
- Migrating an existing service into a team’s AWS or GCP account service-by-service, wiring it to existing infrastructure over APIs while new services adopt the Encore resource model
- Giving AI coding agents a tight local run-see-fix loop, since
encore runprovisions real infra locally and the CLI’s MCP server lets agents introspect services, APIs, databases, and traces
Under The Hood
Architecture - Encore.dev’s npm package is a thin TypeScript SDK (mod.ts plus submodules for api, auth, config, cron, log, pubsub, service, storage/{sqldb,objects,cache}, validate, metrics) whose real work happens outside the package: the monorepo’s Go compiler and Rust-based tsparser (v2 parser) statically analyze application source for these constructs (Service classes in encore.service.ts files, Topic/Subscription declarations, SQLDatabase/Bucket instances, CronJob configs) and build an application graph that drives both encore run’s local provisioning (real Postgres, NSQ for Pub/Sub, local filesystem for buckets) and cloud deploys (RDS/Cloud SQL, SNS+SQS/Cloud Pub/Sub, S3/GCS). The SDK types are effectively markers the compiler recognizes rather than a conventional runtime library.
Tech Stack - The overall repo is 57% Go (CLI, compiler, provisioning logic) and 40% Rust (tsparser, the TypeScript static analyzer, built with Cargo), with the encore.dev npm package itself under 2% of repo bytes and written in plain TypeScript with zero runtime dependencies - its package.json lists only devDependencies (typescript, typedoc, @types/node). Go module encr.dev pins go 1.25 and pulls in cloud SDKs (cloud.google.com/go/storage), a TUI stack (charmbracelet/bubbletea, lipgloss), and esbuild for bundling.
Code Quality - The npm SDK package ships no visible unit tests of its own (test coverage instead lives in the monorepo’s e2e-tests directory and the Go/Rust compiler test suites, which validate the parser’s recognition of SDK constructs end-to-end rather than testing the thin TS wrapper types in isolation). Naming is consistent and the exports map in package.json cleanly separates each subsystem (api, auth, pubsub, storage/sqldb, etc.) as an independently importable subpath, which keeps tree-shaking straightforward for consumers.
API Design - The public surface favors small, composable primitives over configuration objects: new Topic(name, cfg), new SQLDatabase(name, {migrations}), new Bucket(name, {versioned}), and a Service class scoped by directory convention. Branded utility types (Header<T>, Query<T>, Cookie<T>) let request/response shapes stay plain TypeScript while the compiler extracts wire-level metadata from them, so there’s very little boilerplate to get an endpoint or resource declared, at the cost of a non-obvious dependency on the external compiler to make any of it actually run.