Changelog #0294

This week is all about sandboxes. Docker now ships preinstalled in every sandbox, the TypeScript SDK gets a file API for reading and writing the sandbox filesystem, and the CLI picks up sandbox checkpoints and port forwarding. If you use the CLI, it's also a good week to run railway update: older versions will soon lose SSH access, more details down below.

Let's get into it! 🚄

New in Priority Boarding: Docker in sandboxes

Railway Sandboxes now come with Docker preinstalled. Every sandbox includes the Docker daemon and CLI, so you can pull images, run containers, and build from a Dockerfile without any setup:

railway sandbox create
railway sandbox ssh
docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=password postgres:17
docker build -t myapp .
docker run myapp

This opens sandboxes up to container-shaped work. An agent isn't limited to the toolchain its sandbox started with. It can pull whatever image the task needs. Dependencies like Postgres or Redis can run as containers next to the code under test instead of being mocked. And you can build the same image you ship to production and run it to verify it starts.

Per-job CI builds and ephemeral test environments for container images work the same way: SSH in, run the build, destroy the sandbox when the job finishes.

Each sandbox runs its own Docker daemon and has no private networking access, only internet, so containers can't reach the rest of your project or workspace. That isolation also makes sandboxes a reasonable place to run images you don't trust. Destroying the sandbox removes everything with it.

Before this, running a container on Railway meant deploying a service, and sandbox work was limited to whatever the sandbox image shipped with. Container builds and integration tests against containerized dependencies stayed on a local machine or in CI.

Create a sandbox, run docker run hello-world, check out the docs, and let us know what you think on Central Station.

New in Priority Boarding: Sandbox checkpoints and forwarding

Checkpoints capture a running sandbox's disk as a named, bootable snapshot you can boot fresh sandboxes from later. railway sandbox forward forwards local ports into a running sandbox. Together they round out the CLI's sandbox workflow.

Set a sandbox up once (install dependencies, clone a repo, warm caches), checkpoint it, and boot from that exact state whenever you need it. Checkpoint creation is synchronous, so the checkpoint is ready when the command returns, and reusing a name replaces the previous checkpoint in place. Unlike templates, whose recipes live in the local store of the machine that built them, checkpoints are stored server-side, so you can boot from one on any machine. And unlike forking, a checkpoint outlives the sandbox it came from. Named checkpoints are capped per environment by plan: 10 on the Trial plan, 50 on Hobby, and 100 on Pro.

Port forwarding makes the sandbox dev loop feel local. Run a dev server or database inside a sandbox and hit it from localhost. Several ports multiplex over one connection, a busy local port falls back to a nearby free one (and says so), and the forward keeps the sandbox alive while it's up.

Checkpoints are also available in the dashboard's Sandboxes tab and in TypeScript SDK v3.2.0. Update with railway upgrade, check out the CLI sandbox docs, and let us know what you think on Central Station.

New in the TypeScript SDK: sandbox.files, an API for reading and writing the sandbox filesystem directly. It's binary-safe, streams in both directions, and doesn't go through a shell, so there's no quoting or encoding to get wrong.

Reads come back as text, bytes, or a stream, with offset, length, and fromEnd options for pulling a slice of a large file. Writes accept strings, byte arrays, blobs, and streams (including streams of unknown length), and parent directories are created automatically. Large transfers run in bounded-memory segments and resume from the exact byte position if the connection drops. Alongside read and write, you get list, stat, exists, mkdir, rename, and remove.

Before this, moving files in and out of a sandbox from the SDK meant shelling out through exec and wrestling with quoting, encoding, and memory for anything bigger than small text. The file API gives scripts and agents a direct, typed path to the filesystem.

Grab the latest SDK release and let us know what you think on Central Station.

• We shipped standard SSH in May, and we're turning off the legacy SSH path it replaced. Older CLI versions will stop having SSH access soon, so upgrade with railway upgrade. Recent versions also let railway connect tunnel to private databases (Postgres, MySQL, Redis, and MongoDB) over SSH, so you can reach a database that has no public TCP proxy. Previously, railway connect only worked through a public proxy.
• We improved Infrastructure as Code imports and diagnostics. railway config pull now round-trips canvas groups, and invalid changeset patches surface schema validation details. Previously, groups didn't survive an import, and patch failures returned a generic error.
• We improved the Railway agent skills (1.3) to be sandbox aware. Ask your agent to create a Railway sandbox, and the skills let it build applications in sandboxes, create checkpoints and forks, connect in over SSH, and forward ports as needed, after checking that your account is enrolled in Priority Boarding first. Previously, the skills had no knowledge of sandboxes.
• We improved the CLI's agent health check and skills update flow. railway --help now ends with an Agent tooling section that shows whether Railway skills and the MCP server are configured across your detected editors, and tells you when a newer skills revision is available. The skills updater also detects installs made by older CLI versions and prompts you to bring them under management, so skill updates keep propagating down to your configuration. Previously, those installs were invisible to the updater and never received updates.