SST
Overview
SST (Serverless Stack) is a framework for building and deploying full-stack applications on AWS with high-level constructs for Lambda, API Gateway, DynamoDB, S3, and frontend frameworks. It features live local development connected to real AWS services, type-safe resource linking, and zero-config TypeScript support.
Instructions
- When defining infrastructure, use
sst.config.ts with typed components like sst.aws.Function, sst.aws.Api, sst.aws.Bucket, and sst.aws.Dynamo.
- When connecting resources, use the
link property on Functions to automatically grant IAM permissions and inject environment variables, and access linked resources via Resource.Name in handlers.
- When developing locally, use
sst dev which runs Lambda locally with hot reload while connected to real AWS services (DynamoDB, S3, SQS), with support for VS Code breakpoint debugging.
- When deploying, use
sst deploy --stage prod for named stages, sst deploy --stage pr-${PR_NUMBER} for preview environments, and sst remove --stage dev for teardown.
- When deploying frontends, use
sst.aws.Nextjs, sst.aws.Remix, or sst.aws.Astro components for SSR on Lambda with static assets on S3 + CloudFront.
- When managing secrets, use
sst secret set KEY value for encrypted, stage-specific secret storage.
- When organizing code, keep handlers thin in
packages/functions/ as orchestrators, and place business logic in packages/core/.
Examples
Example 1: Build a serverless API with DynamoDB
User request: "Create a REST API on AWS with DynamoDB using SST"
Actions:
- Define DynamoDB table and API Gateway in
sst.config.ts
- Link the table to API handler functions for automatic permissions
- Implement CRUD handlers accessing
Resource.MyTable.name
- Run
sst dev for live local development against real AWS services
Output: A serverless REST API with type-safe resource access and live debugging.
Example 2: Deploy a Next.js app with preview environments
User request: "Deploy my Next.js app on AWS with per-PR preview environments"
Actions:
- Configure
sst.aws.Nextjs component with custom domain and linked resources
- Set up CI to run
sst deploy --stage pr-${PR_NUMBER} for each pull request
- Link backend resources (API, database) to the Next.js deployment
- Add cleanup step with
sst remove when PR is closed
Output: A production Next.js deployment on AWS with isolated preview environments for each PR.
Guidelines
- Use
link instead of manual IAM policies; SST generates least-privilege permissions automatically.
- Access linked resources via
Resource.Name in handlers; never hardcode table names or bucket ARNs.
- Use
sst dev for daily development; it is faster than deploying to AWS on every change.
- Create per-developer stages (
sst dev --stage alice) so each developer gets isolated AWS resources.
- Keep handlers thin: business logic in
packages/core/, handlers in packages/functions/.
- Use
sst secret for API keys and credentials; they are encrypted and stage-specific.
- Set up
sst deploy --stage pr-${PR_NUMBER} in CI for preview environments on every pull request.
1---2name: sst3description: Assists with building and deploying full-stack serverless applications on AWS using SST. Use when defining Lambda functions, API Gateway routes, DynamoDB tables, S3 buckets, or deploying Next.js/Remix/Astro with SSR on AWS. Trigger words: sst, serverless stack, sst dev, sst deploy, aws lambda, sst ion, resource linking.4license: Apache-2.05---67# SST89## Overview1011SST (Serverless Stack) is a framework for building and deploying full-stack applications on AWS with high-level constructs for Lambda, API Gateway, DynamoDB, S3, and frontend frameworks. It features live local development connected to real AWS services, type-safe resource linking, and zero-config TypeScript support.1213## Instructions1415- When defining infrastructure, use `sst.config.ts` with typed components like `sst.aws.Function`, `sst.aws.Api`, `sst.aws.Bucket`, and `sst.aws.Dynamo`.16- When connecting resources, use the `link` property on Functions to automatically grant IAM permissions and inject environment variables, and access linked resources via `Resource.Name` in handlers.17- When developing locally, use `sst dev` which runs Lambda locally with hot reload while connected to real AWS services (DynamoDB, S3, SQS), with support for VS Code breakpoint debugging.18- When deploying, use `sst deploy --stage prod` for named stages, `sst deploy --stage pr-${PR_NUMBER}` for preview environments, and `sst remove --stage dev` for teardown.19- When deploying frontends, use `sst.aws.Nextjs`, `sst.aws.Remix`, or `sst.aws.Astro` components for SSR on Lambda with static assets on S3 + CloudFront.20- When managing secrets, use `sst secret set KEY value` for encrypted, stage-specific secret storage.21- When organizing code, keep handlers thin in `packages/functions/` as orchestrators, and place business logic in `packages/core/`.2223## Examples2425### Example 1: Build a serverless API with DynamoDB2627**User request:** "Create a REST API on AWS with DynamoDB using SST"2829**Actions:**301. Define DynamoDB table and API Gateway in `sst.config.ts`312. Link the table to API handler functions for automatic permissions323. Implement CRUD handlers accessing `Resource.MyTable.name`334. Run `sst dev` for live local development against real AWS services3435**Output:** A serverless REST API with type-safe resource access and live debugging.3637### Example 2: Deploy a Next.js app with preview environments3839**User request:** "Deploy my Next.js app on AWS with per-PR preview environments"4041**Actions:**421. Configure `sst.aws.Nextjs` component with custom domain and linked resources432. Set up CI to run `sst deploy --stage pr-${PR_NUMBER}` for each pull request443. Link backend resources (API, database) to the Next.js deployment454. Add cleanup step with `sst remove` when PR is closed4647**Output:** A production Next.js deployment on AWS with isolated preview environments for each PR.4849## Guidelines5051- Use `link` instead of manual IAM policies; SST generates least-privilege permissions automatically.52- Access linked resources via `Resource.Name` in handlers; never hardcode table names or bucket ARNs.53- Use `sst dev` for daily development; it is faster than deploying to AWS on every change.54- Create per-developer stages (`sst dev --stage alice`) so each developer gets isolated AWS resources.55- Keep handlers thin: business logic in `packages/core/`, handlers in `packages/functions/`.56- Use `sst secret` for API keys and credentials; they are encrypted and stage-specific.57- Set up `sst deploy --stage pr-${PR_NUMBER}` in CI for preview environments on every pull request.