04/17/26

SST Alternatives in 2026

What to use now that SST is in maintenance mode

8 Min Read

SST made deploying TypeScript applications to AWS simpler than raw CloudFormation or CDK. The high-level components, live Lambda debugging, and SST Console gave teams a better developer experience than piecing together infrastructure tools manually. In 2025, SST moved to maintenance mode, and teams that built on it are evaluating what comes next.

Most SST alternatives are other Infrastructure as Code tools that require you to write and maintain infrastructure configuration separately from your application. This guide covers those options alongside the approach that eliminates separate infrastructure configuration entirely.

SST Alternatives: An Overview

FeatureEncoreAWS CDKPulumiTerraformServerless Framework
ApproachInfrastructure from codeIaC (constructs)IaC (imperative)IaC (HCL)IaC (YAML + plugins)
LanguageTypeScript / GoTypeScript, Python, Go, Java, C#TypeScript, Python, Go, C#, JavaHCLYAML
State managementNone (no state file)CloudFormation stacksManaged or self-hostedRemote state fileCloudFormation stacks
Cloud supportAWS, GCP (your account)AWS onlyAWS, GCP, Azure, 150+ providersAWS, GCP, Azure, 4,000+ providersAWS (primary), others via plugins
Infrastructure configZero (derived from app code)Separate program filesSeparate program filesSeparate HCL filesserverless.yml
Live developmentFull local infra (Postgres, Pub/Sub, tracing)NoneNoneNoneserverless-offline plugin
AI agent supportMCP server with full contextLimitedPulumi AILimitedLimited
Best forTeams who want zero infra managementAWS-only shops needing full controlMulti-cloud IaC in real languagesMulti-cloud with huge ecosystemSimple Lambda functions

Encore

Encore takes a different approach from SST and every other tool on this list. Instead of writing infrastructure configuration in a separate file, you declare what your application needs directly in your TypeScript or Go code. Databases, Pub/Sub topics, cron jobs, object storage, and caching are declared as objects in the same files where you use them. Encore's open-source framework parses the code to understand infrastructure requirements, and Encore Cloud provisions the corresponding AWS or GCP resources in your own account.

For teams coming from SST, the development experience is similar in spirit: you write TypeScript and infrastructure appears. The difference is that Encore doesn't use CloudFormation, Pulumi, or any IaC engine under the hood. Infrastructure is derived directly from your application code without a synthesis or plan/apply step.

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

// Provisions RDS on AWS or Cloud SQL on GCP with sensible defaults (uses Docker Postgres locally).
const db = new SQLDatabase("orders", { migrations: "./migrations" });

// Provisions SNS+SQS on AWS or GCP Pub/Sub on GCP with sensible defaults (in-memory locally).
const orderEvents = new Topic<OrderEvent>("order-events", {
  deliveryGuarantee: "at-least-once",
});

export const createOrder = api(
  { method: "POST", path: "/orders", expose: true, auth: true },
  async (req: CreateOrderRequest): Promise<Order> => {
    const order = await db.queryRow`
      INSERT INTO orders (customer_id, total)
      VALUES (${req.customerId}, ${req.total})
      RETURNING *`;
    await orderEvents.publish({ orderId: order!.id, total: order!.total });
    return order!;
  }
);

// Provisions CloudWatch Events on AWS or Cloud Scheduler on GCP.
const cleanup = new CronJob("daily-cleanup", {
  title: "Clean up expired orders",
  schedule: "0 2 * * *",
  endpoint: cleanupExpiredOrders,
});

Why teams choose Encore over other SST alternatives

SST's strength was reducing the distance between application code and infrastructure. Encore eliminates that distance entirely. There's no sst.config.ts file, no link system, no state backend to manage. Your application code is the infrastructure definition.

For teams that valued SST's live development experience, Encore provides something comparable: encore run starts your app with real Postgres, Pub/Sub, and distributed tracing locally, without Docker Compose or mock services.

Encore Cloud deploys to your own AWS or GCP account. Encore also deploys to Kubernetes clusters on EKS and GKE. You get built-in distributed tracing, a service catalog, and preview environments for every PR.

Key features

  • Infrastructure from code: databases, Pub/Sub, cron, caching, object storage, secrets
  • Deploys to your own AWS or GCP account (also supports EKS and GKE)
  • Built-in distributed tracing, logging, and metrics
  • Preview environments for every PR
  • encore build docker for standard Docker images
  • MCP server for AI agent integration

Good to know

Encore supports TypeScript and Go, and provisions infrastructure on AWS and GCP. If you need Azure, or if your infrastructure requirements go beyond what Encore's primitives cover, you can use Encore's Terraform provider to reference Encore-managed resources in your own Terraform configurations.

Try Encore

Deploy with Encore

Want to jump straight to a running app? Clone this starter and deploy it to your own cloud.

Deploy

See the quick start guide to get started, or book a 1:1 intro for a walkthrough.


AWS CDK

AWS CDK is the most direct SST replacement for teams committed to AWS. SST v2 was built on CDK, so the constructs and patterns are familiar. CDK lets you define AWS resources in TypeScript, Python, Go, Java, or C#, and synthesizes them into CloudFormation templates.

CDK's high-level constructs bundle common patterns. A single ApplicationLoadBalancedFargateService creates a Fargate service, load balancer, target group, security groups, and IAM roles together.

import * as cdk from "aws-cdk-lib";
import * as rds from "aws-cdk-lib/aws-rds";
import * as ec2 from "aws-cdk-lib/aws-ec2";

const vpc = new ec2.Vpc(this, "VPC");

const db = new rds.DatabaseInstance(this, "Orders", {
  engine: rds.DatabaseInstanceEngine.postgres({
    version: rds.PostgresEngineVersion.VER_16,
  }),
  vpc,
  instanceType: ec2.InstanceType.of(ec2.InstanceClass.T4G, ec2.InstanceSize.MICRO),
  databaseName: "orders",
});

Key features

  • Define AWS resources in TypeScript with full type safety
  • High-level constructs for common patterns
  • Construct Hub with community-contributed patterns
  • CDK Migrate to import existing CloudFormation stacks

Good to know

CDK is AWS only. The CloudFormation layer underneath has its own limitations: stack size limits, slow rollbacks on failure, and occasional stuck resources. CDK still requires maintaining infrastructure code separately from application code, and you still need a deployment pipeline. SST's live Lambda development and Console are not part of CDK.


Pulumi

Pulumi replaces HCL with real programming languages and works across AWS, GCP, Azure, and 150+ other providers. SST v3 actually used Pulumi under the hood, so teams familiar with SST's Ion architecture already know the Pulumi model.

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

const db = new aws.rds.Instance("orders", {
  engine: "postgres",
  engineVersion: "16",
  instanceClass: "db.t4g.micro",
  dbName: "orders",
  username: "app",
  password: dbPassword,
});

Key features

  • Infrastructure in TypeScript, Python, Go, C#, Java
  • 150+ cloud providers
  • Pulumi Cloud for managed state and deployments
  • Pulumi AI for generating IaC from prompts

Good to know

Pulumi is still IaC. You write infrastructure configuration in a separate program from your application code. The state file exists, the plan/apply cycle exists, and infrastructure changes are a separate PR from application changes. If your frustration with SST was about the IaC model itself, Pulumi shares that model.


Terraform

Terraform is the most widely used IaC tool with 4,000+ providers. If you're moving from SST and want the broadest ecosystem with the most community support, Terraform is the established option.

resource "aws_db_instance" "orders" {
  identifier     = "orders"
  engine         = "postgres"
  engine_version = "16"
  instance_class = "db.t4g.micro"
  db_name        = "orders"
  username       = "app"
  password       = var.db_password
}

Key features

  • 4,000+ providers covering every cloud service
  • Massive community with extensive modules and tutorials
  • HCL is declarative and predictable
  • HCP Terraform for managed state and runs

Good to know

Going from SST's TypeScript experience to HCL is a step backward in developer experience. State management, the two-codebase problem, and the plan/apply cycle all require operational investment. IBM's acquisition of HashiCorp and the BSL license change are also worth considering. OpenTofu is the open-source fork if licensing matters.


Serverless Framework

Serverless Framework is the original tool for deploying Lambda functions. If your SST project was primarily Lambda-based and you want a simpler alternative to SST's abstractions, Serverless Framework is a straightforward option.

# serverless.yml
service: orders-api
provider:
  name: aws
  runtime: nodejs20.x
functions:
  createOrder:
    handler: src/orders.create
    events:
      - http:
          path: /orders
          method: post

Key features

  • YAML-based configuration for Lambda functions
  • Large plugin ecosystem (1,000+ plugins)
  • Simple deployment model for Lambda-based architectures
  • Dashboard for monitoring and troubleshooting

Good to know

Serverless Framework is built around Lambda. If your backend needs containers, long-running processes, or persistent connections, the framework doesn't cover those use cases. The YAML configuration becomes verbose for complex applications. Serverless Inc. has shifted focus to their dashboard and observability products, and the framework itself receives less active development than it used to.


How to choose

Teams leaving SST are usually looking for one of two things: a similar developer experience with continued active development, or a way to simplify their infrastructure story further.

AWS CDK is the most familiar option for SST v2 users. The constructs and patterns carry over. You lose SST's developer experience features (live development, Console) but gain a stable, well-maintained tool backed by AWS.

Pulumi is the closest to SST v3's architecture since SST used Pulumi under the hood. If you were comfortable with SST v3's model, Pulumi gives you the same engine with broader cloud support.

Terraform offers the broadest ecosystem. If multi-cloud support and community resources matter more than developer experience, Terraform is the established default. OpenTofu is the open-source option.

Serverless Framework works for Lambda-heavy architectures that don't need the abstractions SST provided.

Encore is for teams who want to go further than SST went. SST reduced the configuration required to deploy to AWS. Encore eliminates it. Your application code declares what it needs, and the platform provisions it in your AWS or GCP account with sensible defaults and built-in observability. For teams building TypeScript or Go backends who valued SST's developer experience and want to stop maintaining infrastructure configuration entirely, Encore is the most direct path forward.

Ready to build your next backend?

Encore is the Open Source framework for building robust type-safe distributed systems with declarative infrastructure.