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.
| Feature | Encore | AWS CDK | Pulumi | Terraform | Serverless Framework |
|---|---|---|---|---|---|
| Approach | Infrastructure from code | IaC (constructs) | IaC (imperative) | IaC (HCL) | IaC (YAML + plugins) |
| Language | TypeScript / Go | TypeScript, Python, Go, Java, C# | TypeScript, Python, Go, C#, Java | HCL | YAML |
| State management | None (no state file) | CloudFormation stacks | Managed or self-hosted | Remote state file | CloudFormation stacks |
| Cloud support | AWS, GCP (your account) | AWS only | AWS, GCP, Azure, 150+ providers | AWS, GCP, Azure, 4,000+ providers | AWS (primary), others via plugins |
| Infrastructure config | Zero (derived from app code) | Separate program files | Separate program files | Separate HCL files | serverless.yml |
| Live development | Full local infra (Postgres, Pub/Sub, tracing) | None | None | None | serverless-offline plugin |
| AI agent support | MCP server with full context | Limited | Pulumi AI | Limited | Limited |
| Best for | Teams who want zero infra management | AWS-only shops needing full control | Multi-cloud IaC in real languages | Multi-cloud with huge ecosystem | Simple Lambda functions |
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,
});
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.
encore build docker for standard Docker imagesEncore 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.
Want to jump straight to a running app? Clone this starter and deploy it to your own cloud.
See the quick start guide to get started, or book a 1:1 intro for a walkthrough.
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",
});
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 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,
});
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 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
}
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 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
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.
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.