v4.21.3

nodejs.install works with npm 12, and the Router's CloudFront function leaves more room for your own injection. Still built on upstream v4.17.2.

Fixes

• nodejs.install now works with npm 12. A function that installs packages at build time failed on npm 12 with EUNKNOWNCONFIG, because npm 12 rejects flags it doesn't know and --platform and --arch were two of them. The install no longer passes --platform and --arch. It selects the function's platform with --os=linux and --cpu=<x64|arm64> (and --libc=glibc for sharp), as before, so native packages such as esbuild and sharp are still fetched for the function's architecture. npm 10 and 11 give the same result as before. npm older than 9.9 still completes the install, but installs the packages for the machine it runs on instead of the function's architecture, before and after this change. (#122, anomalyco/sst#7031, anomalyco/sst#6946)

Changes

• A Router leaves about 1 KB more room for edge.viewerRequest.injection. CloudFront limits the viewer-request function to 10,240 bytes, and the route lookup and the cloudfront.net block are now minified. On a test router with three sites, a URL route and a bucket route the function went from 8,872 to 7,898 bytes, and an injection of 1,800 bytes that CloudFront rejected as too large now deploys. The 403 that a request to the cloudfront.net URL gets, from a component that has a domain (Router, StaticSite or SsrSite) and from every HttpsRedirect, now has the plain text body 403 Forbidden instead of an HTML page. Its status code and description are the same. StaticSite and SsrSite use the smaller block too, which saves them about 150 bytes; the rest of their function is unchanged. For a Router, the first deploy after you update changes the code of its viewer-request function in place and replaces nothing. It also runs the route data, file sync and CloudFront invalidation steps of the sites behind the Router again, so each StaticSite gets one invalidation. (#124, anomalyco/sst#7030)

Install

npm install sst@npm:@sst-community/sst@4.21.3

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.21.3" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v4.21.2

Faster deploys for apps that pass an IAM role to their functions, and Router timeout docs that match what CloudFront does. Still built on upstream v4.17.2.

Fixes

• A function no longer reads the IAM role you pass to it on every deploy. With role set, SST looked the role up once per function on every sst dev and sst deploy, even when nothing had changed, so an app that shares one role across many functions paid for it many times. On a test app with 150 functions sharing one role, that was 150 reads per run, and it is now 0; a deploy with nothing to change went from 21–26 seconds to 13–18 seconds. The role is read when you access nodes.role, and then a role that doesn't exist fails the deploy. Because of that, a role that was deleted no longer fails a deploy of an existing function: the function fails when it runs, with "The role defined for the function cannot be assumed by Lambda". The role docs now say so. The first deploy after you update changes none of your resources; it only drops the role reads from SST's state. (#116, anomalyco/sst#6942)

Docs

• The readTimeout and keepAliveTimeout options of a URL route on a Router (router.route()) now say what CloudFront does. readTimeout counts for each connection attempt, so a request to a destination that never answers can take readTimeout times connectionAttempts (3 by default) to fail. keepAliveTimeout is passed to CloudFront but ignored: the connection is kept for the keep-alive timeout of the distribution's origin, 5 seconds by default. (#112, anomalyco/sst#6987, anomalyco/sst#6900)

Install

npm install sst@npm:@sst-community/sst@4.21.2

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.21.2" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v5.0.0-alpha.2

The second pre-release of v5: a guide to moving from v4, a notice when a newer SST is out, faster rebuilds in sst dev, and the fixes in 4.21.0 and 4.21.1. It's on npm under the next-experimental tag, so an install without a version still gets 4.x. Built on sst-community v4.21.1 with the fixes on main since, and on upstream v4.17.2.

It's a build to try v5 with, on a stage of its own. The v5 components can still change in any way before 5.0.0.

⚠️ Breaking changes

• The functions v5 components create refuse an output for dev, logging, url, python and concurrency, as sst.aws.v5.Function already did. A queue's subscriber is one. These decide which resources are created, so they have to be plain values. The error names the arg.

New

• A guide to moving from v4, Migrate From v4. It covers what to check in your config before you install, how to switch a component, what every v5 component does differently, what a switch can replace, a line for each component, and how to go back.
• The CLI says when a newer SST is out. Once a day, in the background, the commands that run your app, like sst deploy, sst diff and sst dev, ask GitHub for the newest release in the CLI's major version, the one sst upgrade installs. When there is one, the next run shows SST 5.0.0-alpha.3 is available. Run `sst upgrade` to update. under the header. Nothing is looked for in CI, or with SST_SKIP_UPDATE_CHECK=1.
• sst dev rebuilds the functions a change affects together, 4 Node.js functions at a time unless SST_BUILD_CONCURRENCY_FUNCTION says otherwise, and files saved at once, by a formatter or a git checkout, start one rebuild instead of one each. With 16 functions that import a shared module, a change to it took 866ms of builds and takes 329ms.
• A function can leave the AWS SDK out of its bundle in sst dev, which took one function's build from 53ms to 10ms. The nodejs.esbuild docs show how. It's then loaded from your node_modules, and a deploy still bundles it.

Fixes

• A version rule in sst.config.ts accepts a pre-release when it accepts its release. ">= 4" and "5.x" accept this one, and "4.x" doesn't. 5.0.0-alpha.1 only met a rule that named a pre-release.
• A function given a role no longer looks the role up on every run. Each lookup was an IAM call per function, so an app with 440 functions sharing one role spent 367s of a no-op sst dev on them, and now spends 29s. A v5 Function uses a role ARN as it is, and still looks up a role given by name. (#116)
• A Mysql without a version can be created again. It defaults to "8.0", and RDS uses its current minor version of MySQL 8.0. The old default, 8.0.40, is no longer offered. A database you've deployed keeps its version.
• sst diff no longer shows a v5 component's function as deleted when its args hold a value that's only known on deploy, like the ARN of a layer being replaced.
• A function's changed build options apply in sst dev without a restart. It kept building with the ones it started with.
• A killed sst tunnel or sst dev no longer leaves the tunnel running. Run sudo sst tunnel install again after you update, outside a project folder. (#101, anomalyco/sst#6297)
• A Go function no longer changes when only the git commit changes, so a deploy no longer uploads every Go function after each commit. The first deploy after you update uploads each one once. (#109, anomalyco/sst#6976)
• The Run resource no longer hangs on a long line of output. (#110, anomalyco/sst#7006)

Docs

• How a Router URL route's timeouts behave (#112), and successor on PlanetScale's PostgresBranchRole (#111).

Known issues

• Not ported yet: the sites (Nextjs, Astro, StaticSite and the rest), Vpc, Router, Cdn, MicroVm, the Cloudflare and Vercel components, and others. They work as 4.x components. The plan lists them.
• sst diff can still show a 4.x component's function as deleted that the deploy then updates, as above.
• Not tried in AWS yet: sst dev with a v5 Service or Task, get and existing with real resources, a custom provider, and switching a v5 component back to 4.x.
• The v5 docs aren't published. The component pages and guides are in the repo, under www/src/content/docs/docs.

Install

npm install sst@npm:@sst-community/sst@5.0.0-alpha.2

To try it in an existing project:

1. Use a stage of its own. A version rule in sst.config.ts has to accept 5.x: ">= 4" does, and an app without one runs with any version.
2. Set its dependency to "sst": "npm:@sst-community/sst@5.0.0-alpha.2" and reinstall.
3. To go back, switch any v5 components back to their 4.x names and check sst diff, then set it to 4.21.1.

For a project that isn't JavaScript, install the CLI globally. This replaces a global 4.x CLI:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | VERSION=5.0.0-alpha.2 bash

v4.21.1

A fix for Go functions that redeploy when nothing in them changed. Still built on upstream v4.17.2.

Fixes

• A Go function no longer changes when only the git commit changes. Go wrote the git revision and commit time into every binary it built, so a new commit gave a new binary and a new zip even if no Go file changed, and the next sst deploy uploaded new code for every Go function in the project. Deploy builds now pass -buildvcs=false, and so do the release builds of the sst dev bridge task image. The first deploy after you update uploads each Go function once, because the binary changes; after that, a commit alone leaves them as they are. On a real Go function, an empty commit and a second deploy updated it before the fix and left it alone after. Dev builds are unchanged. (#109, anomalyco/sst#6976)

Also

• The Run resource no longer hangs on a command that prints a line longer than 64 KB, and it reads stdout and stderr together, so a command that writes a lot to stderr can't block either. A line over 1 MB is replaced by a note and the lines after it still come through. Nothing in SST 4 creates a Run resource today, so no config reaches this yet. (#110, anomalyco/sst#7006)

Docs

• The PlanetScale guide explains successor on PostgresBranchRole, which a role that owns objects needs before SST can remove it, and the Postgres examples set it. (#111, anomalyco/sst#6932)

Install

npm install sst@npm:@sst-community/sst@4.21.1

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.21.1" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v5.0.0-alpha.1

The first pre-release of v5, the fork's next major version. It rebuilds the components on one foundation, and lets you write and share your own the same way. It's on npm under the next-experimental tag, so an install without a version still gets 4.x. Built on sst-community v4.20.0 with the fixes on main since, and on upstream v4.17.2.

It's a build to try v5 with, on a stage of its own. The v5 components can still change in any way before 5.0.0. The 4.x components in sst.aws.* work as they do in 4.x, so an app can move to this CLI first and switch its components one at a time.

⚠️ Breaking changes

• A version rule in sst.config.ts has to name a pre-release to accept this one. ">= 5.0.0-0" accepts 5.0.0-alpha.1, but ">= 4", "5.x" and "*" don't. Change the rule or remove it before you install.
• A provider version in your config has to be in the major version SST's components are built for, or before 1.0, the minor version. An older one was already refused, and now a newer one is too, with the versions to use. sst add picks the newest version in that major version instead of npm's latest.
• A file in your app that re-exports a global by name no longer builds, such as export { aws }. export const x = aws and export default aws still work.
• A file that app() imports can't use a provider while it loads. Providers aren't installed when app() is read, so a provider's module is a stub there that throws when it's used. Code that did this couldn't rely on the provider before either.
• Deployed function roles no longer trust the account root, only Lambda. sst dev still adds it. The first deploy updates every function's role in place, so a deploy role with limited permissions needs iam:UpdateAssumeRolePolicy. Add it before you update. (#95, anomalyco/sst#7026)

New

• v5 components, next to the 4.x ones. 20 are ported, as sst.aws.v5.*: Alb, ApiGatewayV2, AppSync, Aurora, Bucket, Bus, Cluster, CognitoUserPool, CronV2, Dsql, Dynamo, Efs, Function, Mysql, Postgres, Queue, Redis, Service, SnsTopic and Task. Each declares every resource it creates as a part, and from that list gives you transform for any of them, existing to use one you already have, and nodes to read any of them. See the README.
• Switch one component at a time and keep what's deployed. Change sst.aws.Queue to sst.aws.v5.Queue, keep the name, and the resources stay. An object transform is merged deeply in v5, where 4.x replaced what it named. Each component's doc comment, in platform/src/components/aws/v5/, has a "Switch from" section with what else is written differently.
• Write your own components with sst.component(), the way SST's own are made, from resources of any provider in your app. Whoever uses one gets transform, existing and nodes for each of its parts, and a link() method makes it linkable. See Write a Local Component.
• Share components as npm packages. A package imports sst/components and its providers and lists them as peer dependencies. When an app deploys it, the package gets the app's copies. The deploy checks those peer dependencies, and says to run sst add for a missing provider. An app without a package.json lists packages in its config, under packages. See Write a Package Component.
• Test components without AWS. mock() stands in for the deploy engine, so a test creates a component and checks what it would deploy. A package's repo imports it from sst/testing.
• sst install writes .sst/tsconfig.json, which says where the app's SST and providers are. An app's tsconfig.json extends it, so TypeScript reads a package's types.
• sst upgrade and sst init stay in the CLI's major version. This CLI upgrades to the newest 5.x, pre-releases included.
• "X is not defined" in a config says how to add the provider, with sst add.
• sst.aws.Redis can create an ElastiCache Serverless cache, with serverless. (#91, anomalyco/sst#6160)

Fixes

• sst dev sends a function's response again when it doesn't arrive. Right after a function cold-starts, AppSync can take a response and not deliver it, and the call hung until it timed out. The CLI now sends each response and error five times, three seconds apart, and the function keeps the first to arrive. (#102, anomalyco/sst#6575)
• Functions on a shared bundle each read their own linked resources. They shared one file, so the last one written won, and every deploy uploaded their code again. (#89, anomalyco/sst#6750)
• sst dev's memory stops growing as functions rebuild. It keeps at most 4 esbuild build contexts. SST_BUILD_CONTEXT_CACHE sets the number, and 0 turns the cache off. (#90, anomalyco/sst#6960)
• A rebuild in sst dev no longer deletes a function's output from under a running worker, which broke functions with several bridge instances, such as behind CloudFront or a Router. (#100, anomalyco/sst#6416)

Known issues

• Not ported yet: the sites (Nextjs, Astro, StaticSite and the rest), Vpc, Router, Cdn, MicroVm, the Cloudflare and Vercel components, and others. They work as 4.x components. The plan lists them.
• sst diff can show a function as deleted that the deploy then updates, when its args hold a value that isn't known until the deploy. 4.x does the same.
• Not tried in AWS yet: sst dev with a v5 Service or Task, get and existing with real resources, and a custom provider.
• Mysql without a version can't be created, as RDS no longer offers its default, 8.0.40. 4.x has the same problem. Set a version.

Install

npm install sst@npm:@sst-community/sst@5.0.0-alpha.1

To try it in an existing project:

1. Use a stage of its own, and check that version in sst.config.ts accepts a pre-release.
2. Set its dependency to "sst": "npm:@sst-community/sst@5.0.0-alpha.1" and reinstall.
3. To go back, set it to 4.20.0 again. Switch any v5 components back to their 4.x names first.

For a project that isn't JavaScript, install the CLI globally. This replaces a global 4.x CLI:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | VERSION=5.0.0-alpha.1 bash

v4.21.0

Redis on ElastiCache Serverless, function roles that stop trusting your whole AWS account outside sst dev, and fixes for sst dev and sst tunnel. Still built on upstream v4.17.2.

⚠️ Breaking changes

• The role SST creates for a function now trusts only Lambda, except in sst dev. Before, every function role also trusted your AWS account, so anyone in it who is allowed to assume roles could take on a deployed function's permissions. The first sst deploy after you update changes each function role in place, so a deploy role with limited permissions needs iam:UpdateAssumeRolePolicy. sst dev on a deployed stage adds the account back until the next deploy. If something assumes a deployed function's role on purpose, add the trust back with transform.role. (#95, anomalyco/sst#7026)

New

• sst.aws.Redis can create an ElastiCache Serverless cache, with serverless: true or with storage and ecpuPerSecond limits. It links host, port, username and a generated password like a provisioned cluster, and serverless: { password: false } leaves the password out. A deploy role with limited permissions needs the ElastiCache user and user group actions in the password docs. Turning serverless on or off for an existing Redis replaces the cache, and its data is lost. (#91, anomalyco/sst#6219)

Fixes

• A killed sst tunnel or sst dev no longer leaves the tunnel running, which blocked the next one with "Another tunnel process is already running". The fix is in the copy at /opt/sst/tunnel, so run sudo sst tunnel install again after you update. Run it outside a project folder: inside one, it installs the sst in that project's node_modules. (#101, anomalyco/sst#6297)
• sst dev no longer hangs when a function's response is lost on the way back after a cold start. The response is sent again a few times. (#102, anomalyco/sst#6575)
• sst dev keeps a function's build output while it rebuilds, so a running function no longer loses its bundle.mjs. (#100, anomalyco/sst#6416)
• sst dev no longer grows in memory as it builds functions. It keeps at most 4 esbuild build contexts. SST_BUILD_CONTEXT_CACHE changes that; keep it at or above SST_BUILD_CONCURRENCY_FUNCTION. (#90, anomalyco/sst#6960)
• Functions that share a bundle directory each get their own links. Each has its own .sst/<function name>/resource.enc there, and its zip carries only that one. A .sst folder you keep in a bundle directory is no longer uploaded. (#89, anomalyco/sst#6772)

Also

• The README has Discord, npm and build badges. The automatic review works with its free model again (#93).

Install

npm install sst@npm:@sst-community/sst@4.21.0

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.21.0" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v4.20.0

A security fix for buckets served through CloudFront, EventBridge notifications for buckets, and fixes for static sites' error pages and sst dev with a custom bundle. Still built on upstream v4.17.2.

⚠️ Breaking changes

• A bucket with access: "cloudfront" can now only be read by CloudFront distributions in your own AWS account. Before, a distribution in any account could read it through its own origin access control. This covers the assets bucket of every StaticSite and SSR site, and buckets routed with router.routeBucket. If a distribution in another account reads one of your buckets on purpose, it gets a 403 after you update. Allow it with the policy statement shown in the access docs. (#79, anomalyco/sst#6878)
• A deploy role with limited permissions needs cloudfront:CreateOriginAccessControl, cloudfront:GetOriginAccessControl and cloudfront:DeleteOriginAccessControl to deploy a StaticSite that has an errorPage. Add them before you update. A site without an errorPage needs nothing new. (#78)

New

• Buckets can publish their events to EventBridge. bucket.notify({ eventBridge: true }) turns it on, alone or with queue, topic and function notifications. sst.aws.Bucket.subscribeEventBridge() subscribes a function to a bucket's events, filtered by event type and key, including on a bucket SST doesn't manage. (#85, anomalyco/sst#6866)

Fixes

• A StaticSite with an errorPage shows that page for a missing path, instead of a 502. (#78, anomalyco/sst#7025)
• sst dev works with a relative bundle on a Function, such as bundle: "./dist". It crashed with ERR_INVALID_ARG_TYPE. (#25, anomalyco/sst#6253)

Docs

• The bootstrap IAM policy lists everything the CLI calls: ssm:GetParameter on /sst/bootstrap, and on /sst/bootstrap/asset to clear an older SST's bootstrap. The reset steps show the command that removes the parameter. (#81, #83)

Install

npm install sst@npm:@sst-community/sst@4.20.0

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.20.0" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v4.19.0

A new MicroVm component, streaming for SvelteKit, and fixes for sites with a base path and for accounts that encrypt SSM parameters. Still built on upstream v4.17.2.

⚠️ Before you upgrade

• sst/aws/workflow now uses @aws/durable-execution-sdk-js 2.6.0, and two errors have new classes. A step that fails inside promise.all throws PromiseCombinatorError, not StepError. A failed waitForCallback callback throws CallbackExternalError, not ChildContextError. Update code that checks for the old classes. (#62, anomalyco/sst#7024)

New

• sst.aws.MicroVm and the sst/aws/microvm SDK, for AWS Lambda MicroVMs: isolated, stateful sandboxes with their own HTTPS endpoint. Lambda builds the image from your Dockerfile, and a linked function starts MicroVMs with microvm.run() and calls them with fetch(). It supports VPC egress and sst dev, and deletes old image versions. (#58)
  • For now every MicroVM has 2 GB and no lifecycle hooks, until the AWS provider supports them.
  • sst remove fails while MicroVMs from the image are running. Terminate them first.
  • A deploy role with limited permissions needs the Lambda MicroVMs actions, including lambda:ListMicrovms, lambda:ListMicrovmImageVersions and lambda:DeleteMicrovmImageVersion to delete old versions.
• sst.aws.SvelteKit can stream responses. Turn it on with adapter({ streaming: true }) in @sst-community/svelte-kit-sst 3.1.0, out with this release. It needs this CLI or later. Update the adapter with npm install svelte-kit-sst@npm:@sst-community/svelte-kit-sst@3.1.0. (#40, #76, anomalyco/sst#6674)

Fixes

• A site with a base path loads its static files again, instead of getting a 403 from S3. This covers Next.js basePath and SvelteKit's and Astro's base. (#72, anomalyco/sst#6980)
• The Router takes a base path off the start of a request path only. A request with the base text in the middle of its path, or /administrator on a site based at /admin, got the wrong S3 key. (#75)
• SST works where a policy encrypts SSM parameters. Before, every command stopped with invalid character 'A' looking for beginning of value. With a customer managed KMS key, the role needs kms:Decrypt on it. (#73, anomalyco/sst#6856)
• SSR sites stop right away in the 11 regions without Lambda function URLs, instead of failing minutes into the deploy. Auckland is one of them. Spain (eu-south-2) works again. Sites without a server function aren't affected. (#60)

Examples

• The Astro examples use Astro 7, which needs Node.js 22.12 or later. Those that deploy with the adapter use @sst-community/astro-sst. (#53, #54, #55, #56, #57)

Also

• The docs site has a logo. The workflow SDK's tests load again (#69). The automatic review asks for a Closes line when a pull request fixes an SST issue (#71). A release that fails partway can be finished by re-running it.

Install

npm install sst@npm:@sst-community/sst@4.19.0

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.19.0" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v4.18.1

Now built on upstream v4.17.2, SST's latest release. 4.18.0 was built on 4.17.1. This release also fixes server routes next to prerendered pages, the visitor's address in SvelteKit apps, and JWT auth on WebSocket APIs.

⚠️ Before you upgrade

• Node.js 22 or later is still required, as since 4.18.0. The package now says so in its engines field: npm, pnpm and Bun warn when you install it on an older Node.js, and Yarn 1 refuses to install it. Upgrade Node.js everywhere you run sst, CI included.
• An ApiGatewayWebSocket with JWT auth now stops at sst diff and sst dev, not only at deploy. It could never deploy: API Gateway only supports JWT authorizers on HTTP APIs. Use a Lambda authorizer that verifies the token instead; the docs now show one. (#51, anomalyco/sst#6041)

SST 4.17.2

SST 4.17.2 has one change, which guards a function's description in sst dev against a missing value (anomalyco/sst#6984). The fork has had the same fix since 4.17.3 (#14), so nothing changes for you. sst version now shows built on SST 4.17.2.

Fixes

• Server routes in a folder with prerendered pages no longer get a 403. An SsrSite sent a whole asset folder to S3, so when a folder held a prerendered page, the server routes in it got S3's 403. In SvelteKit, a prerendered page or endpoint in such a folder could 403 too. Those folders' files are now listed one by one, so each request goes to S3 or to the server as it should. This applies to SvelteKit, SolidStart and Astro with a server. (#35, anomalyco/sst#6143)
• getClientAddress() in a SvelteKit app returns the visitor's address behind CloudFront, from CloudFront-Viewer-Address. It used to return CloudFront's own address, which changes from request to request, so rate limiting and logging saw the wrong address. It's in @sst-community/svelte-kit-sst 3.0.1. The value can only be trusted when requests come through CloudFront: if you use it to allow or block clients, set protection on the SvelteKit component, or on the Router that serves it. (#50)

Changes

• ApiGatewayWebSocket documents how to accept a JWT, such as a Cognito token: a Lambda authorizer that verifies it with aws-jwt-verify. Its jwt, payload and response options are deprecated, since WebSocket APIs don't support or use them. (#51)
• To update the SvelteKit adapter: npm install svelte-kit-sst@npm:@sst-community/svelte-kit-sst@3.0.1.

Docs

• The landing page, the README and the docs intro say Node.js 22 or later is required.

Install

npm install sst@npm:@sst-community/sst@4.18.1

To switch an existing project:

1. Check that node --version shows v22 or later, wherever you run sst, CI included.
2. Set its dependency to "sst": "npm:@sst-community/sst@4.18.1" and reinstall.

For a project that isn't JavaScript, install the CLI globally. It still needs Node.js 22 or later, to run sst.config.ts:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash

v4.18.0

The fork's first minor release: Pulumi and the providers updated, Astro 6 and 7, and fixes for sst dev and deploys. Still built on upstream v4.17.1.

⚠️ Breaking changes

All from the Pulumi and provider update (#18):

• Node.js 22 or later is required. Pulumi's Node.js SDK, which runs your sst.config.ts, needs it. On an older Node.js the CLI warns that SST needs Node.js 22 or later. Node.js 20 mostly works, but inline Lambda callbacks fail. Upgrade Node.js everywhere you run sst, CI included.
• A deploy role with limited permissions needs cloudfront:TagResource and cloudfront:ListTagsForResource. The first deploy updates the tags on every site's and Router's CloudFront Functions and KV stores. Add both before you deploy.
• A provider version pinned in sst.config.ts has to be at least aws 7.48.0, command 1.2.1, docker-build 0.0.22, random 4.21.2 or tls 5.6.1. A lower pin stops with You specified version <pin> of the "<provider>" provider. SST needs <version> or higher. Raise the pin or remove it.
• The first deploy after upgrading redeploys your containers. Every image SST builds with docker-build is rebuilt once, so each Service, Task and container Function gets a new task definition revision and a rolling deployment. Your own command.local.Command and remote.Command resources run once more too.

Fixes

• sst dev no longer freezes when one of its clients stops reading. A pane, a browser tab or another client that stopped reading events used to block the whole event bus, so every function invocation timed out until sst dev was restarted. That client now misses events instead, and the log file gets a warning. (#27, anomalyco/sst#7013)
• sst dev no longer crashes with concurrent map read and map write when many invocations arrive at once. (#23, anomalyco/sst#6970)
• A new function URL or SSR site no longer fails to deploy now and then with ResourceConflictException: The function could not be updated due to a concurrent update operation. The URL's permissions are now added after the URL exists. Existing stacks get the new ordering with no resource changes. (#22, anomalyco/sst#6933)
• ApiGatewayV2 with cors: false leaves the CORS configuration unset, as its docs say. It used to set an empty one, under which API Gateway answers preflight requests itself and ignores the CORS headers your routes return. The next deploy removes the empty configuration from an existing API, in place. (#26, anomalyco/sst#6748)
• SsrSite deploys to Auckland (ap-southeast-6). The deploy crashed, because the region had no coordinates. (#18, anomalyco/sst#6792)

Changes

• Pulumi 3.267.0, and newer providers: @pulumi/aws 7.48.0, command 1.2.1, docker-build 0.0.22, random 4.21.2 and tls 5.6.1. Cloudflare stays at 6.15.0, because from 6.18 the first deploy of an existing D1 database fails (pulumi/pulumi-cloudflare#1583). Vercel stays at 4.6.0. (#18)
• Function exposes its function URL resource as nodes.url, when url is set. (#22)
• Pulumi's log files and workspace file go to SST's folder instead of ~/.pulumi. (#18)

Astro 6 and 7

SST's astro-sst 3.x can't build an Astro 6 or 7 app. The fork now publishes the adapter as @sst-community/astro-sst 4.0.0, which works with Astro 5.6 and later, 6 and 7. Install it under the old name so import aws from "astro-sst" keeps working:

npm install astro-sst@npm:@sst-community/astro-sst

• sst init installs it for a new Astro app.
• sst.aws.Astro stops before the build when an Astro 6 or 7 app still has SST's adapter, and names the package.json line to change.
• It fixes bugs from 3.1.4: cookies keep Max-Age, several cookies in stream mode arrive as separate headers, binary responses such as AVIF are no longer corrupted, trailing-slash redirects and src/fetch.ts work, and Astro.clientAddress can't be spoofed. The adapter's changelog has the full list, including what changes when you switch.
• Astro 5.0 to 5.5 need SST's 3.x, or an Astro upgrade.

(#47)

Install

npm install sst@npm:@sst-community/sst@4.18.0

To switch an existing project, set its dependency to "sst": "npm:@sst-community/sst@4.18.0" and reinstall. Without Node:

curl -fsSL https://raw.githubusercontent.com/sst-community/sst/main/install | bash