Where Does SST Store Config and State?
SST projects define infrastructure in sst.config.ts with deployment state in .sst, both inside the project folder.
Last updated
SST co-locates infrastructure and application code in one project, and the filesystem shows it. The sst.config.ts file declares stages, providers, and stacks. The .sst folder accumulates deployment state, build artifacts, and local dev metadata as you work.
That division decides what to version. Config and stacks are the project; .sst is scratch that SST rebuilds. Stage-specific outputs nest inside per stage, so one folder can hold several environments without mixing. Wiping it is the standard unstick maneuver when deploys misbehave, since nothing in it is authoritative.
Where SST stores this, by platform
[ProjectDir]\sst.config.ts
Stage, provider, and stack definitions. The .sst folder beside it holds deploy state and caches. Wipe .sst to recover from stuck deploys; it regenerates fully.
[ProjectDir]/sst.config.ts
Same project-relative layout on macOS. sst dev writes extra local state here too, so stop dev sessions before wiping the folder.
[ProjectDir]/sst.config.ts
Same arrangement. CI runners start clean each time, which is why fresh-checkout deploys work: everything authoritative lives in the config and code.
Frequently asked questions
A deploy is stuck on stale state. What do I wipe?
Delete .sst and redeploy. It holds local deployment state and caches that regenerate from sst.config.ts and your code. Never commit it; the config file is the source of truth.
Should the .sst folder be committed?
Yes. Commit sst.config.ts, the stacks, and app code. The .sst directory is machine-local state, and the official template gitignores it from the start.
Notice an outdated path? Let us know.