--- title: "Railway Agent sandbox, HA static egress, GitHub org guardrails" date: 2026-05-22 number: 0291 url: https://railway.com/changelog/2026-05-22-chat-agent-sandbox --- # Railway Agent sandbox, HA static egress, GitHub org guardrails We gave the Railway Agent a computer. The chat agent now gets a sandbox VM of its own, so it can clone a repo, run commands, edit files, and open a pull request without you copy-pasting code into the conversation. Static IP egress now supports high-availability with traffic distributed across three gateways and automatic failover. And enterprise workspaces can now lock deployments down to an allowlist of approved GitHub organizations. Quick PSA on the iOS app: TestFlight caps us at 10,000 external testers and we're already past +8,900. If you've been meaning to try it, [join now at ](https://railway.com/mobile)[railway.com/mobile](http://railway.com/mobile) before the slots fill up. On Android? Add your voice to [this Central Station thread](https://station.railway.com/feedback/railway-mobile-app-for-androi-aca54c32) so we know how loud the demand is. Let's get into it! 🚄 ## Railway Agent sandbox [Video: The Railway Agent can now work with your repo] New in Priority Boarding: [Sandbox VMs for the Railway Agent in the dashboard](https://railway.com/account/feature-flags) The Railway Agent can write code now, not just talk about it. Toggle the flag and the chat agent gets a sandbox VM with its own filesystem and shell, plus a set of tools to clone a repository, read and write files, run commands in the foreground or background, and open a pull request back to the source repo when the work is done. Before this, the agent could call Railway tools to inspect projects, services, and deploys, but it had no environment of its own. Making changes to a repo meant bringing the code to the conversation, pasting output back, and applying edits yourself. The agent could suggest a fix, but you were the one doing the typing. With the sandbox, the agent works the way a teammate would. Ask it to reproduce a bug, upgrade a dependency, add a route, or wire up a new service, and it can clone the repo, make the changes, run tests or scripts to verify, and open a PR for you to review. The sandbox tears down when the conversation ends, so there's no long-lived environment to manage. This is rolling out in Priority Boarding behind a flag. [Join Priority Boarding](https://railway.com/account/feature-flags), enable the **Chat sandbox** flag, and let us know what you think on [Central Station](https://station.railway.com/new?type=feedback). ## Static IP egress now supports high-availability [Video: Assign three egress IPs across three gateways] New in Priority Boarding: [HA static egress](https://railway.com/account/feature-flags) Static IP egress now supports high-availability. Turn it on for a service and Railway assigns three egress IPs across three gateways, distributes outbound traffic across them, and fails over automatically if one of the gateways gets unhealthy. From your application's perspective, nothing changes. From the receiving end, your requests come from a stable set of IPs that stays reachable even when a single gateway has a bad day. Previously, every service with static egress had a single gateway and a single IP. The IP was stable, but a hiccup on that one gateway affected every outbound request the service made. There was no failover path, and a slow or saturated gateway meant slow or dropped traffic for anything sitting behind it. New services that enable static egress get HA by default. Existing services see an upgrade option in service settings to migrate over, which assigns the new set of three IPs. The only thing to be aware of when you migrate is that any third-party IP allowlists pointing at your old static IP need to be updated to the three new ones. HA static egress is rolling out in Priority Boarding for services on the Pro plan. [Join Priority Boarding](https://railway.com/account/feature-flags), enable the flag, and drop feedback on [this Central Station thread](https://station.railway.com/feedback/feedback-ha-static-egress-5429a443). ## GitHub org guardrails [Image: Restrict deployments to approved GitHub organization] Workspace guardrails now cover deployment sources. Toggle **Restrict deployments to approved sources** on, add one or more GitHub organizations to the allowlist, and Railway blocks any deployment whose source repository isn't owned by an approved org. The GitHub repo picker filters down to the allowed owners too, so members can't accidentally pick a repo they aren't supposed to deploy from. This builds on the public networking guardrails we shipped previously (Restrict Generate Domain, Restrict TCP Proxy). The pattern is the same: workspace admins decide what's allowed, and everyone else operates inside those boundaries by default. The feature is available to workspaces on a spend commitment. Open **Workspace settings**, expand **Guardrails**, and add your approved GitHub organizations. Let us know what you think on [Central Station](https://station.railway.com/new?type=feedback).