Jake Cooper

Jake Cooper founded Railway in 2020 to reduce the friction of deploying software. His work spans infrastructure engineering and the decisions behind a deployment platform increasingly designed for AI agents. In his May 2026 Latent Space interview, he described the goal as making production deployment instantaneous and said Railway had deeply prioritized agents as a mechanism for building and deploying software over the preceding six months.[1][2]

Cooper recalled being a deep AI skeptic until 2023, becoming more receptive in 2024 and confident in using the tools in 2025. After winter break, he urged Railway staff to use coding agents and put their effort into reviewing and reconciling generated code. His instruction was direct: “If you’re writing code by hand, you’re doing this wrong.” He argued that architectural judgment remained essential: engineers should ask agents to produce code they understand, then refine it until it matches their intended implementation.[1]

That enthusiasm remained conditional for AI site reliability engineering. Cooper argued that agents need safe infrastructure primitives before they can change production systems. His proposed approach uses forked environments close to production, read-only production copies, transformations for personally identifiable information, and copy-on-write storage. These mechanisms would let an agent test a fix without relying on a staging environment that has drifted from production.[1]

His engineering thesis joins specification, code and tests in a reconciliation loop. If the specification and tests agree but the code differs, fix the code; if the tests and code agree but the specification differs, reconcile the specification. He also reported setting up a Railway-hosted process with Railway CLI credentials that could change its own environment and redeploy itself. Broader safe self-replicating infrastructure was a direction he wanted to pursue.[1]

Cooper sees the CLI as an interface through which agents can deploy, retrieve logs and query changing system information. Commands and flags that overwhelm a human can give an agent useful handles for completing a task. He envisaged Railway’s visual canvas increasingly becoming an output: a shared representation of infrastructure that helps humans understand changes and decide whether to approve them. His forecast that “Pull request is definitely dying.” accompanied a continued emphasis on versioning, feature flags and progressive rollouts.[1]

Cooper reported personally rebuilding Railway’s network overlay over a weekend after an upstream provider’s compute quota constrained capacity at the start of 2026. The rebuilt overlay could span five clouds, including Oracle, AWS, Railway’s own infrastructure and GCP; he left the fifth provider unnamed. He also described patching Railway’s Linux kernel fork for an agent-oriented storage layer. Those patches were internal work, rather than upstream Linux contributions.[1]

Cooper explained Railway’s limited use of Kubernetes as a choice to retain greater control over workload placement and resource reuse for parallel agents. He credited the team with building Nixpacks and its successor, Railpack, to determine dependencies from source code. In his assessment, maintaining multiple versions of Nix packages could inflate package space and image sizes. He described subsequent work toward content-addressable filesystems that could lazily load files and page them into memory.[1]

Cooper repaired bare-metal builders whose factory RAID1 configuration incorrectly included the EFI partition, according to Eduard Ganiukov’s Builder v3 account. His repair accompanied Ganiukov’s implementation and rollout of cgroup v2 isolation, which reserved CPU and memory for control daemons so build workers could not starve BuildKit’s daemon and stall builds by interrupting its Temporal heartbeats.[3]

Cooper also described Railway’s in-house Central Station as a way to cluster customer feedback and support requests, detect emerging incidents and route context to relevant staff. The work was collective: interviewer swyx recalled helping with Angelo in 2023. Cooper advocated broad incident disclosure, including issues affecting small subsets of users, so customers could understand what happened and how Railway intended to address it.[1]

Before Railway, Cooper’s work supplied practical experience with long-running distributed workflows. He recounted starting with front-end work involving the porting of Wolfram Mathematica, spending a brief period at Bloomberg, then moving into distributed systems at Uber. There, he worked on moving Jump Bikes systems onto Cadence, the precursor to Temporal. A ride could be represented as a workflow that accumulated actions and charges until the trip ended.[1]

That earlier experience informed his evaluation of Temporal at Railway, where it ran the deployment pipeline, including hooks, signaling and queuing. Cooper valued the workflow model but warned that engineers needed to understand its state and replay behavior: changes could introduce nondeterminism, while growing workflows complicated state-machine reasoning and activity-slot management. He maintained that workflow engines still required decent tests.[1]

Cooper also built and tried to sell a simpler feature-flagging product before starting Railway. He abandoned it after encountering what he saw as an adoption mismatch: smaller customers did not prioritize feature flags, while larger customers required substantial infrastructure and scale. In the agent era, he argued that the same tools had become important for controlling the impact of rapidly generated software changes.[1]

During Railway’s early years, Cooper kept Discord open on a second monitor and immediately welcomed new arrivals, trying to get the first hundred users to return. He later temporarily cut off free users to rebuild the business. He reported losses of roughly $500,000 a month during the historical free-tier period and described the decision as making an experience people loved financially workable. He favored building systems over adding headcount simply to handle expansion.[1]

As a solo founder, Cooper described needing to attend to both go-to-market questions and kernel-level engineering. He uses writing and time away from work to clarify uncertain goals. His emphasis on focus also shaped product boundaries: in the May 2026 interview, he expected Railway eventually to need GPUs, but explicitly said it had no GPU plans at that point.[1]