Railway Is Down Today. My Agents Taught Me to Keep a Second Place to Ship.

Update (Oct 22, 8:00 AM ET): Railway has since said this was a security incident: an unauthorized party may have accessed customer environment variables, some decrypted. They recommend rotating every secret stored there. Builds are back for Pro and Enterprise; Hobby, Free and Trial are still waiting, per the status page.

Railway has had builds and deploys paused since about 3:24 AM Eastern today. As I write this, a little after 3 PM, the status page still says the dashboard and API are affected and no new builds are going out in any region.

I'm not writing this to dunk on Railway. I like Railway, and every platform has a day like this, including the one I run. But today is a good, concrete look at something I've been thinking about for months: what happens to your AI agents when the place they deploy to goes away for a day.

This post covers what the outage looks like from an agent's side, why I keep a deploy target on a server I own, and the honest cost of doing that.

⭐ If this is useful, a star on GitHub helps other people find it.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

What happened, from the status page

Here's what Railway has posted so far. I'm only repeating what's on status.railway.com; times are converted to Eastern.

• 3:24 AM: Railway starts investigating an issue.
• 5:28 AM: Issue identified. The dashboard, API and CLI are unavailable, and new builds are paused in all regions.
• 7:33 AM: The API is partly back, but builds are still paused.
• 12:29 PM onward: Builds and deploys stay paused, the API and dashboard are still affected, and the support site (station.railway.com) is down.
• 2:45 PM: Latest update, with no new information. Railway says it will keep posting at least every 30 minutes.

The incident is titled "Dashboard and API unavailable, builds paused" and lists builds in US West, EU West, Southeast Asia and US East as affected. Check the status page for the current state, since it'll be out of date by the time you read this.

What an agent does with a paused platform

When I'm the one deploying, an outage is annoying. I read the status page, sigh, and go do something else.

An agent doesn't sigh. It pushes a fix, asks for a deploy, gets an error, and tries again. Maybe it reads the error and decides its own code is broken, and starts "fixing" things that weren't wrong. If it's running overnight, you wake up to a long log of retries and nothing shipped.

That's not the agent's fault. It was handed one place to deploy, and that place is closed. There's no Plan B in its instructions, because there's no Plan B in the setup.

Why I keep a box of my own

This is the reason I built agentic-hosting. It's open source, and it turns a Linux server you own into a place your agents can deploy apps and databases by themselves, with limits you set.

It's one program, ah, that takes requests over an HTTP API. So the "second place to ship" is just a URL and a key your agent already knows how to use. A deploy from a git repo looks like this ($SVC is a service the agent created first):

BODY=$(jq -n --arg sha "$(git rev-parse HEAD)" '{
  source_type: "git",
  source_url: "https://github.com/you/app",
  source_ref: $sha }')

curl -s -X POST "$AH_URL/v1/services/$SVC/builds" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d "$BODY"

I'm not saying move everything off Railway today. I'm saying it's worth having somewhere your agents can still ship when your main platform can't. You can add one line to their instructions:

If the main platform's deploys are failing and its
status page shows an incident, deploy to $AH_URL
instead and tell me you did.

What it costs you

Running your own deploy target isn't free, and I'd be lying if I said it was.

• You own the uptime. If your box goes down at 3 AM, there's no status page and no team working on it. There's you.
• You do the upkeep. Updates, disk space, backups and TLS are your job. agentic-hosting handles a lot of the guardrails, but it's still a server.
• One box is one box. A single server is also a single point of failure. The point is having two places that fail for different reasons, not one place that never fails.

For a lot of people, a managed platform is the right main choice. I think the mistake is having exactly one place your agents know how to ship.

Wrapping up

Railway's builds have been paused for most of today, and anyone whose agents deploy only there is waiting along with them. Outages happen everywhere. What you can control is whether your agents have a second place to go. agentic-hosting gives them one on a server you own, and the tradeoff is that keeping it up is on you.

• Star agentic-hosting on GitHub so more people find it.
• Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
• Try the quickstart, or start at the docs site.