--- title: "Undoable volume deletes, standard SSH, auto-deploy toggle" date: 2026-05-01 number: 0288 url: https://railway.com/changelog/2026-05-01-undoable-deletes --- # Undoable volume deletes, standard SSH, auto-deploy toggle One `curl` shouldn't be enough to wipe a production database, [especially when an agent is the one firing it off](https://blog.railway.com/p/your-ai-wants-to-nuke-your-database). This week, volume deletions over the API soft-delete for 48 hours, matching the safety net the dashboard already had. SSH is now a regular SSH connection, so your client, your config, and your keys all work the way you expect. Auto-deploys get an explicit on/off control on every GitHub-connected service, so a missing permission no longer means reconnecting your repo. Let's get into it! 🚄 ## Undoable volume deletes [Video: Volume deletions over the GraphQL API now soft-delete for 48 hours, just like the dashboard] Volume deletions over the API now soft-delete for 48 hours. The dashboard has had this safety net for a while, but `volumeDelete` removed volumes immediately, with no recovery path. The API matches the dashboard now, so a runaway script or an overeager agent can't wipe out data in a single round-trip. We shipped this after seeing an AI agent deleting a production database using a long-lived account-scoped token it found on a developer's machine. Check out the [full post on the blog](https://blog.railway.com/p/your-ai-wants-to-nuke-your-database) for the rest of the story. Agents move faster than humans, take more turns, and don't carry the same intuition that "production" and "staging" mean different things, even when the API treats them the same. A human hesitates before a bad command. An agent calls the next tool. That's why we keep shipping guardrails by default. There's more on the way. ## SSH support [Video: Right-click a service and select Copy SSH command, or run railway ssh from the CLI] Railway has had SSH for a while, but the old implementation was a custom protocol the Railway team built over a WebSocket relay. It worked, but only the Railway CLI could speak it. No `~/.ssh/config`, no SCP, no port forwarding. The new implementation is a standard SSH connection. Anything that speaks SSH speaks Railway: your existing `ssh` client, `~/.ssh/config` entries, ProxyJump, port forwarding, SCP, SFTP, and identity files all work the way you'd expect. To get started, generate a key pair locally, upload the public key on the [SSH keys page](https://railway.com/workspace/ssh-keys), and connect. From the dashboard, right-click a service and select **Copy SSH command** to drop a ready-to-paste CLI command in your clipboard (make sure you’re on the latest CLI version by running `railway upgrade`). The CLI shells out to your OS `ssh` client now and picks up a few new flags along the way. - `--session`. Persistent tmux sessions with auto-reconnect, so a flaky network doesn't kill your shell. - `-i / --identity-file`. Forward a specific private key to the SSH process, mirroring `ssh(1)`. - PTY autodetection: `railway ssh -- vim foo` allocates a TTY when both ends are interactive, so remote `vim`, `htop`, and `less` work. Pipes stay clean for scripts and CI. - Workspace-owned SSH keys: Register a key under a workspace so CI/CD can authenticate as the workspace, not as a user. Useful for letting an entire org's CI use SSH without minting per-user keys. Pro tip, once you have SSH configured, you can start a session by running `@ssh.railway.com` Check out the` `[`railway ssh`](https://docs.railway.com/cli/ssh)[ docs](https://docs.railway.com/cli/ssh), and if you run into any issues, let us know in [this Central Station thread.](https://station.railway.com/feedback/feedback-standard-ssh-b815eb3c) ## Auto-deploy toggle [Video: Toggle Auto-deploy on or off in service settings] Auto-deploys on GitHub-connected services now have a clear on/off control in your service settings. You can see at a glance whether the next push to your tracked branch will trigger a deployment, and flip the state without touching the repo connection. Auto-deploys sometimes failed to set up because of missing GitHub permissions. Once you fixed the permissions, Railway couldn't always recreate the integration on its own, and the workaround was to disconnect and reconnect your repository, a fragile flow that occasionally lost configuration along the way. The auto-deploy state is now visible in service settings and yours to control. Toggle it off to pause deployments without unlinking your repo, and toggle it back on whenever you're ready to ship again. Check out the new [controlling GitHub autodeploys docs](https://docs.railway.com/deployments/github-autodeploys), and as always, let us know what you think on [Central Station](https://station.railway.com/new?type=feedback). ## Fixes and improvements - We improved how skipped deployments appear in the deployment history. When a deployment is skipped because of watch paths, it now shows up in the history with its skipped status, and you can toggle skip deploys on or off from the same view. Previously, skipped deployments disappeared from history entirely.