---
title: "Sandboxes, Infrastructure as Code"
date: 2026-06-05
number: 0293
url: https://railway.com/changelog/2026-06-05-sandboxes
---

# Sandboxes, Infrastructure as Code

This week, Sandboxes are available in Priority Boarding from the dashboard and CLI, and Infrastructure as Code is available experimentally in CLI 5.2.0. Both features use the [Railway TypeScript SDK](https://github.com/railwayapp/railway-ts-sdk) (yes, we released a TypeScript SDK too). We also shipped Console tab GA and tightened the first deploy path for agents.

Let's get into it! 🚄

## Sandboxes to Priority Boarding

[Video: Spin up sandboxes from the Railway dashboard]

[New in Priority Boarding: Sandboxes](https://railway.com/account/feature-flags)

Sandboxes are short-lived Linux environments you can create from the dashboard, CLI, or TypeScript SDK. The project navigation now includes a **Sandboxes** tab where you can create a sandbox, see active and inactive sandboxes, copy an SSH command, open a console, or destroy one when the work is done. The table shows status, age, region, and idle timeout, so it's clear what is running and what is still incurring usage.

From the CLI, `railway sandbox` gives the same primitive to scripts and agents. Create a sandbox, run commands in it, connect over SSH, fork it, build templates, and tear it down after the task finishes:

```bash
railway sandbox create
railway sandbox template build --name dev -c 'npm i -g pnpm' --wait
railway sandbox create --template dev
railway sandbox ssh
railway sandbox exec --id <id> -- ls -la
railway sandbox fork
railway sandbox destroy --id <id>
```

Sandboxes are useful for agent runners, application testing areas, and longer tasks that need filesystem and shell access without keeping a service container around. Templates give you a reusable base for setup work. Build a template with packages, environment variables, working directories, and commands, then fork sandboxes from that prepared state instead of rebuilding from a clean Debian base every time.

Before this, sandbox-style work on Railway usually meant borrowing an existing service, using a local machine, or maintaining a custom runner. Sandboxes give that work an isolated Railway-managed place to run, with dashboard controls for humans and lifecycle commands for scripts and agents.

Open the **Sandboxes** tab in a project, run `railway sandbox --help`, 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).

## Infrastructure as Code in the CLI

[Video: Infrastructure-as-code with the TypeScript SDK]

Experimental in CLI v5.2.0+: Railway Infrastructure as Code.

Railway Infrastructure as Code lets you describe project configuration in `.railway/railway.ts`, then import, preview, and apply it from the CLI. A single file can define services, databases, buckets, custom domains, environment variables, replicas, and canvas groups.

Run `railway config init` to create a starter config for a new project. The CLI can scan the current directory and generate a starting service from your package manager, `package.json` scripts, and GitHub remote. Run `railway config pull` to import the current state of an existing Railway project instead.

From there, `railway config plan` shows exactly what the file would change, and `railway config apply` runs a plan before applying after confirmation. Plans stop if a service is still managed by `railway.json` or `railway.toml`, so one service doesn't have two sources of truth.

Before this, reproducing project structure across environments or workspaces meant clicking through settings, scripting against individual APIs, or keeping deployment knowledge in docs. IaC gives that configuration a typed source of truth that an engineer or agent can review alongside code.

TypeScript authoring is the first supported path and requires the Railway TypeScript SDK as a dependency. Read the [Infrastructure as Code docs](https://docs.railway.com/infrastructure-as-code), expect rough edges while the DSL settles, and tell us what feels wrong on [Central Station](https://station.railway.com/new?type=feedback).

## Fixes and improvements

- We shipped the **Console** tab to General Availability. The in-browser shell and service file browser are available without the Priority Boarding flag. Previously, the Console tab was gated behind the feature flag.
- We improved agent-driven sign-up and first deploy flows in the CLI. Agents can detect missing auth, start the right Railway auth flow, and continue once the account is ready. `railway up` can also create a project, link the local directory, and keep deploying when an app starts outside an existing Railway project. Previously, the first run needed a human to create the project, run linking commands, and restart the deploy.
- We improved managed skills updates in the CLI so unmodified Railway skills update with CLI releases. If you've edited a skill, the CLI leaves it alone unless you pass `--force`. Previously, skills could lag behind Railway changes unless you manually reinstalled them.
- We improved Railway Agent Skills 1.3 so agents understand the updated sign-up, project creation, and application deployment paths, then choose the right flow for the project in front of them. Previously, agents had less context about whether to create, link, or deploy from scratch.