DEV Community: Marcus Kohlberg

[Boost]

Marcus Kohlberg — Thu, 12 Mar 2026 07:28:28 +0000

Encore.ts + Effect.ts : Building a Production-Ready Task Management System with Functional TypeScript

Leonardo Marciano ・ Mar 12

Build a production-ready SaaS app (that will scale!)

Marcus Kohlberg — Mon, 09 Feb 2026 13:42:15 +0000

Thinking of building a SaaS application? This starter template will help you create a scalable and production ready application using Encore.ts and Next.js.

It uses Clerk for authentication, has a Stripe integration for payments, and uses Tailwind and shadcn/ui for styling and components.

Demo: https://encorets-saas-starter.vercel.app
Open on GitHub

Features

Marketing landing page (/)
Pricing page (/pricing) which connects to Stripe Checkout
Dashboard pages with (/dashboard)
Subscription management (/dashboard/subscription)

Tech stack

Backend framework: Encore.ts
Frontend framework: Next.js
Authentication: Clerk
Payments: Stripe
UI Library: Tailwind & shadcn/ui

Getting started

Install or Update Encore

Install Encore:

macOS: brew install encoredev/tap/encore
Linux: curl -L https://encore.dev/install.sh | bash
Windows: iwr https://encore.dev/install.ps1 | iex

Note: This starter requires Encore v1.46.9+, if you have an older version installed, update using encore version update.

Create app

Create a local app from this template:

encore app create my-app-name --example=ts/saas-starter

Then install the frontend dependencies:

cd my-app-name/frontend
pnpm install

Setting up Clerk

Create a Clerk account if you haven't already. Then, in the Clerk dashboard, create a new application.

Ensure the application is configured to support organizations, which can be enabled on the Organization management settings page.

Secrets

If you host your app on Vercel (see deployment instructions further down), you can connect your Clerk application with your Vercel project under Integrations in the project settings on Vercel.
Don't forget to run vercel env pull afterward.

Otherwise, go to the API Keys page for your app. Copy the "Publishable Key" and one of the "Secret keys". To your frontend project, add them to the .env.local as

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY={PUBLISHABLE_KEY}
CLERK_SECRET_KEY={SECRET_KEY}

You also need to add the following environment variables to your frontend project:

NEXT_PUBLIC_CLERK_SIGN_IN_URL="/sign-in"

To add them to Encore, go to the API Keys page for your app. Copy the "Publishable Key" and one of the "Secret keys".

From your terminal (inside the backend directory), run:

$ encore secret set --prod ClerkSecretKey

Next, do the same for the development secret. The most secure way is to create another secret key (Clerk allows you to have multiple).
Once you have a client secret for development, set it similarly to before:

$ encore secret set --dev ClerkSecretKey

Setting up Stripe

Create a Stripe account if you don't have one already. Then, create your account and make sure to set up the products and pricing plans. You must also configure the billing customer portal.

You will also need to add your backend as a webhook endpoint in Stripe and set the endpoint URL to https://YOUR_DOMAIN/stripe/webhook.

Currently, the pricing plans are stored in frontend/lib/plans.ts, but you can also read them from Stripe or store them in a database if you prefer.

Secrets

On the Stripe dashboard, go to the Developers page and create a new API key. Copy the "Secret Key".

From your terminal (inside the backend directory), run:

$ encore secret set --dev StripeSecretKey

To be able to verify the incoming webhook requests, you need to copy the signing secret from the Webhook page on the Stripe dashboard and add it to Encore by running:

$ encore secret set --dev StripeWebhookSigningSecret

Once you want to set it up for production, create a separate Secret key and Webhook Signing Secret for production and run:

$ encore secret set --prod StripeSecretKey
$ encore secret set --prod StripeWebhookSigningSecret

Testing payments

To test Stripe payments, use the following test card details:

Card Number: 4242 4242 4242 4242
Expiration: Any future date
CVC: Any 3-digit number

Vercel Environment Variables

Vercel-specific environment variables are not set on local by default, so you need to add them yourself. This can be done on the project settings page on Vercel.

Please add the following environment variables for development:

VERCEL_ENV="development"
NEXT_PUBLIC_VERCEL_ENV="development"
VERCEL_GIT_PULL_REQUEST_ID=""
NEXT_PUBLIC_VERCEL_GIT_PULL_REQUEST_ID=""

Run locally

Run your Encore backend:

cd backend
encore run

Note: This will fail unless you set up the Stripe and Clerk secrets according to the instructions above.

In a different terminal window, run the React frontend using Next.js:

cd frontend
pnpm run dev

Generating a request client

Keep the contract between the backend and frontend in sync by regenerating the request client whenever you make a change to an Encore endpoint.

pnpm run gen # Deployed Encore staging environment
# or
pnpm run gen:local # Locally running Encore backend

Deployment

Encore

Deploy your backend to a staging environment in Encore's free development cloud:

git add -A .
git commit -m 'Commit message'
git push encore

Then head over to the Cloud Dashboard to monitor your deployment and find your production URL.

From there you can also see metrics, traces, connect your app to a GitHub repo to get automatic deploys on new commits, and connect your own AWS or GCP account to use for deployment.

Nice job, your SaaS backend is now deployed to the cloud!

Next.js on Vercel

Create a repo and push the project to GitHub.
Create a new project on Vercel and point it to your GitHub repo.
Select frontend as the root directory for the Vercel project.

Frontend & CORS configuration

The backend needs to know where the frontend is hosted, in order to serve the correct redirect URLs
back from Stripe. It is also necessary for CORS to work correctly.

To handle this, you need to update two configuration files.

First, update the FRONTEND_URL constant in backend/config.ts to point to where your frontend is hosted.

Secondly, if you are running into CORS issues when calling your Encore API from your frontend then you may need to specify which origins are allowed to access your API (via browsers). You do this by specifying the global_cors key in the encore.app file, which has the following structure:

"global_cors": {
  // allow_origins_without_credentials specifies the allowed origins for requests
  // that don't include credentials. If nil it defaults to allowing all domains
  // (equivalent to ["*"]).
  "allow_origins_without_credentials": [
    "<ORIGIN-GOES-HERE>"
  ],

  // allow_origins_with_credentials specifies the allowed origins for requests
  // that include credentials. If a request is made from an Origin in this list
  // Encore responds with Access-Control-Allow-Origin: <Origin>.
  //
  // The URLs in this list may include wildcards (e.g. "https://*.example.com"
  // or "https://*-myapp.example.com").
  "allow_origins_with_credentials": [
    "<DOMAIN-GOES-HERE>"
  ]
}

Both of these default to "https://encorets-saas-starter.vercel.app" which is the hosted demo application.

More information on CORS configuration can be found here: https://encore.dev/docs/ts/develop/cors

Wrapping up

You now have a scalable and production-ready SaaS application up and running. Now keep going and develop your SaaS product!

If you have questions: Join our Discord
Star Encore on GitHub
Find more Open-source App Examples
Join our Squad if you want to contribute content to Encore's blog

[Boost]

Marcus Kohlberg — Mon, 09 Feb 2026 13:39:59 +0000

The End of Heroku: What It Means for Your Apps

Marcus Kohlberg for Encore ・ Feb 9

#heroku #cloud #backend #devops

The End of Heroku: What It Means for Your Apps

Marcus Kohlberg — Mon, 09 Feb 2026 13:39:47 +0000

Heroku recently moved to a "sustaining engineering model." No new features, no new enterprise contracts. The platform stays running for existing customers, but active development has stopped.

Heroku launched in 2007 and was acquired by Salesforce for $212 million in 2010. After removing its free tier in November 2022 and years of slowing feature development, the February 2026 announcement made the trajectory official.

For teams planning a move, the biggest shift is toward infrastructure ownership: deploying to your own AWS or GCP account rather than renting another managed platform. But there are several directions and here's what each option offers.

Encore Cloud

If you want to replicate Heroku's git push workflow while owning your infrastructure, Encore Cloud provisions managed resources in your own AWS or GCP account (powered by Encore, an open-source framework with 11k+ GitHub stars). You declare infrastructure as type-safe objects in your TypeScript or Go code, and Encore provisions the corresponding managed services. Everything else is standard TypeScript or Go.

import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
import { CronJob } from "encore.dev/cron";

// These declarations are all Encore needs to provision your infrastructure.
// Everything else in your codebase is standard TypeScript (or Go).
const db = new SQLDatabase("main", { migrations: "./migrations" });
const events = new Topic<OrderEvent>("events", { deliveryGuarantee: "at-least-once" });
const _ = new CronJob("daily-cleanup", { schedule: "0 0 * * *", endpoint: cleanup });

On AWS, this provisions RDS, SNS/SQS, and CloudWatch Events. On GCP, it provisions Cloud SQL, Pub/Sub, and Cloud Scheduler. Networking, IAM, encryption, and backups are configured automatically following cloud provider best practices.

Deployment works like Heroku: git push encore main. The infrastructure runs in your account, visible in the AWS or GCP console. Local development runs everything with encore run, every pull request gets an automatic preview environment, and built-in distributed tracing and metrics come included.

For teams using AI agents like Cursor and Claude Code, infrastructure-from-code means infrastructure doesn't drift from application logic. When AI changes your code, infrastructure updates automatically to match, and guardrails like type validation and compile-time checks are built in so there's no separate Terraform or YAML falling out of sync.

Companies like Groupon already use this at scale with TypeScript and Go, deploying to both AWS and GCP (Azure is not yet supported).

Managed Platforms

Render

Render is the most direct Heroku replacement. The concepts are nearly identical: git-push deploys, managed Postgres, background workers, cron jobs. If you want the smallest possible change from your current workflow, Render is the shortest path.

The mental model carries over cleanly as you connect a Git repo, define services in render.yaml or through the dashboard, and push to deploy. Render handles SSL, load balancing, and auto-deploys from your branch, and preview environments work similarly to Heroku Review Apps.

The main tradeoff is that you're still on someone else's infrastructure. If Render changes direction, raises prices, or gets acquired, you're in a similar position to where you are with Heroku. Per-service and per-seat pricing can also add up for larger teams running multiple services.

Fly.io

Fly.io takes a different approach. Instead of abstracting away infrastructure, it gives you lightweight VMs (Machines) in 30+ regions worldwide. The deployment workflow has a similar feel (fly deploy and your app is live) but the underlying model is closer to running containers than Heroku-style dynos.

Fly.io is well-suited for applications where latency matters, with fast cold starts, automatic placement near users, and a global Anycast network. The community is active and the team is responsive on support.

The managed Postgres offering has had some reliability challenges, though the team is actively improving this with their new MPG product. Pricing is usage-based, which can make monthly bills harder to predict compared to Heroku's flat per-dyno model.

Railway

Railway focuses on modern developer experience. The dashboard is clean, deploys are fast, and the project model is intuitive. It supports any language via Docker or Nixpacks (similar to Heroku buildpacks) and deploys from GitHub, a CLI, or templates.

Railway stands out for teams: paid plans include unlimited seats, which is a meaningful differentiator over Render and Heroku where each team member adds to the bill. Support for monorepos and multi-service projects is solid.

Like Render and Fly.io, you're on Railway's infrastructure. It's a managed platform with the same category of tradeoffs around ownership and portability.

Self-Hosted: Coolify, Dokku, Dokploy

Tools like Coolify, Dokku, and Dokploy run a Heroku-like experience on your own VPS. The typical setup is a Hetzner or DigitalOcean server with one of these tools installed. You get git-push deploys, automatic SSL, and database provisioning.

This path gives you the most control at the lowest price. Dokku is the most mature option (built in 2013, supports Heroku buildpacks directly). Coolify and Dokploy offer web dashboards for teams that prefer a GUI.

The tradeoff is operational responsibility. You manage the server: OS updates, security patches, backups, monitoring. For side projects and internal tools this is fine. For production applications that need high availability, it takes significantly more effort.

How to Choose

If you need...	Consider
Infrastructure ownership, compliance	Encore Cloud (your AWS/GCP)
Fastest migration from Heroku	Render
Global edge performance	Fly.io
Modern DX, unlimited team seats	Railway
Lowest possible cost	Self-hosted (Coolify/Dokku)

Heroku's concepts (dynos, Postgres, worker processes, config vars, pipelines) map cleanly to every alternative. The migration is more about choosing the right destination than dealing with technical complexity.

For step-by-step migration guides:

Related Resources

How to Deploy to AWS in 2026

Marcus Kohlberg — Tue, 27 Jan 2026 09:26:40 +0000

Deploying to AWS in 2026 looks different than it did five years ago. The ecosystem has matured, new tools have emerged, and the "right" approach depends more than ever on your team's size, experience, and what you're building.

This guide covers the main options for deploying backend applications to AWS, from clicking around in the console to fully automated infrastructure-as-code. We'll look at the trade-offs, show code examples, and help you pick the right approach.

Option 1: AWS Console (Click-Ops)

The AWS Console is where most developers start. You log in, click through wizards, and configure services manually.

When it works:

Learning AWS concepts
Quick experiments and prototypes
One-off tasks that don't need to be repeatable

When it doesn't:

Anything you need to reproduce (staging, production, disaster recovery)
Team environments where multiple people need to understand the setup
Compliance requirements that need audit trails

The console is fine for learning, but you'll quickly hit limits. There's no version control, no way to review changes, and no easy path to reproduce what you built. Most teams graduate to something else within months.

Option 2: Infrastructure from Code (Encore)

Encore takes a different approach than traditional infrastructure-as-code. Instead of writing separate infrastructure definitions, you declare what your application needs directly in your backend code. Encore Cloud then provisions AWS resources automatically.

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

// This creates an RDS PostgreSQL database
const db = new SQLDatabase("users", {
  migrations: "./migrations",
});

// This creates SNS/SQS
const signups = new Topic<SignupEvent>("signups", {
  deliveryGuarantee: "at-least-once",
});

// This creates a Fargate service or Lambda
export const createUser = api(
  { method: "POST", path: "/users", expose: true },
  async (req: CreateUserRequest) => {
    const user = await db.exec`INSERT INTO users ...`;
    await signups.publish({ userId: user.id });
    return user;
  }
);

When you push code, Encore analyzes it and provisions the corresponding AWS resources: RDS for databases, SNS/SQS for Pub/Sub, Fargate or Lambda for compute, S3 for object storage, CloudWatch for cron jobs.

What you get:

No Terraform, CloudFormation, or YAML to write
Infrastructure changes through code review (not manual config)
Local development with Docker-based versions of AWS services
Preview environments for every pull request
Built-in observability (tracing, metrics, logs)

Trade-offs:

Less granular control over resource configuration than raw Terraform
Newer ecosystem than Terraform

Encore works well for teams that want AWS infrastructure ownership without becoming infrastructure experts. Companies like Groupon use this approach to power their backends at scale. The open-source framework has 11k+ GitHub stars.

Option 3: AWS CloudFormation

CloudFormation is AWS's native infrastructure-as-code service. You define resources in YAML or JSON templates, and CloudFormation creates and manages them.

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  MyDatabase:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: db.t3.micro
      Engine: postgres
      MasterUsername: admin
      MasterUserPassword: !Ref DBPassword
      AllocatedStorage: 20

  MyLambda:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: nodejs18.x
      Handler: index.handler
      Code:
        S3Bucket: my-deployment-bucket
        S3Key: lambda.zip

What you get:

Native AWS integration, no third-party dependencies
Drift detection (CloudFormation can tell if someone changed resources manually)
Stack management for grouping related resources

Trade-offs:

Verbose YAML/JSON syntax
Slow feedback loops (deployments can take minutes)
Limited programming constructs (no loops, limited conditionals)
AWS-only (can't manage GCP or other providers)

CloudFormation is reliable but painful to write. Most teams either use a wrapper (like CDK) or switch to Terraform.

Option 4: AWS CDK

The Cloud Development Kit (CDK) lets you write CloudFormation in real programming languages. You write TypeScript, Python, or Go, and CDK synthesizes CloudFormation templates.

import * as cdk from 'aws-cdk-lib';
import * as rds from 'aws-cdk-lib/aws-rds';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class MyStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string) {
    super(scope, id);

    const database = new rds.DatabaseInstance(this, 'Database', {
      engine: rds.DatabaseInstanceEngine.postgres({
        version: rds.PostgresEngineVersion.VER_15,
      }),
      instanceType: ec2.InstanceType.of(
        ec2.InstanceClass.T3, 
        ec2.InstanceSize.MICRO
      ),
    });

    const fn = new lambda.Function(this, 'Handler', {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      environment: {
        DATABASE_URL: database.instanceEndpoint.hostname,
      },
    });
  }
}

What you get:

Real programming language instead of YAML
IDE autocomplete and type checking
Reusable constructs and abstractions
Still generates CloudFormation under the hood

Trade-offs:

Adds a compilation step (CDK → CloudFormation → AWS)
Debugging means understanding both CDK and CloudFormation
AWS-only
Still requires understanding AWS service configuration

CDK is a significant improvement over raw CloudFormation, but you still need to understand AWS services deeply.

Option 5: Terraform

Terraform is the industry standard for infrastructure-as-code. It uses HashiCorp Configuration Language (HCL) and works across AWS, GCP, Azure, and hundreds of other providers.

// Terraform HCL syntax
provider "aws" {
  region = "us-east-1"
}

resource "aws_db_instance" "main" {
  identifier        = "my-database"
  engine            = "postgres"
  engine_version    = "15"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  username          = "admin"
  password          = var.db_password
}

resource "aws_lambda_function" "api" {
  function_name = "my-api"
  runtime       = "nodejs18.x"
  handler       = "index.handler"
  filename      = "lambda.zip"

  environment {
    variables = {
      DATABASE_URL = aws_db_instance.main.endpoint
    }
  }
}

What you get:

Multi-cloud support
Massive ecosystem (providers for everything)
State management for tracking what's deployed
Plan/apply workflow for reviewing changes before deploying
Large community and extensive documentation

Trade-offs:

Learning HCL (it's not hard, but it's another language)
State file management (remote state, locking, etc.)
Can get complex for large infrastructures
Separate from your application code

The trade-off is that you're maintaining two codebases: your application and your infrastructure. This adds overhead but gives you more control over individual resource settings.

Option 6: Pulumi

Pulumi is like Terraform but uses real programming languages instead of HCL. You write TypeScript, Python, Go, or C# to define infrastructure.

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

const database = new aws.rds.Instance("database", {
  engine: "postgres",
  engineVersion: "15",
  instanceClass: "db.t3.micro",
  allocatedStorage: 20,
  username: "admin",
  password: config.requireSecret("dbPassword"),
});

const fn = new aws.lambda.Function("api", {
  runtime: "nodejs18.x",
  handler: "index.handler",
  code: new pulumi.asset.FileArchive("./lambda"),
  environment: {
    variables: {
      DATABASE_URL: database.endpoint,
    },
  },
});

What you get:

Real programming language (loops, conditionals, functions)
Type safety and IDE support
Multi-cloud support
Can share code between infrastructure and application

Trade-offs:

Smaller ecosystem than Terraform
Still requires understanding cloud service configuration
Separate from your application code

Pulumi offers an alternative to Terraform's HCL syntax if you prefer using TypeScript or Python for infrastructure definitions.

Option 7: SST (Serverless Stack)

SST focuses on serverless AWS deployments. It's built on CDK but optimized for Lambda, API Gateway, and related services.

import { Api, Table } from "sst/constructs";

export function API({ stack }: StackContext) {
  const table = new Table(stack, "users", {
    fields: { id: "string", email: "string" },
    primaryIndex: { partitionKey: "id" },
  });

  const api = new Api(stack, "api", {
    routes: {
      "POST /users": "packages/functions/src/create.handler",
    },
  });

  api.bind([table]);

  return { api };
}

What you get:

Optimized for serverless (Lambda, DynamoDB, etc.)
Live Lambda development (code changes without redeploy)
Good developer experience for serverless patterns

Trade-offs:

Serverless-focused (less suited for containers or traditional servers)
Built on CDK, so inherits some of its complexity
AWS-only

SST targets serverless applications on AWS. It's built on CDK, so you'll still need to understand AWS concepts.

Comparison

Approach	Learning Curve	Flexibility	Maintenance	Best For
Console	Low	High	None (not repeatable)	Learning, experiments
Encore	Low	Medium	Low	Teams wanting AWS without DevOps
CloudFormation	High	High	High	AWS-native shops
CDK	Medium	High	Medium	Teams comfortable with AWS
Terraform	Medium	Very High	Medium	Multi-cloud, large infra
Pulumi	Medium	Very High	Medium	Developers who prefer real code
SST	Low-Medium	Medium	Low	Serverless applications

Which Should You Choose?

Choose the Console if:

You're learning AWS
It's a one-time experiment

Choose Encore if:

You want to focus on backend code, not infrastructure
You want AWS ownership without becoming an AWS expert
You value fast iteration and built-in observability
Your infrastructure needs are covered by databases, queues, cron, storage

Choose CloudFormation/CDK if:

You're already invested in the AWS ecosystem
You need fine-grained control over every AWS setting
Your organization mandates AWS-native tooling

Choose Terraform if:

You need multi-cloud support
You have complex infrastructure requirements
Your team has (or wants to build) infrastructure expertise
You need to manage non-AWS resources

Choose Pulumi if:

You want Terraform's flexibility with real programming languages
Your team prefers TypeScript/Python over HCL

Choose SST if:

You're building serverless applications
You want the best Lambda development experience
You're okay being AWS-only

Getting Started

Most teams should start with the simplest option that meets their needs, then evolve if necessary. If you're building a backend application and don't want to become an infrastructure expert, Encore is worth trying. If you need maximum flexibility or multi-cloud support, Terraform is the industry standard.

Whatever you choose, avoid the console for anything you need to reproduce. Infrastructure-as-code isn't optional in 2026—it's how professional teams ship software.

Related Resources

[Boost]

Marcus Kohlberg — Fri, 23 Jan 2026 14:42:31 +0000

Best TypeScript Backend Frameworks in 2026

Marcus Kohlberg for Encore ・ Jan 23

#typescript #node #javascript #backend

Best TypeScript Backend Frameworks in 2026

Marcus Kohlberg — Fri, 23 Jan 2026 14:42:24 +0000

TypeScript has become the default choice for backend development in the Node.js ecosystem. The combination of type safety and JavaScript's flexibility makes it ideal for building production APIs. But with so many frameworks available, picking the right one can be challenging.

In this guide, we break down the most popular TypeScript backend frameworks in 2026, comparing their features, ideal use cases, and potential drawbacks to help you make an informed decision.

TypeScript Backend Frameworks: An Overview

Here's a high-level comparison of the frameworks included in this article, comparing built-in support for common backend requirements.

Feature	Express.js	Encore.ts	Fastify	NestJS	Hono
Use case	General purpose APIs	Distributed systems	Schema-validated APIs	Enterprise applications	Edge & serverless
Learning Curve	Low	Low	Medium	High	Low
Built-in Validation	No	Yes	Yes (JSON Schema)	Yes (decorators)	Yes
Type-safe Service Calls	No	Yes	No	No	No
Built-in Tracing	No	Yes	No	No	No
Infrastructure from Code	No	Yes	No	No	No
Auto API Documentation	No	Yes	Yes (via plugins)	Yes (via plugins)	No
Service Discovery	No	Yes	No	No	No

Express.js

Express is the grandfather of Node.js frameworks. Released in 2010, it remains the most widely used Node.js framework with millions of weekly npm downloads. Express takes a minimalist approach, providing the core building blocks for web applications while leaving architectural decisions to the developer.

The framework's longevity has resulted in an unmatched ecosystem. Whatever functionality you need, there's likely Express middleware for it. This makes Express a safe choice for teams who value proven solutions and extensive community support.

import express from 'express';

const app = express();
app.use(express.json());

app.get('/users/:id', async (req, res) => {
  const user = await getUserById(req.params.id);
  res.json(user);
});

app.listen(3000);

Key Features

Minimal core with extensive middleware ecosystem
Flexible routing with support for various HTTP methods
Template engine support for server-rendered applications
Static file serving out of the box

Benefits

Express shines in situations where flexibility is paramount. Its unopinionated nature means you can structure your application however you like, using whatever libraries you prefer. The massive community means finding help, tutorials, and solutions to common problems is straightforward.

Limitations

Express was designed before TypeScript became mainstream, so type safety requires additional setup. Request validation needs external libraries like Zod or Joi. The framework's age also means some patterns feel dated compared to modern alternatives.

When to Consider Express

Consider Express when you need maximum flexibility, want to leverage existing middleware, or have a team already experienced with the framework. It's also a reasonable choice for simple APIs where the overhead of more opinionated frameworks isn't justified.

If you're evaluating Express against modern alternatives, see our detailed Express.js vs Encore.ts comparison.

Encore.ts

Encore.ts takes a fundamentally different approach to backend development. Rather than just providing HTTP routing, Encore is designed for building distributed systems with multiple services. You declare infrastructure like databases, Pub/Sub, and cron jobs directly in TypeScript, and Encore provisions them automatically during local development.

The framework excels at making microservices feel like a monolith to develop. Service-to-service calls are type-safe function calls with automatic service discovery. Built-in distributed tracing shows you exactly how requests flow through your system. And because Encore understands your infrastructure, you get a service catalog and auto-generated API documentation that stay in sync with your code.

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("users", { migrations: "./migrations" });

interface User {
  id: number;
  name: string;
}

export const getUser = api(
  { method: "GET", path: "/users/:id", expose: true },
  async ({ id }: { id: number }): Promise<User> => {
    return await db.queryRow<User>`SELECT * FROM users WHERE id = ${id}`;
  }
);

Key Features

Type-safe request validation based on TypeScript types
Infrastructure primitives (databases, Pub/Sub, cron) with automatic local provisioning
Type-safe service-to-service communication with generated clients
Built-in distributed tracing across services
Service catalog and auto-generated API documentation
Streaming APIs with WebSocket support

Benefits

Encore makes building distributed systems significantly easier. When you create a new service, you just create a new folder. Service calls become type-safe function calls with full IDE autocomplete. Databases provision automatically in local development without Docker configuration. Distributed tracing works out of the box across all your services.

The consistent infrastructure SDKs mean you use the same patterns for databases, Pub/Sub, cron jobs, and more. This makes the codebase easier to understand and onboard new developers.

Limitations

Encore is more opinionated than Express or Fastify. If you need to integrate with infrastructure that Encore doesn't support natively, you can use standard libraries alongside Encore's primitives. The framework works best when you embrace its conventions for building services.

When to Consider Encore.ts

Consider Encore when you're building microservices or distributed systems, when you want type-safe service communication with automatic service discovery, when local infrastructure automation matters (databases, Pub/Sub without Docker), or when you want built-in observability across multiple services.

Try Encore.ts

You can get started with Encore in minutes:

curl -L https://encore.dev/install.sh | bash
encore app create my-app
cd my-app
encore run

See the Encore.ts documentation for more details, or follow the REST API tutorial to build a complete application.

Fastify

Fastify positions itself as a high-performance alternative to Express, though recent benchmarks show this advantage has diminished. Modern alternatives like Encore.ts now significantly outperform both Fastify and Express in request throughput.

That said, Fastify's value proposition goes beyond raw speed. It uses JSON Schema for validation, which provides both runtime checking and automatic serialization optimization. The plugin architecture keeps code organized and encapsulated, with each plugin having its own dependencies and lifecycle. Fastify also offers good TypeScript support and helpful error messages.

import Fastify from 'fastify';

const fastify = Fastify({ logger: true });

fastify.get('/users/:id', {
  schema: {
    params: {
      type: 'object',
      properties: {
        id: { type: 'string' }
      }
    },
    response: {
      200: {
        type: 'object',
        properties: {
          id: { type: 'string' },
          name: { type: 'string' }
        }
      }
    }
  }
}, async (request, reply) => {
  return { id: request.params.id, name: 'John' };
});

fastify.listen({ port: 3000 });

Key Features

JSON Schema validation with automatic serialization
Plugin-based architecture for modularity
First-class TypeScript support
Extensive logging with Pino integration
OpenAPI generation from schemas

Benefits

Fastify provides a good balance of performance and features. The JSON Schema validation provides runtime safety and can be used to generate OpenAPI documentation. The plugin system encourages good architectural patterns and makes testing easier.

Limitations

JSON Schema definitions can become verbose, especially for complex objects. The ecosystem is smaller than Express, so you may need to write custom plugins for less common use cases. The mental model for plugins takes some time to internalize.

When to Consider Fastify

Consider Fastify when you appreciate a well-structured plugin architecture, when you want JSON Schema validation with OpenAPI generation, or when you're building a single-service API and are already familiar with the Fastify ecosystem.

NestJS

NestJS brings Angular-style architecture to the backend. It's highly opinionated, uses decorators extensively, and provides a comprehensive solution for building enterprise applications. The framework enforces consistent code organization through modules, controllers, and providers.

The dependency injection system makes testing straightforward and encourages loose coupling between components. NestJS includes solutions for most backend requirements out of the box, including GraphQL, WebSockets, microservices, and more.

import { Controller, Get, Param } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(id);
  }
}

Key Features

Angular-inspired module architecture
Built-in dependency injection container
Comprehensive decorator-based validation
First-class GraphQL and WebSocket support
Microservices patterns with multiple transport layers

Benefits

NestJS provides strong guardrails for large teams. The enforced architecture means code stays consistent as the team grows. The comprehensive feature set means you rarely need to look outside the framework for common requirements.

Limitations

The learning curve is steep. Understanding modules, providers, guards, interceptors, and pipes takes time. The decorator-heavy approach can obscure what's actually happening, making debugging more challenging. For simple APIs, NestJS can feel like overkill.

When to Consider NestJS

Consider NestJS for large enterprise applications where consistent architecture matters more than minimal boilerplate. It's particularly suitable for teams with Angular experience or those who value strong conventions.

For a deeper comparison, see our NestJS vs Encore.ts article.

Hono

Hono is a newer framework designed for modern JavaScript runtimes. It runs everywhere: Cloudflare Workers, Deno, Bun, and Node.js. The framework is ultrafast, with a minimal footprint that makes it perfect for edge deployments where bundle size matters.

Despite its small size, Hono includes essential middleware for common tasks like JWT validation, CORS, and request logging. The API is clean and intuitive, borrowing good ideas from Express while modernizing the developer experience.

import { Hono } from 'hono';

const app = new Hono();

app.get('/users/:id', (c) => {
  const id = c.req.param('id');
  return c.json({ id, name: 'John' });
});

export default app;

Key Features

Universal runtime support (Node.js, Deno, Bun, Cloudflare Workers)
Minimal bundle size for edge deployment
Built-in middleware for common requirements
Clean, modern API design
First-class TypeScript support

Benefits

Hono shines at the edge. When deploying to Cloudflare Workers or similar platforms, bundle size directly impacts cold start times and costs. The framework's universal nature also means you can move between runtimes without rewriting your application.

Limitations

As a newer framework, Hono has a smaller community and fewer third-party integrations. Some Node.js-specific patterns may require adaptation. The edge-first design means certain traditional server patterns may feel awkward.

When to Consider Hono

Consider Hono when deploying to edge platforms, when you need cross-runtime compatibility, or when building lightweight APIs where bundle size matters.

How to Choose

The right framework depends on your specific situation:

Express remains the safe choice for general-purpose development, especially when flexibility and ecosystem maturity matter most.

Encore.ts is ideal for building distributed systems with multiple services, when you want type-safe service communication, local infrastructure automation, and built-in observability.

Fastify works well for single-service APIs where you want JSON Schema validation and a plugin architecture, though performance is no longer a differentiator.

NestJS fits large enterprise applications where consistent architecture and comprehensive features justify the learning investment.

Hono is perfect for edge computing and serverless deployments where bundle size and cold start times matter.

The best way to decide is to build a small project with your top two candidates. Each framework has excellent documentation, and the experience of building something real will clarify which tradeoffs matter most to your team.

Building something with TypeScript? Join our Discord community to discuss framework choices with other developers.

[Boost]

Marcus Kohlberg — Tue, 13 Jan 2026 09:06:11 +0000

Moving on from Terraform CDK

Marcus Kohlberg for Encore ・ Jan 13

#terraform #devops #cloud #backend

Moving on from Terraform CDK

Marcus Kohlberg — Tue, 13 Jan 2026 09:06:02 +0000

HashiCorp is sunsetting Terraform CDK. Terraform CDK let you write infrastructure in TypeScript instead of HCL - you'd define AWS resources in TypeScript, run cdktf synth to generate Terraform JSON, then terraform apply to provision everything. Writing infrastructure in a real programming language with type safety and IDE support instead of learning HCL syntax.

At Encore, we approach this differently. While Encore isn't a replacement for Terraform CDK, we think developers who appreciated CDK's approach might find our perspective interesting. Instead of writing infrastructure declarations that generate configs, you write application code with infrastructure primitives. Encore parses the application code to understand what infrastructure is needed, then provisions it directly through cloud provider APIs in your AWS or GCP account (or generates a Docker image for self-hosting). The infrastructure declarations are part of your application code, not separate from it.

Note: This article describes deploying through Encore Cloud, which provisions infrastructure directly in your AWS or GCP account without config files. Self-hosting is available, but requires you to set up your own deployment infrastructure. The application code and local development benefits apply either way.

What Terraform CDK Required

Creating a database with Terraform CDK meant writing infrastructure configuration for the database instance, subnet groups, security groups, and all the wiring between them. Here's what that looked like:

import { Construct } from "constructs";
import { AwsProvider } from "@cdktf/provider-aws/lib/provider";
import { DbInstance } from "@cdktf/provider-aws/lib/db-instance";
import { DbSubnetGroup } from "@cdktf/provider-aws/lib/db-subnet-group";
import { SecurityGroup } from "@cdktf/provider-aws/lib/security-group";

const subnetGroup = new DbSubnetGroup(this, "db-subnet", {
  name: "my-db-subnet",
  subnetIds: ["subnet-12345", "subnet-67890"],
});

const securityGroup = new SecurityGroup(this, "db-sg", {
  name: "my-db-sg",
  vpcId: "vpc-12345",
  ingress: [{
    fromPort: 5432,
    toPort: 5432,
    protocol: "tcp",
    cidrBlocks: ["10.0.0.0/16"],
  }],
});

const db = new DbInstance(this, "postgres", {
  identifier: "my-postgres",
  engine: "postgres",
  engineVersion: "14.7",
  instanceClass: "db.t3.micro",
  allocatedStorage: 20,
  dbName: "myapp",
  username: "admin",
  password: process.env.DB_PASSWORD,
  dbSubnetGroupName: subnetGroup.name,
  vpcSecurityGroupIds: [securityGroup.id],
  skipFinalSnapshot: true,
});

The application code that used this database was written separately:

import { Pool } from 'pg';

const pool = new Pool({
  host: process.env.DB_HOST,
  database: 'myapp',
  user: 'admin',
  password: process.env.DB_PASSWORD,
});

const result = await pool.query('SELECT * FROM users');

Two files, two different purposes. The infrastructure file declared AWS resources. The application file used those resources through environment variables. Running cdktf synth generated Terraform JSON, then terraform apply provisioned everything, then you'd deploy your application code separately.

How We Approach This

With Encore, application code includes infrastructure declarations. The database declaration and its usage are in the same file:

import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("myapp", {
  migrations: "./migrations",
});

const result = await db.query`SELECT * FROM users`;

The SQLDatabase declaration tells Encore this application needs a PostgreSQL database. When you run the app locally with encore run, Encore starts a local PostgreSQL instance. When you deploy to AWS, Encore provisions RDS with backups, high availability, security groups, and least-privilege IAM policies configured automatically. The application code stays the same - locally it connects to the local database, in production it connects to RDS.

Local development environment with database running

A Complete API Example

Here's a user management API. With Terraform CDK, this would require separate infrastructure code for Lambda functions (or ECS tasks), API Gateway configuration, methods, integrations, IAM roles, security groups, and the database setup - easily several hundred lines of infrastructure declarations, plus the application code itself, plus state management setup.

With Encore:

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("users", {
  migrations: "./migrations",
});

interface User {
  id: number;
  email: string;
  name: string;
}

export const createUser = api(
  { method: "POST", path: "/users", expose: true },
  async ({ email, name }: { email: string; name: string }): Promise<User> => {
    await db.exec`
      INSERT INTO users (email, name)
      VALUES (${email}, ${name})
    `;
    return await db.queryRow<User>`
      SELECT id, email, name FROM users WHERE email = ${email}
    `;
  }
);

export const getUser = api(
  { method: "GET", path: "/users/:email", expose: true },
  async ({ email }: { email: string }): Promise<User | undefined> => {
    return await db.queryRow<User>`
      SELECT id, email, name FROM users WHERE email = ${email}
    `;
  }
);

Running encore run starts a local API server with a PostgreSQL database. The API is available at http://localhost:4000 and there's a development dashboard at http://localhost:9400 showing your services, APIs, and database schema. Deploying to AWS provisions ECS tasks for running the services, an Application Load Balancer for routing requests, RDS for the database, TLS certificates, and IAM roles with appropriate permissions.

API Explorer with automatic documentation and testing interface

Database migrations are standard SQL files. Here's migrations/1_create_users.up.sql:

CREATE TABLE users (
  id BIGSERIAL PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

We run these migrations automatically when the application starts, both locally and in production.

Pub/Sub

Terraform CDK required configuring SNS topics, SQS queues, subscriptions, IAM policies, and then connecting them in your application code - usually 40+ lines of infrastructure configuration plus separate publisher and consumer code.

With Encore's Pub/Sub:

import { Topic, Subscription } from "encore.dev/pubsub";

interface Order {
  orderId: number;
  userId: string;
  total: number;
}

const orders = new Topic<Order>("orders", {
  deliveryGuarantee: "at-least-once",
});

// Publishing events
await orders.publish({ orderId: 123, userId: "user_123", total: 99.99 });

// Subscribing to events
const _ = new Subscription(orders, "process-orders", {
  handler: async (order) => {
    await db.exec`
      INSERT INTO processed_orders (order_id, user_id, total)
      VALUES (${order.orderId}, ${order.userId}, ${order.total})
    `;
  },
});

The same pattern applies - the Topic declaration works locally with an in-memory pub/sub system and provisions SNS topics and SQS queues in AWS. Publishers and subscribers are type-safe through TypeScript.

Object Storage & More

The pattern extends to object storage and other primitives:

import { Bucket } from "encore.dev/storage/objects";

const uploads = new Bucket("user-uploads", {
  versioned: false,
});

// Upload a file
await uploads.upload("document.pdf", fileBuffer, {
  contentType: "application/pdf",
});

// Download a file
const file = await uploads.download("document.pdf");

Locally, this uses the filesystem. In AWS, it provisions S3 buckets with appropriate permissions and lifecycle policies.

Encore supports more infrastructure primitives - secrets management, cron jobs, streaming APIs - all following the same pattern. See the full list of primitives in the docs.

State Management

Terraform CDK still used Terraform underneath, which meant managing state files. State was typically stored in S3 with DynamoDB for locking, and you'd occasionally hit state drift issues where your actual infrastructure didn't match what Terraform thought it provisioned. Team coordination required careful state locking, and migrating state between backends was manual work.

We don't use state files in Encore. Instead, we analyze your application code to understand what infrastructure exists and what needs to be provisioned. When you deploy, we compare what's declared in your code to what's actually running in your cloud account and provision any differences. Infrastructure always matches code because the code is the source of truth - no separate state to drift out of sync, no locking mechanisms to configure, no state backend to manage.

Infrastructure changes require approval before provisioning

Type Safety

Terraform CDK provided type safety for infrastructure declarations - TypeScript would catch errors if you misconfigured an RDS instance. But when application code connected to that infrastructure, type safety stopped. Connection strings came from environment variables, database queries were strings, API responses were any.

With Encore, type safety extends throughout the stack. Database queries are type-checked:

interface User {
  id: number;
  email: string;
  name: string;
}

const user = await db.queryRow<User>`
  SELECT id, email, name FROM users WHERE email = ${email}
`;
// user is User | undefined, fully type-safe

API endpoints are type-safe:

export const getUser = api(
  { method: "GET", path: "/users/:email" },
  async ({ email }: { email: string }): Promise<User | undefined> => {
    return await db.queryRow<User>`SELECT * FROM users WHERE email = ${email}`;
  }
);

Service-to-service calls are type-safe when you import other services from ~encore/clients. The TypeScript compiler catches type mismatches, your IDE provides autocomplete for API parameters and database columns, and runtime errors from type mismatches are caught at compile time.

Local Development

Terraform CDK wasn't the best experience locally. Local development meant setting up Docker containers manually, writing docker-compose files, and configuring environment variables differently for local vs production. The local environment approximated production but never quite matched.

We designed Encore to run the same code locally and in production. Running encore run starts your application with local infrastructure - PostgreSQL databases, pub/sub messaging, object storage buckets - whatever your code declares. The local development dashboard shows your services, API documentation, database schema, distributed tracing, and logs. When you deploy, the same code runs with AWS resources instead of local ones, maintaining 1:1 parity between environments.

Automatic service flow visualization and architecture diagram

Working with Existing Infrastructure

If you have existing Terraform managing infrastructure, Encore can run alongside it. Use Terraform for your existing resources, Encore for new services. Encore services are just TypeScript or Go code - they can connect to existing databases, Redis instances, external APIs, or any other infrastructure through standard connection strings and environment variables.

Getting Started

Install the Encore CLI:

# macOS
brew install encoredev/tap/encore

# Linux
curl -L https://encore.dev/install.sh | bash

# Windows
iwr https://encore.dev/install.ps1 | iex

Create an application:

encore app create my-app --example=ts/hello-world
cd my-app

Run it locally:

encore run

The application runs at http://localhost:4000 with a development dashboard at http://localhost:9400. The dashboard shows your API endpoints, lets you test them, displays distributed tracing for requests, and includes a database inspector for viewing your schema and data.

When you're ready to deploy, connect your AWS account through Encore Cloud or self-host the deployment infrastructure. We handle provisioning everything your application declares.

What We Share with Terraform CDK

Terraform CDK and Encore share a core belief: infrastructure definitions belong in real programming languages, not domain-specific configuration languages. If you chose Terraform CDK because you wanted type safety, IDE autocomplete, and familiar programming constructs for infrastructure, we built Encore with the same philosophy.

Where we differ is in execution. Terraform CDK generated Terraform configs from your TypeScript, which meant managing state files, running synthesis steps, and deploying infrastructure separately from application code. We took the idea further: infrastructure declarations are part of the application code itself. When you write new SQLDatabase() in Encore, that's both application code (using a database) and infrastructure declaration (needs a database). We analyze your code and provision what it declares, directly in your AWS or GCP account.

If you were using Terraform CDK to provision databases, APIs, pub/sub, and similar resources, Encore can handle that workflow. You can't just swap CDK code for Encore code 1:1, but if you're starting fresh or migrating gradually, the TypeScript knowledge transfers directly - same language, same type safety, same IDE tooling. The main difference is that infrastructure declarations live in your application code rather than separate configuration files.

To sum it up: Encore provisions standard AWS and GCP resources directly in your account - VPCs, ECS clusters, RDS databases, load balancers, IAM roles. Since everything runs in your infrastructure, there's minimal lock-in. You can see and manage resources through your cloud console, costs appear in your existing billing, and your ops team keeps full access and control. Companies like Groupon use this in production, running it in their existing AWS organization alongside their current setup.

Learn more at encore.dev/docs or try the Quick Start guide.

[Boost]

Marcus Kohlberg — Tue, 16 Dec 2025 15:44:06 +0000

Encore Cloud 2.0 - Development Platform for the AI Era

Marcus Kohlberg for Encore ・ Dec 16

#cloud #devops #backend #node

Encore Cloud 2.0 - Development Platform for the AI Era

Marcus Kohlberg — Tue, 16 Dec 2025 15:43:50 +0000

We started Encore five years ago because developers were spending too much time configuring infrastructure and jumping through hoops, not building products.

That problem persists. AI agents can now scaffold entire backends in minutes, but running them well - with proper observability, and reliable, secure, infrastructure across multiple environments - still requires significant work.

Today, we're launching Encore Cloud 2.0, a big upgrade to our development platform that understands your code and automates the operations layer.

The problem

Before we get into what's new, we'd like to take a moment to expand on why we set out building Encore. I mean, what exactly is wrong with existing tools like Terraform?

These days, AI is already helpful in writing Terraform. But its potential usefulness is limited, because it lacks context.

For most teams, the "truth" of a system is scattered. Business logic lives in one place, infrastructure definitions in another, permissions somewhere else, plus there's those pesky yet inevitable manual changes in cloud consoles. There's no single authoritative model of how the system runs.

Without such a model, common questions require significant human effort to get right:

Which services actually need to talk?
What permissions are truly required?
How can we be sure this infra change won't break something?

Fragmentation turns operating your system into a game of "spot the difference" between your intent and your infrastructure.

Framework-defined infrastructure

We designed Encore to solve this by ensuring that the application code is the single source of truth for everything that impacts application behavior, so that we can derive a complete system model from it.

It works by providing an open source backend framework for TypeScript and Go, which comes with packages to define services and APIs, and infrastructure like databases, message queues, and scheduled jobs.

Unlike Terraform, you do not define specific cloud resources, configurations, or providers in code. You only express what is relevant to the application behavior.

In Encore.ts, creating a database object is new SQLDatabase("users"). An API endpoint is a function with the api() decorator. This is enough for Encore to understand what you're building, identify which services need which permissions, and generate everything needed to run it.

From your code, Encore Cloud automatically orchestrates:

Cloud Resources: Databases, caches, and queues
IAM Policies: Least-privilege permissions, generated automatically
Networking: Service discovery and secure connectivity
Observability: Tracing and metrics, wired out of the box
Documentation: Service catalog, API docs, and architecture diagrams

Because infrastructure details are not embedded in your code, the same application can run on different environments without modification. You create an environment with Encore Cloud and choose where it runs, on AWS or Google Cloud, and using what type of infrastructure, Kubernetes or serverless platforms.

Everything deploys to your own AWS or Google Cloud account by integrating directly with their APIs. Encore provisions resources with sane defaults, which you can tune in Encore Cloud or directly in your cloud provider without them being overridden.

With this approach, there's an intentional tradeoff; you partially give up having low-level control over individual cloud resources defined in code, in exchange for productivity, portability, and safety at the system level.

For teams that want to hand-tune every single resource, Terraform is likely the right tool. For teams that want to focus on application behavior and evolve infrastructure over time without rewrites, Encore optimizes for that path while providing easy-to-reach knobs and configuration options for key things.

Because your code is the source of truth, drift is effectively eliminated. If infrastructure is missing, Encore provisions it. If a resource is removed from your code, Encore marks it as "unused" so you can safely delete it when you're ready.

— But, what about lock-in? We're engineers ourselves and get why this matters, so we've designed Encore to reduce lock-in from the start. Learn more about migrating away

What's new in 2.0

Now let's get to the exciting bit, what's new.

Encore Cloud 2.0 builds on the foundation we've created over the past five years, and delivers an upgraded platform that feels less like "managing servers" and more like shipping product.

1. A redesigned operations dashboard

We've rebuilt the dashboard to reflect how engineers actually think about systems. It allows you to navigate large distributed applications across multiple environments, surfacing topology, deployments, and infrastructure state without the noise.

2. Full-stack observability

For teams using Encore.ts, metrics now live alongside traces and logs. You get a complete, correlated view of system behavior across services. No external agents to install, no dashboards to configure manually.

For teams using Encore.go where metrics was already available, you get an upgraded dashboard with more performant and usable graphs.

3. System transparency

Because Encore understands your system model, it maintains the artifacts that usually go stale. In this release we've improved the performance and usability of these tools:

Architecture Diagrams: Always up-to-date, generated from the live graph.
Service Catalog: A real-time inventory of what's running.
Local MCP Server: Allowing AI agents to inspect your system, and take actions like call endpoints, view traces, and more.

4. Zero-friction onboarding

We've streamlined the path from "new repo" to "production URL." With tighter GitHub integration, you can go from code to a fully provisioned cloud environment in minutes.

Jump in

Encore Cloud 2.0 is available now.

Deploy an example app to a free development environment, or book a demo to see how it works with a production system.

For teams already using Encore, the 2.0 dashboard features are rolling out automatically. Update to the latest CLI version using encore version update to start using metrics in Encore.ts.