SST 4

Apply the Node.js 24 and TypeScript 7 prompts first for the corresponding application runtime and compiler. These rules cover SST 4 configuration, AWS and Cloudflare components, linking, secrets, state, development, and deployment, and were checked against 4.17.1.

Configuration and deployment authority

• Lock the sst package, which installs the CLI and provides the SDK, in the lockfile, and return a version constraint from app() that matches the locked release so the CLI refuses every command when a different SST version runs the config; change the lockfile and the constraint together. Review provider versions in app().providers and run sst install after changes; boolean provider entries are rejected, and providers other than AWS and Cloudflare require an explicit version.
• Set Lambda runtime: "nodejs24.x" for this baseline and use a supported Node.js release for local execution. Do not treat older names accepted by SST's runtime type as evidence of current AWS support, or treat Cloudflare's nodejs_compat flag as a Node.js 24 runtime.
• Treat sst.config.ts, its imports, component transforms, build commands, and console.autodeploy.workflow as privileged executable code. Even sst diff evaluates configuration; never evaluate an untrusted checkout with production credentials, secrets, or state access.
• Allowlist deployment stages and map each to a fixed account, region, home, and credentials. Verify the effective AWS identity: ambient credentials and AWS_PROFILE can override the configured profile, and SST loads .env ahead of .env.<stage>.