How to delete your SST (Serverless Stack) account

About deleting your SST (Serverless Stack) account

SST (Serverless Stack) is an open-source framework designed to help developers build, debug, and deploy full-stack serverless applications on AWS. Unlike traditional SaaS platforms that store project configurations on their own servers, SST operates as a framework that interfaces directly with your personal AWS environment. When you use SST, your code and infrastructure definitions remain under your control, but the framework generates extensive metadata and configuration files to manage your AWS resources.

Users may choose to remove their SST-managed projects for several reasons, including:

• Decommissioning legacy applications to reduce monthly AWS billing costs.
• Migrating from serverless infrastructure to containerized or on-premise solutions.
• Security requirements necessitating the total erasure of development environments.
• Simplifying your local machine by removing unused SST CLI installations.

Why remove SST resources?

• Eliminating recurring charges from AWS Lambda, DynamoDB, and API Gateway instances created by SST.
• Reducing your attack surface by removing exposed cloud endpoints.
• Cleaning up AWS IAM roles and permissions created during the SST bootstrapping process.

What happens to your data

Because SST is a local framework, it does not store your application code or sensitive production data in a proprietary cloud of its own. However, the deletion process is twofold: you must handle both the local configuration and the live cloud resources.

When you run the sst remove command, the framework executes a teardown of the CloudFormation stacks it previously created. The following data points are typically involved in this removal process:

• CloudFormation stacks: The structural blueprint of your AWS services.
• State files: SST maintains a local or remote state file (often in S3) that tracks resource mapping; this should be purged.
• Local logs: Terminal history and local .sst directories contain deployment metadata.
• IAM Roles: Custom permissions created for your application stack.

Privacy considerations

While SST is open-source and respects local-first development, privacy-conscious developers should be aware of how their infrastructure metadata is handled. SST relies on the AWS SDK, meaning any data you process remains within your AWS account boundaries. To maximize privacy, follow these tips:

• Always run sst remove to ensure AWS resources are not left in a 'zombie' state.
• Manually inspect your S3 buckets to ensure that SST-created deployment artifacts have been purged.
• Rotate your AWS access keys if you believe your local environment configurations were compromised.
• Audit your CloudTrail logs to confirm that all infrastructure-deleting actions initiated by the SST CLI were successful.

Frequently Asked Questions

Does SST store my source code?

No, SST is a local development framework; it reads your source code from your local machine to deploy it to AWS, but it does not transmit your code to a central SST server.

What happens if I delete my AWS account but leave SST stacks active?

Your AWS account deletion is the final authority, but leaving stacks active without a parent account can lead to dangling resources that are difficult to track. Always remove the stacks first.

Is there a central dashboard to delete my SST profile?

No, SST does not have a central SaaS account profile. Every interaction is managed via your local CLI and your AWS credentials.

Does the 'sst remove' command delete my database data?

Yes, if your SST project creates a DynamoDB table, running the remove command will delete the table and all contained data unless you have explicitly configured the removal policy to 'Retain'.

How do I check if my SST stacks are fully removed?

Navigate to the AWS CloudFormation console in your browser, select your region, and ensure no stacks associated with your SST project are listed in the 'DELETE_COMPLETE' or active status.