The Serverless Stack (SST) Platform

Tags: ,

Serverless Stack ( is another rapid serverless application development platform for AWS. SST (as it is also known) promises to streamline development and allow local debug of AWS Lambdas.

It uses the AWS CDK and a set of its own constructs and configuration settings to make building serverless applications easier, and provide a more helpful developer experience by providing live debugging and updating of Lambda functions at development time.

Lambdas support JavaScript, TypeScript, Golang, Python, C# and F#, though at the moment the CDK constructs are only written in TypeScript.

SST also provides a live dashboard for your applications. A deployment tool, SEED (, provides incremental, parallel builds of services, and has a free tier for individuals.

SST applications are created via npm. For example:

$ npm init sst                                               ⬡ 16.13.0 
Need to install the following packages:
Ok to proceed? (y) y
? Select a template (Use arrow keys)
❯ typescript-starter 

? Select a template typescript-starter
? Destination directory demo-app
✔ Copied template files

Next steps:
  1: cd demo-app
  2: npm install (or pnpm install, or yarn)
  3: npm start

Once completed, you'll have a project with a fairly familiar Lambda-driven project structure. The stacks folder is where you'd use the CDK to configure your stacks. The Lambda code lives in api, and you can build other folders as needed for client acts in React, etc.

├── api
│   ├── functions
│   │   └── lambda.ts
│   ├── package.json
│   ├── test
│   │   └── sample.test.ts
│   └── tsconfig.json
├── package.json
├── sst.json
├── stacks
│   ├── MyStack.ts
│   └── index.ts
├── tsconfig.json
└── vitest.config.ts

If using TypeScript, you'll have the typical unit tests with the npm test command. If you want to run a watch command, you can issue npx vitest command and it will start and watch the files for changes.

A Simple Unit Test

Given the basic lambda generated in api/functions/lambda.ts:

import { APIGatewayProxyHandlerV2 } from "aws-lambda";

export const handler: APIGatewayProxyHandlerV2 = async (event) => {
  return {
    statusCode: 200,
    headers: { "Content-Type": "text/plain" },
    body: `Hello, World! Your request was received at ${event.requestContext.time}.`,

… a simple unit test would be something like this:

import { describe, it, expect } from "vitest";
import {handler} from '../functions/lambda';

describe("sample", () => {
  it("should work", async () => {
    const result = await handler({
      foo: 'bar',
      requestContext: {
        time: new Date('12/20/2021')
    expect(result.body).toContain('Hello, World');

For some reason the stack template only gives the barest hello world test sample, so this should be easy to fix as a contribution. But at least you get a serverless function and a test provided out of the gate to start with.


Like SAM and the Serverless framework, deployments with SST ultimately use CloudFormation stacks. The stacks in this case are girded by CDK constructs. For example, the Lambda is deployed using an API Gateway via:

import { StackContext, Api } from "@serverless-stack/resources";

export function MyStack({ stack }: StackContext) {
  const api = new Api(stack, "api", {
    routes: {
      "GET /": "functions/lambda.handler",
    ApiEndpoint: api.url

You'll note that the Api construct there isn't the built-in CDK ApiGateway, rather a simplified one with some sensible defaults. The same thing in the CDK would be much longer, including AWS Roles, Policies, an API Gateway, Lambda, and more. If using Serverless SAM, you’d be using the SAM constructs in CloudFormation instead with the SAM Resource API, then adding other resources via the CDK.


SST, like SAM, will deploy your stack for you, after normalizing it from the SST and CDK constructs into a CloudFormation template.

When running your stack for the first time after checkout SST will prompt you to deploy with a stage name. I've given mine the name demo.

While it deploys your stack itself, it also deploys a sophisticated debug environment, where it can deploy code changes in real time, and from which it provides a websocket-connected live debugging feature.

$ npm start                                                  ⬡ 16.13.0 

> demo-app@0.0.0 start
> sst start

Look like you’re running sst for the first time in this directory. Please enter a stage name you’d like to use locally. Or hit enter to use the one based on your AWS credentials (kennethrimple): demo
Using stage: demo
Preparing your SST app

 Deploying debug stack
... lots of output...

Stack demo-demo-app-debug-stack
  Status: deployed
    BucketArn: arn:aws:s3:::demo-demo-app-debug-stack-bucket83908e77-jfde7tn8897i
    BucketName: demo-demo-app-debug-stack-bucket83908e77-jfde7tn8897i
    Endpoint: wss://

Stack demo-demo-app-MyStack
  Status: deployed

 Starting Live Lambda Dev

SST Console:
Debug session started. Listening for requests...

After this is finished, I counted 45 separate deployed artifacts, including:

  • The debug stack, which accounts for 33 of the items, powers the CLI and SST Console interactions (see below). This will not grow significantly over time.
  • The application stack, which is the other 12, contains the API Gateway, Log Group, an IAM Policy and Role, Lambda Function and integration, Lambda execution permission, which would be the bare minimum deployment for the stack we generated.

The SST Console

The SST console provides access to many of the resources you've created, including testers for the API Gateway functions, the Lambdas themselves, Dynamo table data viewers, Cognito users creation and more.

The SST Console executing an API Gateway function that modifies an S3 bucket:

The SST Console reviewing local logging for the API Gateway call

The SST Console viewing bucket contents

Who Is This For?

The SST platform will help developers build AWS serverless applications without having to dive into the details of many common CDK constructs. It will help developers debug their code, and manage their applications without too much effort. It is an early 1.x release, so I assume it will improve over time and expand to cover more services and provide more abstractions. It could use more documentation and adoption to really bring it into its own, but it looks promising and is something to watch over the coming year.