SST vs Kamal 2026: Which Deployment Tool Wins for Your Stack?

TL;DR: SST (Serverless Stack) is built for AWS-first teams deploying serverless apps with zero DevOps overhead. Kamal is for developers who want simple containerized deployments on any cloud or bare metal. Pick SST if you’re all-in on AWS; pick Kamal if you want escape hatches and portability.

Last updated: March 2026 · John Calloway

The Deployment Showdown Nobody Asked For (But Needs)

Here’s the thing: deployment has become weirdly polarized. You’ve got the serverless zealots on one side preaching about managed services and infinite scale. Then you’ve got the container enthusiasts saying “just Docker it and move on.” Both are right. Both are wrong. And that’s exactly why comparing SST and Kamal matters.

I spent three weeks last year migrating a side project from a traditional VPS setup to figure this out. The experience was… educational. SST promised to make AWS feel like a local development framework. Kamal promised to make Docker deployment so simple I wouldn’t need to hire a DevOps person. Both delivered, but in completely different ways.

Real talk: SST has grown 40% in GitHub stars year-over-year. Kamal, the newer upstart from the Rails world, is at 8,500 stars and accelerating. They’re solving the same problem—how do I deploy my app without becoming a DevOps engineer—but their answers are fundamentally different.

Who should read this: Full-stack developers, CTOs, and startup founders trying to pick between serverless and containerized deployments without spending six months researching.

What SST Actually Is (And Why It’s Not Just “Serverless Glue”)

SST started as a framework for building serverless applications on AWS. Today it’s become something closer to a developer experience layer that sits on top of the AWS infrastructure you already have.

The core pitch: instead of juggling CloudFormation templates, Lambda config files, API Gateway documentation, and RDS setup, you write TypeScript code. That code describes your infrastructure. SST synthesizes it into AWS resources and handles the orchestration.

Here’s a practical example. With SST, you write:

import { StackContext, Api, RDS } from "sst/constructs";

export function API({ stack }: StackContext) {
  const db = new RDS(stack, "db", {
    engine: "postgresql15.1",
    defaultDatabaseName: "myapp",
  });

  const api = new Api(stack, "api", {
    routes: {
      "GET /posts": "src/posts.list",
      "POST /posts": "src/posts.create",
    },
  });

  api.bind([db]);
  stack.addOutputs({ ApiEndpoint: api.url });
}

That’s it. No Terraform. No CloudFormation JSON syntax. No IAM role juggling. SST infers what permissions your Lambda functions need, wires up database connections, handles environment variables.

The real advantage: SST includes a local development environment that mimics AWS behavior. You run sst dev and get hot reloads, live debugging, and local versions of DynamoDB, S3, and SQS. It’s genuinely comfortable. I can develop against production-like infrastructure on my laptop.

The catch: You’re fully committed to AWS. SST doesn’t run on Hetzner, DigitalOcean, or your own Kubernetes cluster. If you ever want to migrate off AWS, you’re rewriting deployment infrastructure. That’s not a small concern for bootstrapped founders.

Who SST works for: ✅ AWS-native teams
✅ Startups that want infrastructure-as-code without hiring DevOps
✅ Projects where serverless economics matter (bursty traffic, pay-per-invocation)
✅ TypeScript developers who like DX polish
❌ Multi-cloud strategies
❌ Teams that need on-prem deployment
❌ Projects with long-running background jobs (Lambda’s 15-minute timeout kills this)

Kamal: The Rails Way, Now For Everything

Kamal came out of 37signals’ need to deploy Rails apps without Kubernetes, Heroku, or cloud vendor lock-in. The philosophy is almost brutally simple: Docker containerize your app, push it to any server that has SSH access, pull the image, and run it.

The deployment config looks like this:

service: myapp

image: myusername/myapp

servers:
  web:
    hosts:
      - 192.168.1.1
      - 192.168.1.2

registry:
  server: ghcr.io
  username: myusername
  password:
    - KAMAL_REGISTRY_PASSWORD

Then you run kamal deploy and it:

1. Builds your Docker image
2. Pushes it to the registry
3. SSHes into each server
4. Pulls the new image
5. Stops the old container
6. Starts the new one with zero downtime

That’s genuinely the whole thing. No orchestration layer. No Kubernetes learning curve. No managed service lock-in.

Why this matters: I deployed a side project to a $6/month Hetzner VPS using Kamal. Total setup time: 20 minutes. Comparing that to my SST setup where I’m paying for RDS, Lambda invocations, API Gateway, NAT gateway… the economics are very different.

Kamal also includes built-in features that feel like they should be obvious but usually aren’t:

• Zero-downtime deployments (rolling restarts)
• Automatic asset compilation for Rails/Node
• Health checks
• Secret management via environment files
• Rollback support

The trade-offs: ✅ Works on any cloud or bare metal (Hetzner, Linode, your basement server, whatever)
✅ No vendor lock-in
✅ Cheap to run ($6/month VPS tier is genuinely viable)
✅ Simpler mental model (just Docker + SSH)
✅ Growing ecosystem (Kamal 2.0 added active-active deployment)
❌ You still own the container, health checks, and scaling
❌ No built-in autoscaling (you handle that yourself)
❌ Database backups are your problem
❌ Requires SSH access (no serverless option)

Head-to-Head Comparison

When to Pick SST

You should use SST if:

You’re AWS-first by design. Not because you have to, but because you’ve evaluated options and AWS’s regional availability, service breadth, or specific features (SQS, Kinesis, AppSync, whatever) genuinely fit your use case.

Your workload is bursty. A SaaS that gets traffic spikes at certain hours? Serverless economics might save you 70% compared to running containers 24/7. But run the math—don’t assume.

Your team is TypeScript-heavy. SST’s DX is genuinely excellent for TS developers. The type safety of defining infrastructure in code is real. I’ve caught bugs at deploy-time that would’ve been runtime issues with YAML.

You don’t have DevOps bandwidth. SST handles patching, scaling, routing, and most operational concerns. Your job is to write code. That’s genuinely valuable for small teams.

You need serverless debugging. SST’s sst dev command is the closest thing to a local Lambda environment that actually works. If you’re building Lambda-heavy workflows, this is worth the price of admission alone.

When to Pick Kamal

You should use Kamal if:

You want multi-cloud optionality. Deploy to AWS one month, Hetzner the next, keep it portable. Kamal doesn’t care. This is genuinely powerful for founders who don’t want to bet everything on one provider’s pricing.

Cost is a hard constraint. A $6/month VPS running Kamal beats nearly any AWS bill. If you’re bootstrapped and paranoid about cloud costs, Kamal lets you be paranoid on someone else’s hardware.

Your workload is stable and predictable. Batch jobs, background workers, monoliths—if your CPU and memory needs don’t fluctuate wildly, fixed-cost containers beat variable Lambda pricing every time.

You run stateful services. Databases, caches, message queues that don’t fit the serverless model. Kamal lets you run anything that fits in a container.

You need simplicity more than scale. Early-stage projects don’t need to auto-scale to 1,000 concurrent users. They need to deploy reliably and cheaply. Kamal does that.

Your team has container experience. If you already know Docker, Kamal feels natural. If you’re learning Docker specifically to use Kamal, SST might be less friction.

The Real Decision Framework

Stop comparing features for a second. Here’s what actually matters:

1. How locked in are you to AWS?

• Yes, intentionally → SST
• No, want optionality → Kamal

2. What’s your cost sensitivity?

• Minimal, prefer managed services → SST
• Bootstrapped, want predictable spend → Kamal

3. How much ops work can you absorb?

• None, want managed → SST
• Some, you’ve got it handled → Kamal

4. What’s your traffic pattern?

• Spiky, bursty → SST (serverless economics win)
• Steady, predictable → Kamal (fixed costs win)

5. How’s your AWS knowledge?

• Deep → SST (maximize the advantage)
• Shallow → Kamal (fewer concepts to learn)

Honest take: I see a lot of small teams picking SST because it feels more sophisticated. Then six months in, they’re optimizing Lambda Cold starts and getting surprise AWS bills. They would’ve been happier with Kamal.

Equally, I see teams pick Kamal because it’s simpler, then struggle when they need autoscaling or multi-region failover that containers don’t easily provide.

Real-World Costs: The Math Nobody Does

Let me put actual numbers on this because it matters.

Typical Node.js app on SST:

• API Gateway: ~$3.50/million requests
• Lambda: ~$0.20 per million invocations + $0.0000166667 per GB-second
• RDS (db.t3.micro): ~$15/month
• NAT Gateway: ~$32/month (if accessing external APIs)
• DynamoDB: ~$25/month (if using it)
• Estimated monthly cost: $80-120 at modest scale

Same app on Kamal:

• Hetzner 2vCPU, 4GB RAM: $6/month
• Database hosting (Render or Supabase): ~$15/month
• Object storage (Backblaze B2): ~$1/month
• Estimated monthly cost: $22/month

The gap widens if you have steady traffic. It narrows if you have traffic spikes that serverless handles better.

The Ecosystem Check

SST has grown beyond just a framework. It’s become an opinionated way to think about AWS infrastructure for full-stack teams. The community is strong, examples are abundant, and the DX polish is real.

Kamal is newer but has serious backing (37signals). The community is smaller but vocal. You get fewer off-the-shelf solutions, but that often means more learning and fewer opinions forced on you.

If ecosystem matters (it usually does), SST has the edge. But Kamal’s ecosystem is growing and suffices for most use cases—you’re not lacking Rails guides, Django examples, Node setups, etc.

Bottom Line

Pick SST if you’re building a modern full-stack application on AWS, your team understands AWS, and you want the smoothest possible developer experience without operational overhead.

Try SST with your next project → — the sst dev local development experience alone makes it worth the learning curve if you’re committed to AWS.

Pick Kamal if you want simplicity, cost predictability, portability, and you’re comfortable owning some operational responsibilities. It’s the modern equivalent of “just ship it on a VPS” and that’s powerful.

Get started with Kamal → — 15 minutes to your first deployment if you know Docker.

Real talk: this isn’t a winner-take-all situation. SST and Kamal will coexist because they solve legitimately different problems. Your job is to be honest about which problem you actually have.

Resources

• AWS Lambda pricing calculator — plug in your expected invocations to model SST costs before committing
• Kamal 2.0 release notes — David’s announcement of active-active deployments changes the game for multi-server setups
• SST documentation: Local development — the sst dev command is why developers switch to SST; read this first
• Hetzner pricing — run the numbers on bare-metal deployment costs for your workload

— John Calloway writes about developer tools, deployment, and building profitable side projects at Calloway.dev. Subscribe to The Dev Stack Weekly → for free weekly deep-dives.

You Might Also Enjoy

• Why “Warranty Void If Regenerated” Stickers Are the New Frontier in AI Hardware Protection and What Developers Need to Know
• Why OpenAI’s IPO Plans Could Reshape the AI Industry Forever (And What Developers Need to Know)
• Best ChatGPT Alternatives 2026: 12 AI Models That Actually Beat OpenAI