Compare Encore.ts
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.

See what ships All comparisons

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, 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 AWS.

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 account required

    Stacks deploys into your AWS account with no intermediary, which some organisations require.

  • Single-application simplicity

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

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, dashboard, queue history Distributed tracing and metrics
Cloud targets AWS AWS and GCP
Admin surface Generated from models Developer dashboard, not an app admin

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.

The frameworks that usually come up in the same conversation.

Stacks vs NestJS

Structured TypeScript backends with dependency injection. Stacks trades DI for conventions.

Stacks vs Elysia

The fastest Bun-native router, with end-to-end types. Stacks is the framework around one.

Stacks vs AdonisJS

The other Laravel-inspired TypeScript framework. The closest comparison on this page.