Stacks vs Encore.ts

Two frameworks that think infrastructure belongs in the code.

Encore reads your source, works out which databases, queues, and cron jobs it implies, and provisions them. Stacks reaches the same conclusion from the other end: the infrastructure is declared in config in the repository, and one command applies it. The difference is that Encore is built for many services and Stacks is built for one application.

What Encore.ts is.

In its own terms, not ours.

Encore.ts declares infrastructure as typed objects in application code, generates the provisioning for local, preview, and production environments, and provides a Rust-based request runtime for performance. Its distributed-systems tooling, including service catalogues, tracing, and preview environments per pull request, is more advanced than anything here.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Encore.ts for

  • Distributed systems

    Service-to-service calls, tracing, and a service catalogue are built for estates of services, which is not what Stacks optimises for.

  • Preview environments

    An ephemeral environment per pull request, provisioned automatically on the Encore Cloud Pro plan, is a strong workflow.

  • Observability

    Tracing and metrics are wired in from the start rather than added.

  • Cloud-agnostic provisioning

    AWS and GCP from the same declarations, where Stacks targets Hetzner, AWS, and plain SSH boxes, and not GCP.

Pick Stacks for

  • The application, not just the backend

    Views, CMS, commerce, admin, and mail are part of the framework rather than services you would write.

  • A data layer with opinions

    Models generate migrations and validation; Encore gives you a database and leaves the ORM to you.

  • No platform in the middle, no platform fee

    Encore Cloud provisions your AWS or GCP account for $49 per member a month plus per-environment and per-resource fees, and self-hosting Encore means wiring the infrastructure yourself. Stacks provisions Hetzner or AWS, or adopts any Linux box over SSH, directly.

  • Single-application simplicity

    One deployable, one database, one repository, which is the right shape for most products.

  • Your own mail server

    Stacks ships an SMTP and IMAP server, so hello@ and support@ on your domain are real mailboxes on your own box, readable in Mail.app or any client. buddy mail:provision creates them and their MX, SPF, DKIM, and DMARC records. None of the frameworks compared here ships one.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Encore.ts
Target shape One application Many services
Infrastructure Declared in config/cloud.ts Inferred from code declarations
Data layer First-party ORM Provisioned Postgres, ORM of your choice
Front end Included Separate application
Background work Queues, jobs, schedules Pub/sub and cron primitives
Observability Logs, error tracking, query and job history Distributed tracing and metrics
Cloud targets Hetzner, AWS, any SSH box AWS and GCP
Admin surface Generated from models Developer dashboard, not an app admin
Mail server Built in: SMTP, IMAP, real mailboxes None; inboxes come from a hosted provider

If you did move.

What ports cleanly, what does not, and where to start.

Endpoints become actions

Encore API endpoints and Stacks actions are the same unit with different decoration.

Fold services into one application

Most Encore services in a small system become modules of one Stacks application, which removes the calls between them.

Infrastructure moves to config

Databases, queues, and cron declarations become config plus app/Scheduler.ts entries.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Encore.ts when

You are building a distributed backend, you want per-pull-request environments and tracing, and the front end is a separate concern.

Choose Stacks when

You are building one product, and you want the front end, the admin, and the content layer in the same place as the API, on servers you own without a per-member platform fee.

The frameworks that usually come up in the same conversation.