SaaS Stack
← All updates

v2.3.0 — deploy anywhere, with AWS beside Railway

v2.3.0 brings Milestone 20 from the roadmap. Railway stays the default and works as before. Nothing you built has to change.

AWS from one command

Some products have to live in their own AWS account: a customer asks for it, the credits are there, or the rest of the company already is. Now that is one command too:

Terminal window
bun run deploy:init aws # writes .env.aws, with a new AUTH_SECRET
bun run deploy:plan:aws # shows what would change, and changes nothing
bun run deploy:apply:aws # builds, pushes and applies, after asking
  • ECS on Fargate for the API, the web app, the site and an optional worker, on ARM, behind an HTTPS load balancer with a certificate for your domains.
  • RDS for Postgres and ElastiCache for Redis, reachable only by the services. Redis is set never to evict, so no job is lost.
  • Your settings in Secrets Manager, never in the template. The database’s password is made by AWS and never leaves it.
  • Safe releases, as on Railway: migrations run in a task of their own before anything changes, and a new version that never gets healthy is rolled back.
  • Declared as code with the AWS CDK, in TypeScript like the rest of the kit.

It costs about $50 to $60 a month for a small product, with no NAT gateway unless you want one. With your domains in Route 53, the certificate and the DNS records are made for you.

See AWS.

Production, described once

What production is (the services, the migrate command, the health checks and every setting the API is told) now lives in one file, apart from any host. Railway and AWS are both made from it, and tests fail if either drifts.

That makes a third host a well-trodden path: Add a host lists what every host must guarantee, and the add-host skill walks your coding agent through Fly.io, Render, Google Cloud or anything else.

Settings checked before you deploy

Terminal window
bun run deploy:check --before aws

It holds your settings file to the rules the API checks when it starts, so a publishable Stripe key where the secret one goes, or an AUTH_SECRET that is too short, stops you before a version that would never start. deploy:apply and deploy:apply:aws run it first.

Tested on a real account

From an account that had never used ECS to a passing deploy:check --email: HTTPS on both domains, the contact form through the site, and the sign-in email delivered. The run found three things only AWS does, and the kit now handles each.

Upgrading

  1. Run bun install for the AWS CDK.
  2. If you added your own setting of the API to .railway/railway.ts, add it to packages/deploy/src/production.ts and .env.aws.example too. bun run check tells you if you forgot.

UPGRADING.md has the full list, and the upgrade-kit skill applies it on a branch.

Next

That was the last milestone on the roadmap for now. What comes next will be there first.

Get the next one by email

Only project updates. Unsubscribe with one click.