Encore: Declaring Infrastructure in Go and TypeScript Code

The problem Encore targets: infrastructure declared in code, not next to it

Most backend teams keep two sources of truth. The service code says it needs a database and a queue; a Terraform directory or a cloud console says which database and which queue. The two drift, and the drift only shows up at deploy time. Encore's answer is to make the resource declaration part of the application and derive the rest.

The audience is narrow and specific. It is Go and TypeScript teams building services that talk to Postgres, Pub/Sub, object storage, caches, cron jobs and secrets. The README frames the pitch around the fail-loop: instead of push, wait for CI, and fix, you run the system locally with real infrastructure semantics and push once it works. Whether that loop matters depends on how much of your day is spent waiting on remote environments.

It is not a general purpose PaaS and it is not trying to own every resource. The README is explicit that you can import the AWS SDK or GCP client libraries and provision things yourself, or wire them up alongside Encore-managed resources through the Terraform provider. That is a deliberate scope choice: the project covers the common backend resources and leaves the long tail to you.

How the application graph works, from declaration to provisioned resource

The mechanism is a graph. Each declaration in code becomes a node. The README example declares a Postgres database with migrations, a Pub/Sub topic with an at-least-once delivery guarantee, and a versioned object storage bucket. Encore walks those declarations, runs the migrations, and stands up local equivalents when you run the CLI.

The mapping is the interesting part, because it is what makes the code portable. A SQL database is Postgres locally, RDS on AWS, Cloud SQL on GCP. Pub/Sub is NSQ locally, SNS plus SQS on AWS, Cloud Pub/Sub on GCP. Object storage is the local filesystem, then S3 or GCS. Cache is Redis, ElastiCache or Memorystore. Secrets go to the Encore vault locally and to Secrets Manager or Secret Manager in the cloud. Compute is local, then Fargate or EKS, or Cloud Run or GKE.

On deploy, Encore diffs the graph against the target environment, provisions whatever is missing in your AWS or GCP account, wires up IAM based on the code paths, and rolls out the new code. Configuration is kept separate from semantics: the code says what the app needs, and instance sizes, replicas and process allocation are handled in the platform dashboard, directly in the cloud console, or through the Terraform provider. The claim that Encore picks up console changes on the next deploy is worth testing against your own account before you rely on it.

Installing Encore and running a first service locally

The README does not include an install command, so the entry point is the documentation at encore.dev and the CLI under the cli/ directory in the repository. Once the CLI is on your PATH, the workflow starts with encore run, which the README describes as starting the whole system locally: real Postgres, real Pub/Sub semantics, type-safe service-to-service calls, and a local dashboard with distributed tracing.

The resource declarations are what you write first. This TypeScript example is taken from the README and shows a database, a topic and a bucket:

import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
import { Bucket } from "encore.dev/storage/objects";

const db = new SQLDatabase("users", { migrations: "./migrations" });
const signups = new Topic<SignupEvent>("signups", {
  deliveryGuarantee: "at-least-once"
});
const avatars = new Bucket("avatars", { versioned: true });

After encore run, the local dashboard should show the services and the tracing data. The README also mentions infrastructure namespaces, which let multiple branches or agents work in parallel with isolated state. That matters more than it sounds: without isolation, two branches sharing one local Postgres will fight over migrations, and the failure looks like a code bug.

Where Encore is the wrong tool

The most obvious boundary is language. The SDK ships for TypeScript and Go, and the README lists Python as coming soon. If your services are Python, there is nothing to adopt yet.

The second boundary is the build. The repository is a Cargo workspace with members including runtimes/core, runtimes/js, tsparser and supervisor, and the Cargo.toml patches crates.io entries for tokio-postgres, postgres-protocol and postgres-types to a fork on the encoredev/rust-postgres repository, plus several swc crates to an encoredev/swc branch. That means building the toolchain from source pulls patched dependencies rather than upstream releases. For most users this is invisible because they install a released CLI, but it is a real constraint if you need to audit or vendor the build.

The third boundary is the model itself. Declaring resources in code is a good fit when the declaration is the source of truth. It is a poor fit when infrastructure is owned by a platform team with its own review process, or when a resource must exist before the application does. The README acknowledges the second case by pointing at the Terraform provider and the migration guide, but the further you move resource ownership out of code, the less the graph buys you.

Encore against plain Terraform plus a local Docker Compose stack

The honest comparison is not another framework. It is the setup most Go and TypeScript teams already have: Terraform for cloud resources and a docker-compose file for local Postgres, Redis and a queue.

The difference is where the mapping lives. With Terraform and Compose, you maintain two descriptions of the same topology, and the local one approximates the cloud one. With Encore, one declaration produces both, which is why the local environment can run real Postgres and real Pub/Sub semantics instead of a stub. The cost is that the mapping is fixed to the table in the README: if you need a resource outside that table, you are back to provisioning it yourself and wiring it in.

Terraform is also better at the things Encore deliberately does not do. It has a plan step you can review before anything changes, and a state file you can inspect. Encore diffs the graph and provisions what is missing on deploy; the README describes the diff, but it does not describe a reviewable plan artifact. Teams with strict change control should weigh that difference carefully.

Maintenance, releases and the MPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-18, three days before this writing. Recent releases include v1.58.4 and v1.58.3, both on 2026-08-27, and v1.58.2 on 2026-08-19. The cadence is frequent, and the release notes titles are short ("Fixes and improvements", "Minor improvements"), which tells you the patch stream is steady but not what changed. Read the notes before upgrading rather than assuming a patch release is inert.

The licence is MPL-2.0, a file-level copyleft licence. Modifications to files covered by the licence must be made available under the same terms, while larger works that combine the covered files with other code can be distributed under other terms. That is a different obligation from MIT or Apache-2.0, and it is worth a look from whoever handles licensing at your organisation. This is a description of the licence, not legal advice.

The upgrade cost has two parts. The CLI moves quickly, and the SDK version is pinned in your own go.mod or package.json, so the two can drift. The repository's go.mod requires encore.dev v1.1.0, which is the version the tool itself builds against, not necessarily the version you should use. The second part is the graph: a change to how a resource is declared can change what gets provisioned, so treat SDK upgrades the way you treat schema migrations and run them against a preview environment first.

Editorial conclusion

Adopt Encore if your team writes Go or TypeScript services, wants real Postgres and Pub/Sub semantics on a laptop, and is comfortable with the application graph deciding what gets provisioned. Do not adopt it if you need Python today (the README says it is coming soon), if your infrastructure must stay outside a code-declared model, or if you cannot accept a Rust toolchain and a patched Postgres client in the build. Verify first that encore run starts on your machine, that the migration tooling matches how you already version schemas, and that you are willing to run the SDK without the managed platform if the platform terms do not fit.

Frequently asked questions

Official sources

1. encoredev/encore on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases