SST Review 2026: Full-Stack Apps on AWS, Made Simple

SST (Serverless Stack) makes deploying to AWS not terrible. It provides TypeScript-first infrastructure as code, instant local development, and a web console for managing your apps. After using it for a production project, here's the honest review.

What SST Does

• Infrastructure as code — Define AWS resources in TypeScript
• Live Lambda dev — Test Lambda functions locally against real AWS resources
• Console — Web dashboard for logs, functions, and resources
• Frontend deployment — Deploy Next.js, Astro, Remix to CloudFront
• API routes — Create API Gateway endpoints easily
• Cron jobs — Schedule Lambda functions
• Auth — Built-in auth module (Google, GitHub, etc.)
• Databases — Easy RDS, DynamoDB, and Aurora setup

What I Like

TypeScript Infrastructure

Define your entire stack in TypeScript:

const bucket = new sst.aws.Bucket("Uploads")
const api = new sst.aws.Function("Api", {
  handler: "packages/api/src/index.handler",
  link: [bucket],
})
const site = new sst.aws.Nextjs("Site", {
  link: [api],
})

Type-safe, auto-completed, and readable. Compare this to writing CloudFormation YAML.

Live Lambda Development

The killer feature. sst dev connects your local code to real AWS resources. When you invoke a Lambda function, your local code runs — with access to real DynamoDB, S3, etc. Changes are instant (no deployment).

This solves the biggest pain of serverless development: the deploy-test-deploy cycle. With SST, development feels like working with a local server.

Resource Linking

SST's link system automatically injects permissions and environment variables:

const table = new sst.aws.Dynamo("Table", { ... })
const api = new sst.aws.Function("Api", {
  handler: "src/api.handler",
  link: [table], // Automatically gets DynamoDB permissions + table name
})

// In your function code:
import { Resource } from "sst"
const tableName = Resource.Table.name // Type-safe access

No manually configuring IAM policies or environment variables. Linking handles it.

The Console

Web-based dashboard for your SST apps. View function logs, invoke functions, browse S3 buckets, and query DynamoDB — all from a clean UI. Much better than the AWS Console for day-to-day work.

Multi-Stack Architecture

Organize resources into logical stacks. Deploy stacks independently. This matters for large apps where you don't want to redeploy everything for a small change.

What I Don't Like

AWS Lock-In

SST is AWS-only. Your infrastructure code doesn't work on GCP or Azure. If you might switch clouds, this is a concern. (Most startups won't switch.)

Learning Curve

You need to understand AWS services (Lambda, API Gateway, CloudFront, DynamoDB, IAM). SST simplifies the configuration but you still need to know what you're building on.

Cold Starts

Lambda cold starts remain an issue. SST doesn't solve this — it's an AWS limitation. Functions that haven't been invoked recently have 100-500ms cold starts.

Deployment Speed

Initial deployments are slow (CloudFormation under the hood). Subsequent updates are faster but still 30-60 seconds. Compare to Vercel's 10-second deployments.

Debugging Production Issues

Live Lambda dev is great locally. In production, you're debugging with CloudWatch logs and the SST Console. Less convenient than local debugging.

Pricing

SST itself is free and open source. You pay for AWS resources:

Resource	Typical Cost
Lambda	$0.20/million requests + compute time
API Gateway	$1/million requests
DynamoDB	$1.25/million writes, $0.25/million reads
S3	$0.023/GB storage
CloudFront	$0.085/GB transfer

A typical small SaaS: $5-50/month on AWS. Very cost-effective.

SST vs Alternatives

	SST	Vercel	Serverless Framework
Cloud	AWS	Vercel (abstracted)	AWS, GCP, Azure
Language	TypeScript	N/A (config)	YAML + JS
Local dev	✅ Live Lambda	✅ next dev	❌ (plugins)
Deploy speed	30-60s	10-15s	30-120s
Frontend	✅	✅ Best	❌
Pricing	AWS costs	$20/mo+	AWS costs
DX	✅✅✅	✅✅✅✅	✅✅

When to Use SST

✅ Use SST When

• Building on AWS and want good DX
• Need full control over infrastructure
• Running a SaaS with serverless architecture
• Want to keep costs low (pay-per-use)
• Team knows (or wants to learn) AWS

❌ Skip SST When

• Just need a Next.js deployment (use Vercel)
• Don't want to deal with AWS at all
• Need multi-cloud support
• Small project that doesn't need infrastructure control

FAQ

Is SST production-ready?

Yes. SST v3 (Ion) is stable and used in production by many companies.

SST vs CDK?

SST is built on top of Pulumi (v3) or CDK (v2). SST adds the developer experience layer: live dev, console, resource linking. Use SST instead of raw CDK.

Do I need AWS experience?

Basic understanding helps. SST simplifies AWS but doesn't hide it completely. You'll benefit from knowing Lambda, DynamoDB, and S3 concepts.

Can I deploy Next.js with SST?

Yes. new sst.aws.Nextjs("Site") deploys Next.js to CloudFront + Lambda. Works well but Vercel is simpler if you don't need AWS control.

Bottom Line

SST makes AWS development not suck. Live Lambda dev, TypeScript infrastructure, and resource linking create a genuinely good developer experience on top of AWS. The tradeoff is AWS lock-in and a learning curve.

Recommendation: Use SST if you're building on AWS and want the best DX possible. For simple web apps, Vercel is easier. For full-stack AWS applications with specific infrastructure needs, SST is the best tool available.