The Agent-Native Cloud: 3M Users, 100K Signups/Wk, Data Centers, & Death PRs — Jake Cooper, Railway

From rebuilding Railway’s network overlay over a weekend to moving the vast majority of workloads onto its own bare metal, Jake Cooper is trying to build a new cloud for an agent-native world. In this episode, Railway’s founder and “conductor” joins swyx and Alessio to unpack why the next era of software infrastructure is not just “Heroku but newer,” what agents need that humans did not, and why the old deployment loop of Git, PRs, CI/CD, and static cloud resources may be heading for a rewrite. We go deep on Railway’s infrastructure stack: own-metal data centers, three-month cloud payback periods, cloud bursting, data center debt, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable filesystems, agent-safe production forks, and why the CLI may become more important than the canvas in an agent world. Jake also shares the founder journey behind Railway, how the company survived losing $500K/month, why it now serves millions of users with only 35 people, and why he believes the pull request is dying. We discuss: • Why Railway wants to make deployment feel instantaneous • How Railway went from a slow six-year grind to adding 100,000 users a week • Why the free tier era became a bad business and had to be rebuilt • How Railway thinks about agents as the next dominant software species • Why agents need version control, observability, compute, storage, and orchestration at 1000x scale • Why CLIs with hundreds of flags are annoying for humans but ideal for agents • Why you should be waiting on intelligence, not compute • The economics of Railway’s own-metal data centers and three-month cloud payback • How Railway uses cloud bursting while scaling its own infrastructure • Why data center debt can be a better tool than venture debt for infra startups • Why AI workloads may require Manhattan Project-scale infrastructure spend • Why AI SREs will nuke production unless safe primitives exist first • How Railway thinks about production forks, copy-on