--- title: "Docker in Sandboxes, sandbox file API, checkpoints and forwarding in the CLI" date: 2026-06-12 number: 0294 url: https://railway.com/changelog/2026-06-12-docker-in-sandboxes --- # Docker in Sandboxes, sandbox file API, checkpoints and forwarding in the CLI 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! 🚄 ## Docker in Sandboxes [Video: Docker comes preinstalled in Sandboxes] New in Priority Boarding: [Docker in sandboxes](https://railway.com/account/feature-flags) 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: ```bash 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](https://docs.railway.com/sandboxes), and let us know what you think on [Central Station](https://station.railway.com/new?type=feedback). ## Sandbox checkpoints and port forwarding in the CLI [Image: Manage sandbox checkpoints from the CLI with support for port forwarding] New in Priority Boarding: [Sandbox checkpoints and forwarding](https://railway.com/account/feature-flags) 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](https://github.com/railwayapp/railway-ts-sdk/releases/tag/v3.2.0). Update with `railway update`, check out the [CLI sandbox docs](https://docs.railway.com/cli/sandbox), and let us know what you think on [Central Station](https://station.railway.com/new?type=feedback). ## File API for sandboxes in the TypeScript SDK [Image: Manage files in sandboxes] New in the [TypeScript SDK](https://github.com/railwayapp/railway-ts-sdk/releases): `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](https://github.com/railwayapp/railway-ts-sdk/releases) and let us know what you think on [Central Station](https://station.railway.com/new?type=feedback). ## Fixes and improvements - We shipped [standard SSH in May](https://railway.com/changelog/2026-05-01-undoable-deletes), and we're turning off the legacy SSH path it replaced. Older CLI versions will stop having SSH access soon, so upgrade with `railway update`. 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](https://docs.railway.com/agents) (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.