Latent Space · 2026-05-20 · 89 min

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

Alessio FanelliswyxJake Cooper

YouTube ↗

TL;DR

Railway’s central bet is that agents will become the dominant software-building “species” over the next 10 years, making agent-native infrastructure a secular platform shift even if today’s boom hits an inference wall. Jake Cooper traces the abstraction ladder from assembly to C to C++ to JavaScript to “words”; the destination is thousands of agents working concurrently, where coordination, safe intervention, and compute efficiency become as important as code generation.
The company’s growth curve was earned through six years of expansion, painful compaction, and a deliberate repair of bad unit economics. Railway once burned roughly $500,000 a month against perhaps $50,000 of monthly revenue and a $20 million bank balance while free users attracted bots and crypto miners; it temporarily restricted free usage, rebuilt the business, and now operates with 35 people while adding about 100,000 users a week. The discussion cites both 2 million and 3 million user figures. Cooper rejects the idealized always-up-and-right chart: “You actually don’t want charts that look like that.”
Bare metal gives Railway both its margin engine and the economic headroom to support massively parallel agents. Cooper says hardware pays back in about three months versus renting equivalent cloud capacity, despite being depreciated over four years, while metal workloads carry margins around 70%; Railway reports that the vast majority of workloads now run in its own data centers and uses hyperscalers for bursts. The operating rule is categorical: “You never ever ever want to be waiting on compute anymore. You always want to be waiting on intelligence.”
Railway’s architectural moat is control over network, compute, storage, and orchestration at a workload scale where familiar abstractions may break. Agents need many of the same primitives as humans—version control, feature flags, logs, traces, files, snapshots—but “a thousand times quicker”; Cooper expects conventional CI/CD to “melt,” thinks something beyond Git may emerge, and wants systems whose components can be ripped out whenever a super-exponential workload exposes the next bottleneck.
The agent interface reverses conventional product design: complexity becomes useful input, while the graphical canvas becomes an approval and context surface. A human may hate a CLI with 40 arguments and 600 flags, but an agent sees “so many handles”; Railway measures where agents leave the happy path and adds handles to close the loop. Its canvas consequently shifts from input to output—a “port in the storm” where humans understand changes, preserve shared context, and approve or reject what agents did.
Autonomous remediation is unsafe without cheap, production-like forks, progressive delivery, and reversible state. Cooper remains skeptical of an AI SRE unleashed directly on production: without copy-on-write volumes, read-only production data, PII transformations, observability, and limited blast radii, “it’s not a matter of if, it’s a matter of when it’s going to nuke that database.” Railway’s answer is to let agents clone services and state, validate a hypothesis close to production, then merge or discard the result.
Railway’s roughly $300,000 monthly coding-agent spend is a bet that engineering output—not token thrift—is the relevant denominator. Cooper personally uses about $25,000 and told the 35-person company, “If you are writing code by hand, you are doing this wrong”; engineers should review and reconcile generated code while architectural judgment matters more than ever. His proposed ROI measure is the percentage of tokens that reach production, with the best operators treated like F1 drivers worth placing in a “$3 million car.”
Competitive focus is as important as technical ambition: Railway does not want to become merely “the new Heroku,” and it is declining GPUs for now. Cooper attributes Heroku’s stagnation to being peripheral to Salesforce’s core business, while Railway aims to own the full build-and-deploy loop without copying hyperscalers’ architecture. He is explicit that Railway will not offer GPUs now but “100% will” eventually because vertically integrated infrastructure ultimately needs FLOPs—an unusually clear statement of sequencing rather than scope denial.

Digest · the substance, structured for research

1. Railway wants to version application evolution, not merely deploy code

Cooper’s crisp definition is “the easiest way to ship anything”: use the canvas or talk to Claude, ask for a Postgres instance, a GitHub repository, or arbitrary code to run, and get it deployed without assembling the underlying cloud machinery.
The larger ambition is to stop “stacking entropy on top of entropy” through Docker, Kubernetes, Ansible scripts, and separately maintained environments. Railway wants to version the whole software system so users can clone environments, fork a “parallel universe,” copy production data and services, validate changes, and collapse the successful branch back in.
That makes deployment only the opening move. The durable loop is application evolution: create infrastructure, observe it, alter it, test the altered universe, and merge it without rebuilding an increasingly divergent staging stack.

2. Product experience repeatedly pulls Cooper deeper into the stack

Cooper’s path from front-end work through Bloomberg and Uber was driven less by a predetermined infrastructure résumé than by curiosity. At Uber, making JUMP bikes feel frictionless led him into distributed systems built over Cadence, the precursor to Temporal.
His operating principle is to “swim to the bottom of the swimming pool to go and get the experience right.” Railway therefore moved from an approachable deployment surface into bare-metal data centers, custom orchestration, storage work, eBPF, and even patches to the Linux kernel.
The kernel work concerned Railway’s storage layer for agentic workloads and was not yet intended as an upstream patch. Cooper’s broader claim is more revealing: “Anything is figure-outable”—depth is not the product, but no depth is off-limits when it blocks the intended experience.

3. The six-year growth curve contains a costly business period

Railway’s first hundred users came through “hell or high water.” Its support link led directly to Discord, Cooper kept the channel open on a second monitor, and the rarity of each arrival meant he could greet users immediately while trying to learn what made them return.
Initial demand produced a “consultancy factory”: users requested disparate features, forcing Railway to distinguish a coherent product from bespoke accommodation. Cooper describes alternating expansion—testing use cases by adding capabilities—and compaction, when the company removes distractions and makes the chosen experience significantly better.
The 2022–2023 free tier drove sign-ups but also Reddit bots, crypto miners, and internet abuse. During that period, Railway was losing roughly $500,000 monthly, had about $20 million in the bank, and perhaps only $50,000 in monthly revenue; it temporarily restricted free usage and rebuilt around a viable business.
Railway now has 35 employees and is adding roughly 100,000 users a week. The discussion cites both 2 million and 3 million user figures; weekday activation and visible summer or winter holiday dips increasingly reflect its B2B mix.

4. Agents are a dot-com-style secular bet, not a six-month feature cycle

Railway treated agents as a top-of-funnel opportunity before prioritizing them deeply as a building-and-deployment mechanism over the preceding six months. Cooper’s conviction is categorical: software abstraction has progressed from assembly through C, C++, and JavaScript to “words.”
His dot-com analogy preserves the risk: exuberance can collide with physics, economics, or an inference bottleneck, just as internet companies once returned to earth. Yet the internet still transformed life, so the long-duration decision was to build for it anyway; he sees agents in the same category.
Thousands of parallel agents create two distinct problems. Inference and compute must become much cheaper, but coordination is equally unresolved: agents need to version changes safely, cooperate, and know when to “put their hand up” without turning human oversight into “an interrupt factory that’s crazy.”

5. Bare metal provides a three-month payback and a higher product ceiling

Railway wants direct control of network, compute, storage, and orchestration, including workload placement that Kubernetes does not expose at the required order of control. Memory reuse and precise placement matter because inefficiently running thousands of agents would “massively, massively blow up your cost structure.”
Building a site begins prosaically: rent power and a cage from a colocation provider such as Equinix, fill it with racks and servers, and connect it to the internet. Cooper says Railway has two data centers in every other region, while Singapore is scheduled to receive a second site in Q3.
Cooper estimates a three-month payback when comparing purchased metal with rented cloud capacity, despite depreciating the hardware over four years. Railway’s servers even appreciated after its financing because RAM prices rose; he contrasts that scarcity with hyperscaler capital expenditures of roughly $80 billion in the cited year.
A host’s space-data-center pushback exposed Cooper’s epistemic boundary. He thinks the idea might be solvable but has not seen anyone demonstrate heat dissipation at that scale in a vacuum; the host presses the thermodynamic constraint, while Cooper calls the investment distinction between “a grift” and something viable but insane a coin flip resolved only years later.

6. Hybrid bursting keeps growth from becoming hostage to procurement

Railway began on public clouds, built migration machinery for its own metal, and now reverses that flow when necessary: burst onto AWS, GCP, or another provider, then “compact” workloads back onto owned servers once space, power, and hardware arrive.
That flexibility became essential when an upstream provider could not grant quota quickly enough and available hardware was slower. Cooper spent a weekend rebuilding Railway’s network overlay to straddle five environments—Oracle, AWS, GCP, Railway’s own infrastructure, and another cloud—after tight packing contributed to reliability problems.
Metal margins of roughly 70% can subsidize expensive bursts, preventing temporary demand from being rejected. Revenue can therefore scale approximately as fast as compute is deployed, provided Railway keeps the build-and-deploy loop trivial and allocates capital with sufficient operational discipline.

7. Hardware debt and venture equity solve different problems

Railway’s capacity plan combines owned metal, cloud overflow, cash, hardware-backed debt, and venture capital. Cooper calls this a genuinely interesting operating problem: determine how much capacity to buy, how fast it can be installed, and which financing instrument belongs against each asset.
Its server financing is secured by the hardware at roughly prime plus a spread and can be refinanced as the outstanding debt goes down. Cooper rejects the context-free label “venture debt bad”: this is “data-center debt,” matched to a specific productive asset rather than used as a generic substitute for equity.
Because venture capital is the most expensive financing, founders should ask what “unfair advantage” they can buy with each dilution. Railway selected investors at successive stages for founder guidance, product autonomy, operational scaling, and enterprise access, aiming to align the board around “How do we win this?” instead of debating basic strategy.

8. Agent scale preserves infrastructure primitives while breaking their implementations

Agents still need feature flags, version control, observability, files, snapshots, network, compute, and storage. The distinction is speed and concurrency: “We’re just moving a thousand times quicker,” so existing tools must become massively better even when the conceptual need remains unchanged.
Cooper expects CI/CD to “melt” and argues that orchestration may need to exceed Kubernetes while networking may need to exceed Envoy. Because a new parallelism breakthrough can move the bottleneck elsewhere, every layer must be replaceable rather than treated as permanent architecture.
His provocative framing is that GitHub’s “original sin” is a collection of broken pointers: cloning separates a project from upstream, while merging treats change discretely. He imagines percentage-based or nondeterministic versioning where updates stream progressively through populations instead.
That progression should begin with low-impact users such as “Johnny Vibe Coder,” while an institution such as JPMorgan sits last on the patch line. Someone must absorb real-world entropy, but blast radius should be explicitly ordered by the cost of failure.

9. Agent-facing CLIs benefit from complexity that repels humans

A human receiving a CLI with 40 arguments and 600 flags would refuse to learn it; an agent responds, “This is excellent.” Every argument becomes another handhold for querying dynamic state, taking an action, and closing the build-observe-correct loop.
Railway instruments those loops. If telemetry shows 12% of journeys leaving the happy path at one command, adding the missing argument and reducing that to 2% materially raises successful completion across the user base.
Cooper maps the product journey from hearing about Railway to a first green build, endpoint, or useful log, followed by endless iteration. The objective is to destroy every compute delay: “You always want to be waiting on intelligence,” because any persistent compute bottleneck eventually causes users to find another workflow.
He expects push-pull-rebuild deployment itself to disappear. A small production change should be versioned across infrastructure and copy-on-write data, tested alongside the live system, then merged into production instantaneously.

10. The canvas becomes an output surface and a shared memory

The hosts argue that Railway’s famous visual canvas was designed for humans, whereas the CLI now matters more to agents. Cooper agrees with the direction: the canvas is moving from an input device toward an output that shows what infrastructure and agents changed.
Its human task becomes presenting enough information to approve or reject a control request. Cooper calls it an “anchor for your context” and a “port in the storm”—a hierarchy that can drill from a project into services, functions, code, infrastructure, and arbitrarily nested context.
Shared representation matters because organizations slow when a microservice exists only in one person’s head. Cooper believes sufficiently structured context could support “hyperstructures” larger than today’s coordination systems allow, contrasting that with Slack and Discord’s repetitive pattern of “message passing and interrupts.”
Railway’s in-house Central Station aggregates support conversations and feedback into dynamic clusters, detects brewing incidents, measures affected users, and routes discussion toward the people closest to the relevant subsystem or commits. The discussion also notes that the company is now roughly 10 times bigger than it was around the 2023 work, without clearly specifying which measure “bigger” refers to.

11. Progressive rollout and overdisclosure are both reliability primitives

A recent incident was scoped to roughly 3,000 users when an upstream provider behaved differently from its own RFC documentation, producing cache-invalidation failures. Central Station surfaced the initial reports, Railway disabled the rollout, and the company subsequently hardened the affected systems.
Cooper’s disclosure policy is to risk saying too much rather than let users feel their provider is gaslighting them. Railway roots that choice in its “honor” value: notify the broadest population that might have been affected, confront the failure, and explain how recurrence will be reduced.
Railway uses incremental rollout to limit blast radius. Referencing Meta’s many simultaneous production versions, Cooper argues that agents also require shadow traffic and safe behavioral variants; Railway’s larger customers should receive deeply stable versions only after low-impact cohorts have exercised changes.
His proposed version stream might move from 0.1% to 1%, then through early adopters and eventually the full population. Most mature companies build this machinery internally, creating an opportunity to consolidate it into platform infrastructure.

12. AI SRE needs production-like forks before it earns write access

Cooper grants that perhaps 80% of an observability agent’s suggested fixes will look sensible. The dangerous long tail remains: a plausible fix stamped directly into production can create an incident unless the platform constrains its impact and makes rollback structural.
Conventional staging is insufficient because it drifts from production. Railway wants an agent to clone any implicated service, attach a read-only or copy-on-write version of production data, transform PII where required, run its hypothesis, and present a new infrastructure state for human approval.
Cooper visualizes the agent as a figure moving beneath a transparency sheet representing the canvas: it identifies the services it needs, copies only that slice of the system, runs the experiment close to production, and either merges the verified branch or discards it.
His change of mind is carefully bounded. He was broadly skeptical of AI until 2024, said he could trust it in 2025, and after winter break said it had become “almost harder to use it wrong than it is to use it right”; he still rejects autonomous AI SRE without safe storage and deployment primitives.

13. Specs, code, and tests reconcile fuzzy intelligence with discrete systems

Cooper does not advocate replacing deterministic software with fuzzy logic. Skills should invoke code or applications with static structure; the agent can distill procedures, but execution still needs conventional constraints.
His emerging three-part system is a clear specification, the code, and tests—essentially the familiar RFC, implementation, and verification artifacts kept together. If spec and tests agree while code fails, the agent reconciles code; if another pair diverges, it works the corresponding edge of the triangle.
He dismisses elaborate “software factory” diagrams as “architectural astronomy” when nobody implements them, yet believes the reconciliation loop itself is where agentic development will settle.
Railway can already host a recursive version: install the Railway CLI inside an agent running on Railway, authenticate it to its environment, let it provision Postgres or another service, then call railway deploy to redeploy itself. Safe, cheap throwaway copies turn self-modification from stunt into an iterative production workflow.

14. The next serverless model is indefinite, stateful, and fully Linux

Cooper places Railway between static servers and traditional serverless: workloads may be stateful and long-running, yet users should pay only for resources actually consumed rather than reserve an idle box indefinitely.
The atomic deployment unit must start instantaneously, run as long as necessary, expose a full Linux environment, and disappear cheaply. That follows Railway’s six-year insistence that users need “a box that speaks Linux” plus flexible network, compute, and storage.
Static allocations such as four vCPUs and 16 GB of RAM become prohibitive when replicated for a thousand agents. Resource sharing, snapshots, lazy loading, and tighter scheduling must preserve general-purpose computing without multiplying fixed-instance economics.

15. Heroku’s decline is a warning about strategic adjacency

Cooper is unsurprised that well-known companies are asking Railway to move workloads from Heroku. His explanation is organizational rather than technical: Salesforce’s business is CRM, while acquired compute infrastructure remained an offshoot competing internally for budget, talent, attention, and mission.
The hosts note that Heroku’s public communication celebrated an “incredible journey” without explicitly declaring shutdown, while Cooper says private guidance reportedly told customers to close accounts as services were deprecated. The episode preserves that distinction rather than treating the public release as a clean termination notice.
Heroku was foundational to Cooper’s own deployment experience, but Railway does not want the limiting identity of “the new Heroku.” It wants to become the way software is built, deployed, and eventually monetized; familiar game loops can migrate, though features such as Heroku Pipelines currently map only approximately to Railway environments.
That ambition does not license immediate adjacency. Cooper says Railway will not offer GPUs now, even as others rush into the category, but “100% will” at some future point because a vertically integrated platform eventually requires FLOPs.

16. Temporal is a jet engine; Railpack reflects the same abstraction test

Cadence once powered Uber’s long-running trip workflows, attaching events and charges until a ride ended; Temporal carries that powerful idea forward. One host describes it as programming an entire user journey top-down as a function, a model well suited to agents that must complete or suspend durable tasks.
Cooper’s decade-long critique is that Temporal requires developers to hold the entire workflow journey in their heads. Deterministic history replay can surface nondeterminism after an innocent change, while signals, queues, activities, pre-commit hooks, and worker-slot tuning turn Railway’s deployment pipeline into a large state machine.
His analogy is a “jet engine”: extraordinary when operated correctly, but hazardous when handed to someone without full system context. Railway might eventually build a narrower workflow engine around its own abstractions; Cooper also identifies Restate as doing interesting work.
Railpack follows a related lesson. Railway replaced Nixpacks, whose Nix-based stack of versioned binaries promised reproducibility but produced image bloat and scaling pain across diverse machines; rather than split users into constrained runtimes, Railway is pursuing content-addressable file systems that lazily load data and page it into memory.

17. A $300,000 token bill makes deployment, not generation, the bottleneck

Railway expects to spend roughly $300,000 on coding agents in the cited month, with Cooper personally around $25,000 despite a company of only 35 people. His internal instruction was blunt: “If you are writing code by hand, you are doing this wrong.”
That does not discard engineering craft. Architectural patterns “matter more now than at any other time”; the engineer should ask an agent to generate known work, review it, and reconcile the result until it resembles what the engineer would have written.
Agents let Railway prototype block storage, author thousands of tests cheaply, and “speedrun your roadmap.” Projects once expected to take years can sometimes move into a months-long horizon because the company can validate a future architecture beside the existing one and skip intermediate implementations.
Spending will meet CFO scrutiny before purely technical limits disappear, and inference prices still need to fall. Cooper’s F1 analogy segments users by skill: the exceptional operator merits the $3 million car, while the naïve corporate metric is “the percentage of tokens that end up in production,” not total tokens consumed.

18. The cloud rebuild ends with prompts, flags, snapshots, and focus

A host predicts the pull request will become a “prompt request,” with conventional code review shrinking only when specs, tests, rollout controls, and observability absorb its safety function. Railway already sees more pull requests waiting unmerged, demonstrating that code production can outrun deployment capacity.
Feature flags become foundational under thousandfold concurrency. Cooper previously failed to commercialize a simpler LaunchDarkly because small companies did not care and large ones demanded enormous scale; agentic development makes that formerly enterprise-only control necessary for everyone, from shadow traffic to explicit blast radii.
Railway has an internal flagging engine but will not expose it until behavior works across multiple services and environments. Shipping a partial experience would create fragmented concepts and support load—the company’s product rhythm remains expansion followed by compaction and polish.
Cooper even challenges “cattle, not pets”: pets are safe if there is a cloning machine. Snapshot every filesystem state, lazily restore it, and merge a verified filesystem change; much Dockerfile and Ansible ceremony existed to protect irreplaceable state, so ubiquitous cloning could remove the premise.
As a founder, Cooper handles technical and commercial work through obsession across the stack, while warning that two co-founders without explicit ownership or a CEO tiebreak can deadlock. His personal cadence is sunup-to-sundown Monday through Friday, Saturday disconnected, and Sunday afternoon for writing and planning—though “most advice is to be digested and thrown out the window.”
Railway’s final thesis is to build a new cloud without copying hyperscalers’ homework. The transcript later says most workloads run on its own metal; the share once reached 100%, then rapid growth pushed it back into the 90s. The target is “no friction” between thought and deployed reality, even if achieving that eventually requires descending through every software layer—and perhaps down to energy itself.

Jay Cooper

If you are writing code by hand, you are doing this wrong, right? The tools are good enough at this point that you can move extremely, extremely quickly. Yes, there are issues and pain points and all these other things, but you should be reviewing the code that you are writing instead of trying to write it by hand. All of those architectural patterns, all of those other things—you’re not just going to throw them in the garbage or whatever. Actually, they matter more now than at any other time.

But you just shouldn’t spend your time generating code that you would write. If you know how to go in and write it, just ask the agent to go in and write it, and then reconcile it until it looks like you would have written it.

Shawn Wang

Hey, hey. Today we’re in the studio with Jay Cooper of Railway.

Jay Cooper

Conductor of Railway.

Shawn Wang

Conductor at Railway. Yeah. Choo-choo.

Jay Cooper

I don’t have a business card. We’re not that big yet. At some point I will. I got handed a nice business card from the Supermicro folks, and I was like, “Damn, that’s actually pretty official.”

Alessio Fanelli

Business cards.

Jay Cooper

Yeah, they’re cool. They’re hip. They’re jiggy. But the whole conductor thing: we call some of our volunteer moderators conductors. We’re trying to figure out what we want to call each other internally, and there are varying levels of thought. Some people are like, “Oh, it’s super cringe. You don’t need a name for people internally,” and some people are like, “Oh yeah, we want to call each other this thing or whatever.” We still don’t have a really good one. We’ve got new rail recruits, we’ve got Trainiacs, but nothing’s really—

Alessio Fanelli

For those who don’t know what Railway is, let’s give people a crisp definition up front.

Jay Cooper

Railway is the easiest way to ship anything. You just go to the Canvas or talk with Claude and say, “Deploy a Postgres instance,” “Deploy my GitHub repository,” “Run this code,” et cetera, and you’ll be up and away to the races.

Alessio Fanelli

Yeah, you have a nice animation on the landing page.

Jay Cooper

None of my work, by the way. They don’t let me touch any of the design stuff anymore. But we want to make it really easy not just to deploy things, but for you to almost evolve applications over time. We believe that most of the tooling right now is stacked up like you’re stacking entropy on top of entropy on top of entropy.

You have Docker and Kubernetes, then Ansible scripts and all of these other things. If we can version all of your software for you and keep track of all the changes, then we can make it trivial for you to clone environments, fork into a parallel universe, get copies of production data, get copies of any of your services, make those changes, validate those changes, and collapse it in without having to reproduce everything across a staging environment or all of those other things.

Alessio Fanelli

One thing I was looking at in your background: Bloomberg, Uber. There’s nothing immediately that stands out to me as, “Okay, this guy’s going to found the next great platform as a service.” What prepared you for Railway? It’s almost like a curiosity—just to ever go deeper, right?

You started out on front-end stuff, working on Wolfram webMathematica and porting it over there, then briefly moving to Bloomberg, and then moving toward Uber and distributed systems, taking all of the JUMP Bikes’ systems and moving them over to a distributed system built on top of Cadence—the pre-Temporal Temporal.

Shawn Wang

By the way, I’m happy to talk about the pros and cons.

Alessio Fanelli

Yeah, I think it’s like—let’s do the Railway story.

Jay Cooper

It’s just been a continual step of: I want this experience, whether it is walking up to a bike and unlocking it and having it be frictionless to work, or necessitating the depth required to go in and make that happen. A lot of the work that I do and a lot of the team does is all in service of that experience.

We fundamentally don’t care how deep we have to go. We will swim to the bottom of the swimming pool to get the experience right. I think that’s what a lot of the trajectory was. It’s not like I have a physics PhD or whatever. I did an EECS degree. It’s just always been about trying to figure out that next step of how we get there.

That’s what’s led to starting Railway for that experience and then moving all the way to bare-metal data centers. I was adding patches to the Linux kernel this week just to get the experience there, because I see how much better it can be.

Alessio Fanelli

Yeah, patches to the Linux kernel this week.

Jay Cooper

Yeah. Well, not upstream.

Alessio Fanelli

Railpack? No, this is different. This is the OS on top of Railpack.

Jay Cooper

Yeah, no, this is the actual kernel. It’s always literally just, “What do we have to do to get that experience?” You figure it out, right? Anything is figure-outable. You’ll just figure it out.

Alessio Fanelli

Would you send the patch upstream?

Jay Cooper

We have to work out the experience for us in general. It has a lot to do with the storage layer that we’re building for some of the agentic stuff. Maybe it’ll be useful to people upstream, but it’s deeply useful for us internally.

Shawn Wang

You mentioned open source before, so I’m curious how you think about starting from open source and then letting coding agents do a lot more from forks of it.

Jay Cooper

I think the funny thing is that GitHub’s original sin is that it’s almost a series of broken pointers. You have essentially this thing, and then you clone it, and then, okay, great—I’ve just lost that whole upstream, right? How do we make it trivial for people to modify really, really small pieces of it?

You think of Git as almost this discrete sense of, “I’ve either made a change and I’ve merged upstream, or I haven’t.” What would it look like if it were percentage-based or a little bit more nondeterministic? More like a stream of changes that you traversed as a user, or more as a percentage of this being rolled out in general and then rolled all the way up.

We have the open-source kickback program and allow you to deploy those templates because we want to make it trivial for people to version these shards over time. It solves a really, really large problem in terms of authentication, authorization, and security. npm has that thing where you can almost define, “Hey, don’t take any new packages,” or whatever.

The ideal end state is actually that you should roll out progressively to the users who have the minimum impact zone for any of these things and just continually roll up. JPMorgan or something else like that should probably be the last one on the patch line for that, for all of our sakes, because we have all of our money and all of those things. It’s okay if Johnny Vibe Coder gets a broken patch or something else like that, because ultimately there’s so much entropy in the system that you do have to roll. Rubber has to meet the road at some point; you have to test at varying levels.

Alessio Fanelli

I just wanted to pull up this glorious chart, which is basically your usage, or number of daily signups, I think. Daily signups. You started 6 years ago, and it was a slow grind. Now, obviously, you’re on a rocket ship. You say, “Don’t doubt your vibe and don’t quit.” Maybe you want to pick out certain points that were key inflections of the company. That might be fun.

Jay Cooper

Oh, yeah. Yeah, yeah. Well, at the start, it’s basically: How do you get your first 100 users? Hell or high water, right? We had a website and a support link, and the support link was the Discord channel. You just showed up there, and I had notifications on.

I had 2 monitors: the monitor I was working on and then the other monitor. If anybody came in, I was like, “Oh, hey, how’s it going?” It was super rare. We were trying to get those initial 100 users to actually come back to it.

And that’s, I think, where you can really see it—in between January 2021 and 2022, probably around the middle there, right? That’s the start. Then you ultimately end up building a consultancy factory because users wanted all of these things in general. You have to go back to the drawing board a little bit and be like, “What is the actual product offering that I want to build on top of these?”

Incidentally, it’s funny: I think VCs really want charts that always look like this, right? But in reality, you actually don’t want charts that look like that. Most companies—or at least for us—have had periods of expansion, where we’re going to add these features to test these use cases, and periods of compaction, where we’re saying, “If the experience we have is really, really good, how do we make it significantly better?”

Maybe we’re even stripping out features that don’t fit our ICP anymore. Throughout this whole chart, you can see a lot of those things. The boom from 2022 to 2023 is when we had a free tier, and everybody under the sun was using it, and all those other things.

Shawn Wang

A lot of Reddit bots and stuff.

Jay Cooper

And I think there’s a thing that’s really, really tough to teach people or tell people: when you build an open product on the internet where anybody can sign up, the internet is a horrible place that has so many things like—

Shawn Wang

I told you about my PC.

Jay Cooper

Yeah, like crypto miners. You have all these other things, right? So you kind of go through these periods of, “How do I reach as many people as possible?” and then, “How do I fit exactly the use case for the people who are really, really going to matter and be really, really excited about specifically this thing?”

We go back and forth internally. And then there’s a 2-year period of making the actual business work in general—the free-tier era.

Shawn Wang

We were losing, I think, half a million dollars a month on, like, a $20 million bank account.

Jay Cooper

Yeah, yeah. Like a $20 million bank account with maybe $50,000 a month in revenue or something. I was like, “That is horrible business.” But you have to go through and be like, “Cool, we have an experience that people love in general, but the business has to work,” right?

I think there are, I guess, 2 schools of thought: you can continually run the horrible business all the way up in general and have bad margins, or you can actually go back and make it work, right? For us, we’ve always really wanted to have a super lean team.

Shawn Wang

You’re 35 people right now.

Jake Cooper

We’re 35 people right now. It’s very, very small. We have, like, 3 million—

Shawn Wang

2 million. Yeah, yeah.

Jake Cooper

Because we’re adding, like, 100,000 users a week right now, right? So it’s growing really fast, right? But we’ve always wanted to have a really, really lean team. We don’t want to just add headcount for the sake of headcount or throw bodies at these problems. We want to build systems, right?

It’s really, really hard to build systems when you’re in that expansion phase because you’re just adding stuff to the system in general because people are asking for it or things are breaking in general, right? We basically were like, “All right, we’re going to cut it for now. We just can’t support these free users.”

We want to reach as many people as possible because we believe that software is this really, really important thing where, if you can create something, it’s become really difficult to create things in the physical world. So it’s really important to make it really easy for people to build things in a virtual world so that people have access to creation, right?

And so we want to reach as many people as possible. But there are kind of legs on that journey. We basically had to close off the free users for a little while, rebuild the business, and make sure that it worked in general, right? And I think you can kind of see the building of that in general, right?

Then you see some divots in those charts, right? If you actually follow the period between 2025 and 2026, it’s either summer or winter. That’s basically it, right? Either people go on holiday with their family, or they go on holiday.

Shawn Wang

Oh, it affects it that much?

Jake Cooper

Yeah, yeah. Well, because it’s kind of B2B in general, right? You have a lot of these users who are shipping constantly, and then they’ll kind of stop or whatever, right?

Maybe for summer, our activation curve is now that we see a lot of people activating on weekdays, because we have a lot more business users in general. So it gets a lot less sheer, so to speak, and it kind of smooths out over time.

Shawn Wang

Is there any point at which you started prioritizing AI developments or agent development?

Jake Cooper

I think we’ve prioritized agentic as a top-of-funnel thing. Over the last 6 months, we’ve deeply prioritized agentic as a mechanism to build and deploy things, just because we believe fundamentally the curve is so sheer and that is the way people are going to build and deploy software.

It almost fundamentally doesn’t matter if this is dot-com or not, because we’re all on the internet now anyway, right? If agents are going to deploy a bunch of things and we hit an inference wall at some point, then at some point we’ll go in and fix those problems.

That will be the dominant species over the next 10 years. We’ve moved from assembly to C to C++ to JavaScript to now words, right? And you’re going to need to be able to close that loop, right? That’s where it goes.

Shawn Wang

When you say dot-com, do you mean buying the domain?

Jake Cooper

No, no, no. I mean that there was a bunch of run-up in the dot-com era for companies because they were like, “The internet is really, really important,” and then you hit fundamental bottlenecks—laws of physics, math didn’t work, all those other things—and everybody went back down to earth.

But at the end of the day, it didn’t matter, because the internet is so impactful for our lives that, if you operate on a long enough time horizon, you should just build these things anyway. You can see where that’s going, right? That’s where I fundamentally believe a lot of the agent stuff is.

You’re going to get to a point where you’re running thousands of these agents in parallel, right? First, what’s the inference cost for that? What’s the compute cost? How do you make that efficient? All of those other things.

Second, how do you coordinate all this stuff? We have issues coordinating humans in general, right? We don’t even have good tooling for that. Now we’re starting to figure it out: How do you get agents to coordinate? How do you get them to safely version changes, or know when to put their hand up to get somebody to intervene, right?

Otherwise, it just becomes an interrupt factory that’s crazy.

Alessio Fanelli

Well, so maybe we’ll go right to the technical side of things. What are the core infrastructure or architectural beliefs of Railway that allow you to do what you do?

Jake Cooper

Yeah, I think the primitives matter a lot for us—like, a lot, a lot. We need to be able to do network, compute, storage, and orchestration all kind of around it. You need control over a lot of those things.

We’ve talked a lot about how we don’t really use Kubernetes because we want the higher order of control to be able to place workloads in very, very specific places, right? The reason for that is the thing we talked about previously: you have to be very, very efficient with these agents—memory reuse and all of those other things—or you’re going to massively blow up your cost structure, right?

Incidentally, being able to rack and stack your own servers and build your own metal unlocks a level of performance, one, but also cost, where you can say, “Those experiences that you want to offer, where you’re running 1,000 agents in parallel, are not massively cost-prohibitive,” right?

If you look at token use right now or compute use or anything else, those things are blowing up massively. Over time, those things are going to have to get a lot more efficient. You can get a lot of almost back-of-the-napkin balance-sheet margin, whatever you want to call it, to make those experiences solid by building your own metal, right?

And so, kind of to the earlier point, we’ve always tried to go a little bit deeper every time to make that experience.

It’s all in the service of offering that differentiated experience to as many people as humanly possible.

Shawn Wang

Yeah. You have a data center in Singapore.

Jake Cooper

Yeah. We have 2 in every other region now. Singapore—we’re adding a second one in Q3.

Shawn Wang

So, what’s it like? I’ve never built a data center.

Jake Cooper

We’ll have to go to one or whatever.

Shawn Wang

Go to Equinix and say, “Hey, I want some.”

Jake Cooper

Yeah. I mean, I can Equinix. Equinix.

Shawn Wang

I mean, you can put a data center in the steam room and get nice and hot or whatever.

Jake Cooper

Yeah. You basically just go and say, “Hey, listen. I want power and I want a cage,” and they’re like, “Great. Here’s what it’s going to be.” Then you rent the cage for a period of time, fill the cage with racks of servers, and hook up internet to it. That’s realistically it.

Shawn Wang

And then they handle everything else, right?

Jake Cooper

Yeah, you just handle everything else, right?

Shawn Wang

What’s the math versus, obviously, the clouds?

Jake Cooper

Our payback period when we go to metal—if we rent it in the cloud, our payback period is about 3 months.

Alessio Fanelli

It goes crazy.

Jake Cooper

It’s nuts. That’s 4 years’ worth of depreciated hardware, right? I think you’re going to see a lot of this compute crunch, so to speak, because a lot of the hyperscalers are buying up a lot of stuff. We’re working directly with OEMs and retail resellers, and directly with people who are building these machines, like Supermicro, Dell, and all those other companies, to get these things working.

Upstream, there’s a bunch of supply issues. It was funny because when we raised our last round, in between deploying the capital for the servers and actually—I think even now—the amount of money that we’ve raised is less than the amount of money that we have in the bank plus the value of the servers. The servers have actually appreciated in value because RAM has gone up in general.

It’s kind of nuts, just in terms of how valuable hardware and all of this stuff is. If you look at a lot of the hyperscalers, they deployed, like, $80 billion of capital expenditures this year, and into next year it’s going to be more in general. There are these massive-scale infrastructure builds, and you can look at that and think, “Wow, that’s crazy that they’re spending way more than the Manhattan Project.”

But again, if you go back to every person running dozens or hundreds or whatever of agents in parallel—

Alessio Fanelli

You should spend more than you have. You have no conceptual idea of how much compute is required to go in and make that experience happen. Even if you’re deeply efficient, even if you’re sharing resources, even if you’re doing all of these things correctly, that doesn’t even count inference.

Shawn Wang

How do you plan out the buildout? The growth chart is so vertical. Are you usually at 100% utilization as soon as you’re live with these racks, or how far ahead are you?

Jake Cooper

We still maintain a cloud presence for bursting, essentially. We work with AWS, GCP, and a few of those other clouds. We can just rent capacity, and the moment we get space or power or whatever, we almost just compact those instances off the cloud.

We started on the clouds, and then we built a system to allow us to migrate to our own metal. There’s nothing that says you can’t just continually do that again, which is exactly what we do right now. We never want to be in a spot where we’re compute-constrained.

At the start of the year, we actually got to a point where we were compute-constrained because the one upstream provider we were working with wasn’t able to give us quota at the rate that we needed, and the hardware was slower. We had to do a bunch of different things. I spent a weekend rebuilding our entire network overlay, essentially, so that we could straddle 5 different clouds.

Alessio Fanelli

Right.

Jake Cooper

Yeah. Oracle, AWS, ourselves, GCP, and 1 other one. We can do more than that now, but we got into a spot where we were just trying to pack instances tightly because we couldn’t get the amount of compute that we needed.

It was really unfortunate because, as a result, we had a few reliability issues, which are now behind us. But it was all a result of this. I made a tweet where I got in trouble because I was trying to point it out, but I accidentally caught the Supabase folks in the crossfire.

The tweet was about how it’s really, really difficult, and it’s going to become more and more difficult, to acquire compute at the rate that these models need to acquire compute. We got bitten by it, which is fair and reasonable in the karma scheme of me trying to point it out.

Shawn Wang

How do you think about pricing, knowing that you might not have your own metal available at all times? Are you pricing assuming that you’ll need to pay yourself extra margins if you end up having to go into the cloud?

Jake Cooper

Because we’ve built out our metal data centers, our margins on metal are quite high—around 70%. We can deeply subsidize the cloud business if we want to scale at a reasonable rate.

We have a few different levers on how we can scale it. You have the metal, which actually makes your margins. You have cloud bursting. You have debt that you can use to buy servers in general. It’s a very interesting operational problem to say, “Okay, we have this much cash. How much money should we raise? How quickly can we deploy it?”

Then, obviously, you have venture capital that you can raise on top of it. We can scale revenue as quickly as we can scale compute, provided we continue to make it trivially easy for people to build and deploy.

The faster you can close this loop, and the more operationally excellent you are with the capital, the faster your business can grow. It’s basically a straight-line deployment rate on some of that stuff.

Shawn Wang

I think infrastructure startups raising debt is a tool that people don’t utilize enough or know enough about. What can you tell us about that?

Alessio Fanelli

Yeah, I mean, is it secured against your CPUs or what?

Jake Cooper

Yeah, it’s secured against our hardware.

Shawn Wang

What rates do you get? From whom?

Jake Cooper

We just pay prime, whatever it is, plus some amount. We can refinance any of the debt as it goes down. The terms are pretty good from that perspective.

The unfortunate thing is that Twitter has no nuance. They’re like, “Venture debt: bad,” or whatever. It’s like, well, no. As with all things—

Alessio Fanelli

It’s not venture debt.

Jake Cooper

Yeah. Or data center debt.

Shawn Wang

Yeah. It’s data center debt, right?

Jake Cooper

There are specific tools in specific areas where you can be very deliberate about not just using 1 specific tool as a hammer—venture capital as a hammer for everything. You just have to go out and explore it and figure out how it works.

Shawn Wang

VC is the most expensive financing you can get.

Jake Cooper

Yeah. Incidentally, I think people also think about VC completely wrong from a raising-capital perspective.

Alessio Fanelli

Okay. Tell us how VC is wrong.

Jake Cooper

Most people are like, “Okay, how do I raise as much money as possible from whoever is probably the best that I can get at that point in time?” I think that’s close to right, but I think what you should be doing—or at least what we’ve tried to do—is figure out what unfair advantage you can buy with that equity.

It’s the most expensive equity you’re going to give away at that point in time, assuming your company is going to get better and better and better. How do you use that to work with somebody who is stellar and who’s going to complement you?

Shawn Wang

Yeah, like serious—

Jake Cooper

Lucky. Yeah, yeah, right. Great. I’ve never started a company. Race race Milwaukee. He’s got good advice. I can text him all the time. He’s really fast. Awesome.

Then you move on and work with John and Jordan at Unusual. They were like, “Yeah, you roughly know what you’re doing in building a product. We’re just going to mostly leave you alone and be totally available for advice.”

Amazing. Awesome. You get to Series A, and the business is a total operational tier because we just don’t know how to scale a business. Go and work with Erica and Jordan over at Redpoint. It’s a bonus—we get to work with them continually.

Now, moving into the enterprise, we raised from TQ and FPV, and we’re moving into the enterprise now and feeding into that. Every step of the way, we’ve moved toward asking, “Who can we partner with at this specific time who’s going to help us unlock that next section of the journey?”

Because I don’t know enterprise sales. I can roughly eyeball it and say, “Yeah, as an engineer, I think these are the kinds of features that we’re roughly going to need.” We have some wonderful people who are going to help us internally, but you really want to work with those people at the boardroom-dynamic level. They’re going to be like, “Oh, yeah, we’re all aligned, and that’s obviously what we want to go and do.”

Then we can spend our time saying, “How do we win this?” versus bickering about strategy, right?

Shawn Wang

Uh, no.

I just had to pull up some beautiful data center charts.

Jake Cooper

I feel like you've done others. I couldn't find them.

Shawn Wang

Well, these are good. They all kind of look the same—the servers in a rack.

Jake Cooper

Yeah, exactly. This is our box. Do you want to see more racks? It's like, "Oh, yeah." You know—

Shawn Wang

The J. Cooper signature edition.

Jake Cooper

Yeah, yeah. It's a—

We have plans internally. Yeah, so it'll be fun. We've got a few different promos that we're going to do, and stunts for the year, so those will be fun.

Shawn Wang

Yeah. You had a tweet about data centers in space just before we wrapped this section.

Jake Cooper

Yes.

Shawn Wang

Why no data centers in space? Why do you hate them so much?

Jake Cooper

So it's not "no data centers in space," because my hot take is that I think this is solvable. I've just never seen anybody solve it, right? Because you need to—

Shawn Wang

No, no, no. Well, you said, "How are you going to dissipate that much heat in a vacuum?" You're making a physics claim.

Jake Cooper

Yeah, yeah, yeah. Because I haven't seen anybody prove how you're going to dissipate that much heat in a vacuum, right? It doesn't mean that it's not possible. It just means that nobody's put it up.

Shawn Wang

Pardon?

Jake Cooper

Astrophage.

Shawn Wang

The Martian thing. Okay, you're very loyal.

Jake Cooper

Yeah, that's fair. But, yeah, I don't know. It could work in general, right? But I think a lot of people—and I think, incidentally, this is probably what you have to do—are putting the cart before the horse. It's like, "Oh, yeah, we're going to put data centers in space." It's like, "Okay, but how?" It's like, "Well, we have some period of time to basically figure it out," right?

In The Martian, they're like, "Oh, how are we going to intercept with—"

Shawn Wang

Oh, okay, right.

Jake Cooper

It's like, "How are we going to do that?" It's like, "Well, we'll figure it out. We have however long to go and figure that out," you know, so—

Shawn Wang

Yeah, yeah. Making a bet on human invention is weird because you just have to blindly trust that it can be solved.

Jake Cooper

100%, right.

Shawn Wang

I feel like there are some first-principles bounds that you can put on it, maybe not—

Jake Cooper

Yeah, I know, right.

Shawn Wang

Maybe you're asking to violate travel time here, or break some fundamental thermodynamic law.

Jake Cooper

Yeah, and I don't know how VCs do this, incidentally, too, because how do you know what's basically not possible and is a grift versus what is possible but sounds completely insane, right? You're like, "Oh, cool. We're going to put data centers in space." It's like—

Shawn Wang

Okay, coin flip as to whether that's one or the other. You just don't know, I guess. And I guess you'll know in 10 years.

Jake Cooper

Yeah.

Shawn Wang

Cool. That's one cycle.

Jake Cooper

Okay, okay.

Shawn Wang

Yeah. Moving back to agents. I think the branching that you do—the fast spin-up and orchestration—is kind of the pre-work that happened to be exactly what agents want.

Jake Cooper

Yeah.

Shawn Wang

What do agents want differently than humans?

Jake Cooper

What do agents want differently than humans? I think they want the ability to version things. It's not actually that different; there are just almost slight deviations in terms of how it materializes, right? Agents want a way to be able to test changes incrementally, right?

We have feature flags as engineers, right? Is there any reason why they can't just use feature flags? I don't think so. I think there are ways that you can just go in and do that, right? They want version control. Is there a way we can use Git or not Git? I think that one is realistically completely up in the air, right? I do think something outside Git will ultimately emerge in terms of how we're going to version a lot of these things over time.

They need observability. You need to be able to query what happened at what point in time, which steps failed—traces, logs, metrics, all those other things. They need network, compute, and storage. They need the ability to write files, save files, iterate on files, snapshots, file systems—all of those other things, right?

I think a lot of the stuff that we needed is very much in line with a lot of the stuff that agents also need, right? The branching and forking stuff isn't different. We're just moving 1,000 times quicker than we used to. Some of these things look like you really need something massively different, but you need something massively better than what currently existed, right?

You need orchestration. You need something massively better than Kubernetes, right? You need networking. You need something probably better than Envoy, right? It just goes all the way down the stack, essentially. If the workload profile doesn't change so much as it gets massively compressed because you need to do thousands of these things, what assumptions change? CI/CD is going to melt, right? You need to replace it with something.

I think you can go all the way down the stack and basically say, "Okay, that part has to change, and that part has to change, and that part has to change." The interesting thing about the super-exponential curve is that you have to build your systems in such a way that you can rip out those parts at any point in time, because a new bottleneck might emerge.

You start getting really, really good at parallel agents, and then that's where the new bottleneck is, right? That breaks a different part of your system. I think it's very much similar stuff to what humans have needed; you just need it at a 1,000x scale. How do you do code review in the age of agents, I guess, is more of a question.

Shawn Wang

More agents who don't.

Kurt Mackey

Yeah, right. But then who reviews things for CVEs and all those other things?

Shawn Wang

Yeah, right.

Kurt Mackey

Okay. And then that's how we hit the inference wall at some point, right? You can continually throw agents and agents and agents at that problem, but I think there's a limit to the number of agents you can throw at a problem.

Shawn Wang

You started, though. You already had a CLI before it was cool. How has—

Kurt Mackey

CLIs have always been cool, by the way. But, yeah—

Shawn Wang

How has the shape of what you're exposing changed, if at all?

Kurt Mackey

I think the CLI changes because the way that we think about this is: how do you give Claude, Codex, ChatGPT, or whatever—any of these models—almost like a handhold?

A CLI is a single command when you think about it, right? It's like, "Okay, well, you're going to do a deploy," or whatever, right? "You're going to get logs," whatever. Things that were prohibitively annoying to humans are not actually prohibitively annoying to agents. They're really, really nice, right?

If I wanted to hand you a CLI and I said, "Hey, guess what? The CLI has 40 arguments and 600 flags," you'd be like, "Wow, that's crazy. I'm never going to use all those things," right? But if you hand it to an agent and you say, "Hey, there are 40 arguments and 600 flags," it's like, "Oh, yeah, this is excellent. I have so many handles that I can work with here," right?

If you're going to try to expose things for agents over that mechanism, you want to basically have as many handles as possible where they can get information, query additional dynamic information, and then see how they can close that loop as quickly as possible.

Most of the problems right now are just: how do you close the loop as quickly as possible? Where does the agent get stuck, and how can you remove that? That's why telemetry is very, very important, because if you can tell where the agent gets stuck from the CLI and say, "Hey, listen, 12% of people are actually getting diverted from the happy path because of this thing," and then add this argument and drive that down to 2%, you've massively increased the rate of the loop closing for a lot of people in general, right?

That's the way we think about not just the CLI, but every point in the dashboard, right? It is a user journey from, "I hear about Railway," to, "I go and get something deployed." I get my first green build, whatever—an aha moment. I see an endpoint. I see some logs. I see whatever. Then I go and iterate, right?

The iteration loop is indefinite and infinite until the end of time. It's basically, "The user wants to deploy a new thing. The user wants to deploy a new Postgres instance. The user wants to change their code. The user wants to iterate," all over time, right?

If you focus on a lot of those iteration loops and figuring out what's blocking that loop from closing as quickly as possible, one of the things we talk about internally is that you never, ever, ever want to be waiting on compute anymore. You always want to be waiting on intelligence, right? If you're waiting on compute, there's a bottleneck that needs to be destroyed, because at some point that bottleneck will be so large that some other workflow will emerge to change a lot of that stuff.

And I think, incidentally, we’ve built a really, really awesome product where you can push code, and then you build the code and all those other things, right? But that push-pull-whatever kind of loop, I just fundamentally believe it’s going to go away, right? We’re going to get to a point where you make a small change in production, and that change is versioned across your entire infrastructure.

You’re working alongside copy-on-write versions of your database, all of your infrastructure, and then you merge it in and instantaneously it’s live, right? Because that’s the holy grail of loops. But that push-pull-rebuild thing is a point of friction that we are removing entirely from our loops.

Shawn Wang

Yeah, it’s incredibly fast. So, if anyone hasn’t tried it—

Kurt Mackey

Yes.

Shawn Wang

Yeah. That fast feedback is great. You know, my hot take is that Railway was kind of famous for its canvas, which sort of visualizes your infrastructure and lets you manipulate it visually, but that was for humans.

Kurt Mackey

Yeah.

Shawn Wang

And actually, now for the next phase in growth, the CLI is more important than the canvas, which is what you were famous for.

Kurt Mackey

Yeah. So, I think the canvas is funny because it’s actually just a mechanism to show you changes over time, but I think you’re totally right in the sense that we previously used it a lot as an input, and its goal moving forward is actually a lot more like an output.

What I mean by that is, you would go to the canvas and make some changes and all these other things, right? And you’d see them, and your agents or your infrastructure would evolve over time, right? Now you just have a bunch of agents that have access to the CLI, and they can go and make those changes.

And so the canvas, instead of becoming this input thing where you’re like, “Oh, cool. How do I go in and make this happen?” is actually just more of an output thing. It basically says, “What information—”

Shawn Wang

Yeah. What information does the human need at this point in time to make suitable decisions about control requests? Do I approve this? Do I not approve this, right?

Kurt Mackey

That’s realistically all the canvas becomes at that point. And I think this is important, and I think it’s lost on a lot of people who are building some of these canvas experiences: It has to be almost like an anchor for your context. It has to be like a port in the storm.

You have to think about it basically as layers, and almost like a file system, to get to the next spot, right? You have all your infrastructure, and this is why the canvas starts as just a project, right? And then you have a drill-down chart. It’s like, I’m breaking down into these services or this section that is just a function or code or anything else like that.

You want to actually be able to represent the entire thing not just in your head but in this canvas, so that other people can also get that representation, so that they can think on the same wavelength as you and move as quickly. I think a lot of organizations, especially as they scale, get in trouble because all that context lives in somebody’s head, basically. It’s like, “How does this microservice work?” “I have no idea. Go ask this specific person,” right?

And then you have entire categories and classes of products that are built around how you do context discovery in all these things. I think a lot of that stuff just gets melted in terms of, if you can have a really, really solid hierarchy and you can infinitely nest services, infinitely nest code, infinitely nest context, infinitely nest all these things all the way down, that’s what allows you to build these structures up over time.

I think it’s also what’s going to allow us to build—I’ve written about this—these hyperstructures: things that are way, way bigger. You look at the Golden Gate Bridge and you’re like, “How did we build that?” There’s that whole meme of, “How did we build this? We lost the technology, or we don’t know how anymore,” right?

Well, to some extent, yes, because a lot of the coordination that built those things has evolved and changed, right? We’ve lost almost some of the art of building that structure as we’ve just jammed everything into Slack. Everything happens through Slack, and it’s—

Shawn Wang

But you don’t have anything in Discord.

Kurt Mackey

Yeah, that’s the same point. It doesn’t really matter. It’s just message passing and interrupts. Message passing and interrupts. Message passing and interrupts, right?

Shawn Wang

So you’re arguing that there should be something better, more structured than Slack.

Kurt Mackey

Yeah. Oh, for sure. I think Slack is awful. Incidentally, I think Discord’s awful, too.

Shawn Wang

This is the equivalent of my mom test, right? What have you done to solve this?

Kurt Mackey

So, internally, we’ve built a tool called Central Station that allows us to aggregate all the context from all of our users. Every piece of feedback, every piece of customer support, every single thing like that gets aggregated into what we call clusters.

If you have an incident brewing or anything else like that, now we can determine how many users are affected, all those other things, et cetera. And then we can actually break off a discussion based on that.

I think a lot of that is a lot more helpful and more correct than having these long-running channels where you’re like, “Which channel should I put this thing in?” If you can dynamically aggregate that information and dynamically route it to the right person based on the context, right?

We know internally these 4 people are pretty close on networking, right? And so if we see, “Okay, we’ve got a networking thing,” you can roughly drill it down to those 4 people, right? And if you’re saying, “Oh, okay, cool. It’s actually with this part,” you can just go and look at the commits, right?

This is no longer a manual process internally. This is the whole point of why we built this thing. If you go to station or help.railway.com, the whole reason we built it is because we wanted to figure out how we’re going to scale with a massive, massive, massive amount of leverage to aggregate all this feedback.

Shawn Wang

This is built in-house.

Kurt Mackey

Yeah.

Shawn Wang

Okay. So, and then I remember helping out on this one with Angelo—

Kurt Mackey

In 2023.

Shawn Wang

Yeah. You scaled a lot with a very small team.

Kurt Mackey

Yeah. Yeah. Yeah. So, we’re like 10 times bigger now.

Shawn Wang

Oh my God. You have your full developer account here?

Andrew Farah

Yeah.

Shawn Wang

Okay. All right.

Andrew Farah

Oh, if you go to—

Shawn Wang

I can just clone this.

Andrew Farah

You don’t even have to clone it. We expose this as a pub-subable thing. Go to railway.com/stats.

Shawn Wang

Oh, there you go. Yeah, that’s your—

Andrew Farah

So, it’s all real-time metrics for all of this stuff. There’s a way to get this as JSON somewhere, too, if you care or anything else like that.

Shawn Wang

Look it up.

Andrew Farah

Yeah. We’re big on trying to build everything in public and talk about a lot of the stuff we’re working on. We’ve had some issues in the past, and we’re like, “Hey, cool. Here’s how we’re fixing these things.”

We’ve gotten both compliments and some flak for our incident reports, and we’re always trying to make them better over time just to talk with people.

Shawn Wang

Yeah. Anyhow, you had a big one recently. I like that it was only scoped to 3,000. You presumably used Central Station. Can you talk through what happened, and I guess how do you address it internally as a team?

Andrew Farah

Yeah. Internally, we’ve deemed this one really, really sucked. It was to do with an upstream provider that didn’t exhibit the behavior that they said they were documenting, which is unfortunate given that they wrote the RFC on how the behavior should work.

We rolled those things out, and then Central Station caught that initially. We had a couple of users being like, “Oh, the caches aren’t invalidating for some of this stuff,” right? So, we turned it off immediately, et cetera.

But when you roll out to that large user base of 3 million people, you have a lot of different disparate behaviors that can come up, right? Try as we will, we tested those things in staging. We have tests for them, all this other stuff, and unfortunately we hit an edge case there, right?

We’ve gone and hardened a lot of those systems, and now we can make a lot of that stuff better. But, yeah, it was a tough one, unfortunately.

Shawn Wang

Yeah. I always wonder how the private disclosures are supposed to work if people find an issue. Are they supposed to contact you first? When you run a platform, these things are going to happen. What channels should people pursue to quietly resolve it before it becomes a much bigger incident?

Andrew Farah

Yeah.

Andrew Farah

I think there's responsible disclosure. We kind of err on the side of over-disclosing and knowing that something is wrong versus having your provider almost gaslight you. We've erred on the side of sharing those things more publicly, even if they impact a small subset of users. That's just a decision that we've made internally.

We have 4 values. One of them is honor. What's the honorable thing to do? You notify people to the widest degree at which they may have been affected, if there was an issue or whatever, and then you confront that head-on: Why did that happen? What can we do better in the future? All of those things.

Shawn Wang

Yeah, not the whole user base.

Andrew Farah

No.

Shawn Wang

And that's because of incremental rollouts and—

Andrew Farah

Progressive rollouts and stuff like that, right?

Shawn Wang

Interesting. Yeah, yeah. I feel like that should just be the norm at all large platforms, right?

Andrew Farah

Oh, it totally should. And a variety of companies, it totally is, right? There's a whole quote that Meta runs 10,000 versions—different versions of Meta—in general. To our earlier point about agents, they need the same thing. They need to be able to shadow traffic. We need to build all these other things.

I think we've built so much ceremony around production being sacred, all of these other things, that we need to get to a point where it's trivially easy to test different behaviors in a safe environment. Then you can make those mistakes in an environment that's safe in general.

Shawn Wang

You mentioned somebody brought it up. Do you see a world in which these things get automatically caught, not necessarily by your agent but by your customer agent? You know what I mean? The cache invalidation thing seems like a pretty easy thing to track if you know to look for it.

Andrew Farah

It's hard, because for us to determine it, we'd almost need to hook into your observability infrastructure in general. This is why we almost have the template loop on the platform: to be able to roll those things out progressively. You can say, “Hey, listen, I can roll this out to Johnny Vive Coder initially,” or I can push a shard and you can consume that at your own leisure and say, “Oh, okay, I'm going to update to this specific version.”

You can have this kind of rollout over a period of weeks, where you're pushing a new version and then it goes to 0.1% of people, 1% of people, early adopters, whatever, and then rolls out all the way. That's the kind of nondeterministic version control that we've talked about earlier.

So, yeah, 100%. I do believe that's where most things should go, because ultimately most companies end up building that staged rollout system in-house. It's just the same thing built again and again and again at every single one of these different companies. There's a massive opportunity. You need to consolidate a lot of that for developers.

Shawn Wang

You should have a free tier, like the model providers give you free tokens if you let them use the data. We'll give you free compute if you're the number-one shard that goes out and you let us plug into your observability.

Andrew Farah

Yeah. Incidentally, we do that, right? We talked about the impact of that on 3,000 people or whatever. We start with the lower-impact people, like the larger companies on the platform. They're the last who should ultimately receive those kinds of rollouts, so that they have a version of the platform that's deeply, deeply stable.

Shawn Wang

I have 3 services, so I'm sure I get the first rollout. You can nuke my thing at any time, man. I guess my other question is, there are all these AI agent companies, and the observability people also want to have agents that fix your upstream problems. How do you see that playing out? You have your own agent in the Canvas now that you can try with. How do you see that playing out?

Andrew Farah

It's almost like the stacking-entropy thing in general, right? I think if you don't have the primitives to make iterating in production safe, it becomes very, very difficult. If you're an observability provider and you're like, “Oh, here's this fix to this error,” assume that 80% of those are probably actually good. They're going to make sense, et cetera.

But then the last 20% of that long tail of complex issues—ultimately, if you roll those changes out and just let somebody say, “Oh, cool, this looks good,” and stamp it, there's an opportunity for you to have an issue or an incident or anything else like that. I think that's why it's really, really important to have those kinds of forked environments in general.

People have staging, et cetera, but it always ends up deviating from production. You need the primitives, workflows, and experience built in as a first-party thing on the platform, in our mind, so you can fork any service at any point in time.

I consider the Canvas almost like a little sheet of transparency paper, and the agent is this little guy that you push up. It should be able to pop up in the Canvas and say, “Cool, I need to copy that service. I need to copy that service so I can test these 2 things.” That's my hypothesis as an agent.

Ideally, I get a read-only copy of production. Anything that's PII is marked as a transform when we automatically clone that database, go for a copy-on-write version of it, or read from it. Then it just makes those changes and says, “Does this actually work?” as close to production as possible. Ultimately, that's how close you have to be, or you just have a massive amount of drift.

I've changed this thing, and then it gets out of sorts. The system gets a lot more unstable. That's what you see with a lot of these massive systems that companies built on top of Docker for local, Kubernetes for production, and this specific thing for whatever. All of that complexity ends up getting to a point where it slows down the developers, but it also gets so unstable at scale that it becomes hard for people to iterate and make those changes.

We want to compress a lot of that stuff way down and just say, “As close to production as you could possibly be.” That's where we want to be.

Shawn Wang

I was texting Erica for questions, and she says you were originally not a believer in AI SRE.

Andrew Farah

Oh, yeah. Yeah. I mean, I've kind of—

Shawn Wang

Have you come around on it?

Andrew Farah

Yeah, well, I flipped. I'm actually still not a believer in AI SRE, because I believe that you need the primitives to make those things safe. If you just unleash an AI SRE on your production infrastructure and you don't have safe primitives for copying volumes and making sure that everything is fine, it's going to nuke your production database.

It's not a matter of if; it's a matter of when it's going to nuke that database, right? I'm a big believer in making those kinds of loops safe in general. I think I was a pretty deep—almost, I don't want to say—AI skeptic until 2024. Then I was like, “Okay, maybe I can make this thing roughly do it.” In 2025, I was like, “Okay, now I can trust this.”

Over the whole winter break, everybody came back and was like, “Oh, my God, it's almost impossible to use it wrong.”

Shawn Wang

Seriously? On the Claude docs?

Andrew Farah

But it's gotten to a point where it's almost harder to use it wrong than it is to use it right. There's that scene in Avengers or whatever where Vision says, “It's terribly well balanced,” when he picks up Thor's hammer. This thing just self-balances and works quite well from that perspective.

So, yeah, I'm a deep believer at this point that this will be the dominant species, right? Again, you know, Assembly, C, C++, JavaScript—words, right?

Shawn Wang

Yeah, it feels like a big jump.

Andrew Farah

Yeah, it feels like a big jump, and it is, too. It's not like you abandon CPU-based discrete logic in general and move straight to fuzzy logic. You need both, right?

Your skills should call code or applications or whatever, some sort of static structure, and you can use the skills to distill what the procedure should be or how the code should act. I'm coming to this thesis that you need 3 points, essentially: a clear spec of what defines the system, the code, and the tests.

When you say this thesis out loud, if you've been in engineering for any amount of time, you're like, “Well, no. Of course. That's an RFC, those are tests, and that's your code.” But they all matter a lot, and having them all actually together means they can reinforce each other.

The spec and the tests match, but the code doesn't. Let me reconcile them. Now the tests and the spec match; let me reconcile this other thing. You can move through that period of basically saying, “Well, this is fuzzy, and these 2 are either discrete in the case of tests or slightly fuzzy, slightly discrete in the case of code.” That's your iteration loop.

Jake Cooper

I think that’s also, incidentally, why you’re seeing a lot of people talk about software factories: “I want to write this doc, and how do I reconcile all this other stuff?” I think that’s a bit of architectural astronomy, if you don’t actually go in and implement it. But I do think that, generally, this loop is where most things are ultimately going to end up.

swyx

Yeah. For listeners, we’ve been talking about this on the podcast for 3 years: the holy trinity of specs and tests. Adamar Freeman from Kodo is the reference if people want to look it up.

One thing I do want to mention, just on the OpenClaw thing, is the idea that you can self-modify, which is kind of interesting. I don’t know how exactly Railway would support it, but I do have my OpenClaw, and I just tell it that it has the Railway CLI. You can do whatever. In theory, whatever capabilities or new infrastructure you need, you can just call the Railway CLI, provision it, and add it to itself. So the agent can modify its own infrastructure, which I think is—

Yeah, it’s nuts. We have a loop that I’ve kind of set up, which is: you put the Railway CLI on top of something that runs on top of Railway, right? So you’re essentially authenticated as whatever the current box is, in general, and you can make any sort of changes to it. Then you just call Railway deploy, and it deploys itself.

swyx

Right. It’s just like, “Oh, cool. I need to go and spin up this instance of this environment. I already exist in this environment. Excellent, I’ve got access to a PostgreSQL instance now.”

This is kind of where we want to go with a lot of the agentic, almost self-replicating infrastructure. That’s your loop: you iterate in production. That’s your loop, right? You’re going to continue to make some sort of change, and either it will work and you’re going to want to merge it and say, “Cool, that’s great. Put it into our upstream,” or it will not work and you can just throw it away, et cetera, right?

How do you make those throwaway copies as trivial as possible to spin up and run super cheap? I think the era of “I have an AWS instance and I’m going to get 4 vCPU and 16 GB of RAM” is going to get completely destroyed, right? Because if you do that for agents or anything else like that, you now need 1,000 of those machines. It’s so prohibitively expensive.

We spent a ton of time trying to figure out how to make these deploys—whatever you want to call them. Cloudflare has isolates; everybody calls it a sandbox, whatever—that atomic unit of deploy: only pay for what you use, spin up instantaneously, and close the loop as quickly as possible, right?

Because if the system can self-replicate and it can do so safely, it can say, “This is my environment. I’m making these changes,” et cetera. It can come back with, “Hey, does this look good? This is a new state of infrastructure given this prompt. I think I’ve solved this problem.” Then you can go back to the agent and it actually looks a little bit different.

swyx

It goes and does the loop again, and you’re like, “Cool, excellent, apply.” Yeah. I think that’s retroactively obvious—kind of the most useful kind. I don’t know if you have any other comments on agent deployment on Railway.

No, I mean, it’s getting better every day. I’m on X, or Twitter, or whatever you want to call it, and you can always yell at me about the experience not working as well as it should, because there are plenty of things that should work way, way better.

swyx

I was going to say, I think at this stage, when people want massively or embarrassingly parallel compute, they usually talk about serverless, and I feel like there’s no new serverless that has emerged compared to the previous 5 years of serverless. You’re kind of in that new bucket. I don’t know if you have comparisons or philosophical differences that you want to call out.

No, I think, as you mentioned, it’s somewhere in between, right? It’s the ability to run stateful, long-running—you want to call them workflows, executions, whatever.

swyx

Vercel has Fluid Compute, and then Cloudflare has some container thing. Google has always had App Runner.

App Runner and the new one. Yeah, I forget a bunch of them.

I think that’s kind of where everything roughly is, and this is why we’ve been working on it for the last 6 years. We just believe you need access to a computer—you need a box that speaks Linux—so that you can deploy the things that you want to deploy on it. Other things are going to change the surface area of what you can build, but for us, we’re always like, “No, users need a computer, and they need to be able to deploy anything that they truly want.”

That’s why we focused for a long time on those primitives: network, compute, and storage. If we can give you those things, expose them to you, and allow you to run these things indefinitely, that’s where we believe it’s going to go in general.

You’re seeing right now, again, the whole Twitter-has-no-nuance thing: it’s servers, it’s serverless. It’s like, no, it’s always somewhere in the middle. You want to run it for a long time, but you don’t want to provision this resource statically or pay for things that you’re not using. That’s always been our thesis from day 1: pay only for what you use, run it indefinitely. It’s just full Linux, basically.

swyx

Yeah. I think that’s why I like the Vercel naming of Fluid, because it’s fluid and flexible. Another milestone—and then I wanted to ask one more technical question—is Heroku’s official deprecation. You are one of the presumptive new Herokus. “New Heroku” has been a category for as long as I’ve been in developer tooling.

It’s finally happening. What was that like? Is there any behind-the-scenes insight into why Salesforce let Heroku just stagnate?

Yeah. I mean, you just have so many people who are like, “You were running stuff on Heroku?” You as this company—it’s crazy that whatever name you would know is running this thing, and then you’re coming to us saying, “Yeah, we kind of want to move a lot of this stuff off,” or whatever. Okay, cool. But it’s kind of nuts.

swyx

Any behind-the-scenes insight into why Salesforce let Heroku stagnate?

Well, I mean, I can only guess. I think it’s just hard when it’s not your business. The business of Salesforce is to build a really, really good CRM, right? That’s their focus. They should be really, really focused on building a really, really great CRM.

Then you acquire this business as a compute business that’s kind of an offshoot of your business in general, right? I think a lot of the early Meta folks have talked a lot about focus. Boz has a whole write-up that he’s done, basically, where he talks about how, in the early days of Meta, they had no money and were forced to get focused.

Then they turned on the money tree. This is me paraphrasing or whatever. They turned on the money tree, and then they had no reason not to have focus because they just had infinite money, where they could split all of their focus, right? But that ends up diluting your product. It ends up making these offshoots where you’re just like, “Is that the focus of the business?” And it ultimately ends up not being if it’s not the core of your business, right?

So, to me, it’s kind of no wonder that it languished in general, because it just wasn’t the core focus of the business. I think a lot of companies get in trouble with this when they split out their focus in general, because it means that you’re almost fighting a multi-fronted war, trying to compete with all these things—not just compete with them externally, but compete with them internally for alignment: Where are we going? What are we doing? What is our purpose here?

If you’re really, really Salesforce-built, and you’re like, “Hey, listen, I love Salesforce. I really want to work on all those things,” and you’re mission-driven—which is the aspiration for a company in general, of why people work on things, right?—it’s like they want to work on something interesting. Heroku is off to the side. It’s not the core of the business.

To get those resources—budget, focus, alignment, or whatever—internally, it’s just pushed away. So it was literally just a matter of time for it to happen, in our mind.

swyx

Right. Yeah, I think kudos to them for actually calling it out instead of just letting it be unknown.

Yeah. Well, their whole release was a little bit odd because they kind of called it out as “Our Incredible Journey.”

swyx

Yeah.

Jake Cooper

They didn’t say they were shutting it down, but they were like, “Yeah.”

swyx

Yeah. Yeah.

Jake Cooper

So, yeah. Behind the scenes, I think they issued some stuff to people, being like, “Hey, yeah, you should close these accounts down. We are going to go in and deprecate this and remove it every time.”

It’s crazy because some of my first deployment experiences were on Heroku. It’s a foundational thing where—

swyx

I had a freaking alias in my bash for Heroku deployments.

Yeah, right. You start with dragging stuff into an FTP server, and then you move on to trying to get a deploy working: “How do I go and make this happen?” And it’s Heroku, right?

Shawn Wang

Did you know about Heroku hacks?

Jake Gollub

Yeah, exactly. You learn about all this, and it was the on-ramp for us. The wheel turns regardless. There’s new stuff emerging, and we’re very happy to continue to carry the torch for a lot of that stuff.

But we don’t want to be the new Heroku. We want to be the way in which people are building and deploying software, and ultimately the way that people monetize software over time.

Shawn Wang

I mean, it’s a big crown to be a new Heroku. There are like 50 companies that fought for this.

Jake Gollub

Oh, yeah. Everybody’s kind of holding some portion of this, being like, “Ah.” But for us, we’re just happy to support people and companies. The platform works a bit differently, so it’s obviously almost the same kind of game loop.

We’ve been quite dogmatic in terms of where we believe these things are going to go: the primitives, the agents fanning out into all of those other things. Some things will fit, and for some things, you have to change a few of the workloads. We don’t have—what’s that feature that people really love?

Shawn Wang

Pipelines.

Jake Gollub

Heroku.

Shawn Wang

Yeah, right.

Jake Gollub

We have some approximation of it with the environment system in general. So, yeah, it’s been super exciting. We’ve got a ton of people that we’re able to support, and it’s growing a lot.

Shawn Wang

Yeah. Any other technical infrastructure? I have one more beef: Temporal. Okay, so Temporal—I have sold my shares.

Jake Gollub

You’re a power user. You’re one of our earliest customers. I think I met you through Temporal or something. You’re a big Temporal user; you build on Temporal and have complaints. I think this is the most neutral, most informed conversation that anyone will ever hear about Temporal without someone working at the company.

Shawn Wang

Yeah, that’s fair. It’s the two of us.

Jake Gollub

Yeah, yeah. No, I think that’s fair.

I have used Temporal for almost 10 years now, because of Cadence and all those other things.

Shawn Wang

Just give people a sense of what Cadence is at Uber. People don’t know.

Jake Gollub

Cadence was the precursor to Temporal, and it powers all of the trip actions: the rides, when you rent a JUMP bike or scooter, or a car. Anything like that—you’re running these workflows for a period of time and basically saying, “This ride will run for an indefinite period until it finishes,” right?

You can attach information, whether it’s, “Oh, you paused it in this zone, so you need to add this dollar charge to the bill,” or anything else like that. Then, when you end the trip, your workflow is done. That whole experience behind the scenes—I don’t know about today, in general, but it was powered by Cadence at that point in time.

Shawn Wang

I used to say it’s like, imagine if you could program the entire user journey top-down as one function.

Jake Gollub

Yeah, right.

Shawn Wang

Yeah. Yeah.

Jake Gollub

It’s such a powerful idea, and it’s so important. It’s also incidentally so important for the next phase of the agentic journey, where you want an agent to do a specific task, and then you want it to be complete or incomplete on that task and move on to the next thing, right? You need a way to manage these workflows dynamically.

For me, Temporal was always really, really great in theory, and it was really, really great when you got it working the way that you wanted to in production. It’s just that it required you to model that entire journey in your head. If you didn’t have the entire journey in your head, you could put yourself in a spot where you caused issues, where replaying the state of the entire workflow caused a nondeterminism issue.

Shawn Wang

Because it works on deterministic workflow history.

Jake Gollub

Yeah, exactly. The way that I would describe it is: it’s a jet engine, right? If you know how to operate it, if you know how to run it, all of those other things, it works really well. But you can’t hand it to people who are trying to build things that end up being complicated but don’t have that whole state in their head.

For example, we run our whole deployment pipeline on top of it. That’s a reasonably complicated workflow. There are pre-commit hooks, signaling, queuing, and all of this other stuff in general.

As you try to express this large workflow, as you mentioned, going all the way down gets more and more complicated. There are more and more states in the state machine that you have to map back to the right thing.

Shawn Wang

Yeah, exactly.

Jake Gollub

At Uber, we built a system for doing the state machine and testing the state machine and all that other stuff. We’ve started to build some of those things here because it’s grown quite heavily.

It’s not exactly a love-hate relationship, because that’s too broad. When it works really, really well, it works super, super well. But then you run into a situation where somebody who hasn’t interacted with the system or doesn’t have the full context goes and puts something in the system that invalidates some of the state, causes a nondeterminism issue, spins off a ton of activities, or anything else like that.

Then you have to keep track of all these underlying knobs, like, “Oh, we have the number of activity slots in this thing.” These should just scale with memory, vCPU, and all of those other things in general. It ends up becoming a bit of a bear to scale out.

Shawn Wang

Yeah, so you need a very capable sysadmin running things behind the scenes for you.

Jake Gollub

Yeah, yeah.

Shawn Wang

If you were to move off, what would you do?

Jake Gollub

I think we would build our own workflow system. We have a few internally that we’ve worked on.

Shawn Wang

This is one of those things where you typically wouldn’t vibe-code it, but I’m wondering if—

Jake Gollub

Well, I don’t think you should vibe-code it still. You still want to run type tests and stuff like that to make sure that you—

Shawn Wang

I mean, you know, it’s not like Temporal had to invent that from scratch either, right? There are libraries for those things.

Jake Gollub

Yeah, that you can run. On top of that, it’s just a state machine that you really have to map out. Ultimately, you define the abstractions that you want, run it through a state machine, and that’s it.

Shawn Wang

Yeah, it’s very doable.

Jake Gollub

So, yeah, I think the workflow stuff is very interesting. There are a few really cool companies; I think Restate is doing some neat stuff here.

Shawn Wang

So you’re very tied into JavaScript. You’re like a JavaScript maxi?

Jake Gollub

Internally, we have TypeScript, Rust, and Go. Those are the 3 languages, right? We don’t add any more stuff. Actually, that’s not true. We have a little bit of C because we write eBPF code and its hooks and stuff like that.

But those are the languages we use. We use TypeScript a lot because it powers the dashboard, but we’re going to move a lot of the workflow stuff off of the dashboard stack and into the infrastructure stack.

Shawn Wang

Yeah. Don’t power things on the front end, guys, even though it’s free compute.

Jake Gollub

Yep.

Shawn Wang

Yeah. Yeah. Cool. Any other technical infrastructure cool stuff? Railpack. I don’t know if that’s still—

Jake Gollub

Yeah.

Jake Gollub

Yeah, we built that engine for determining dependencies based on your source code, which is super cool. It’s called Railpack. We built the first version, called Nixpacks, on top of Nix, and then we moved on.

Shawn Wang

People have been trying to get me to adopt Nix and NixOS for 4 years.

Jake Gollub

Yeah.

Shawn Wang

Is it ever going to be a thing?

Jake Gollub

I don’t know. We were super excited about it in general, but it has a bunch of pain points. If you think of it, it’s a stack of versioned binaries at specific slices in time, right? If you want version X and version Y, you end up bloating a lot of your package space, which blows up the size of your images and makes it really difficult for real-world workloads.

Shawn Wang

But you content-address it and cache it. There are a lot of optimizations that, in theory, you should be able to do.

Jake Gollub

In theory, yes. What happens ultimately is that you have a large enough user base and a disparate enough set of machines that you run into the problem described in a paper that Meta released, XFAAS, its internal serverless system. It becomes very difficult to do that at scale unless you break out specific runtimes, which we did not want to do because we wanted to truly allow you to deploy anything.

That was our initial thing with Nix, but we’ve moved toward some interesting stuff that I think we’ll be able to talk about a little later. We’ve built content-addressable file systems that can lazy-load anything from any point and then just page that into memory.

Shawn Wang

Amazing. Okay. Yeah, it’s going to be fun. The whole future is very bright. It’s crazy. It’s going to be nuts. Okay, founder journey stuff.

Alessio Fanelli

Yeah. And your cloud usage—you tweeted you’re going to spend $300K this month.

Jake Gollub

I think we got 2 coding agents across the company.

Alessio Fanelli

You only have 35 people, so I’m sure they’re not all spending $10K a month. What’s the distribution?

Jake Gollub

I think I’m at about $25K in general, and then we have some power users all the way down. We came back from winter break, and I was basically like, “If you are writing code by hand, you are doing this wrong,” right? The tools are good enough at this point that you can move extremely quickly.

Yes, there are issues and pain points and all these other things, but you should be reviewing the code that you’re writing instead of trying to write it by hand. All of those architectural patterns and all of those other things matter more now than at any other time. But you shouldn’t spend your time generating code that you would write.

If you know how to write it, just ask the agent to write it and then reconcile it until it looks like you would have written it yourself, right? Incidentally, people misconstrue my propensity to push people toward agents as, “Hey, we’re growing really fast and we’ve had some bumps in reliability.” They’re not necessarily related.

Jake Cooper

But I think people should really understand that the tools are good enough for you to move extremely quickly and build things way larger than you could have possibly built before. To our point way earlier about how you cool data centers in space, it’s like, well, I don’t know, actually, right?

But you’re at a point now with software where you can be like, “How would I build block storage from scratch? How would I go in and do these things?” I have ideas because I’ve got history. I’ve read all these papers in general. Let me work them out, and let me build massive test benches with thousands of tests, because they’re free to author right now, to make sure that this system can be built.

I think that if you’re not using these AI systems to almost speedrun your roadmap—to figure out where you need to be and reconcile your existing system onto the future—then you’re missing a large part of what’s happening right now. You can just template out anything and validate it on the side for free, right?

Alessio Fanelli

What’s the path to spending $3M a month? Is it bound by ideas and things that customers can absorb?

Jake Cooper

For most companies, I think it’s actually bound by deployment at this point in time. That’s why we’ve seen a massive boom in companies—from Fortune 50s and below—trying to figure out how to get their developers to move quicker.

You’re probably going to hit your CFO before you hit any of these limits, because they’re going to look at this and be like, “There’s an eye-watering amount of money being spent on these tokens.” I think—I don’t know which one—I think it was Uber’s Claude token budget for the entire year or whatever.

Inference costs have to come down, but we’re also inference-constrained at this point in time. You’re going to almost get this price discovery of what makes sense for an organization to adopt. I think what you’re going to end up with is almost the F1 driver concept.

If you have somebody who’s really adept at these things, it makes sense to put them into a $3M car or whatever, right? But if you’re not, then it probably doesn’t make sense for you to do that. We’re going to take a few of these people and say, “You drive the F1 car. We need to go in this general direction. Figure out if this works,” and almost prototype it.

We’ve done a few of those things where we’ve vastly accelerated our roadmap. We thought we were going to be able to ship something in the next few years, but actually we can probably ship it in the next few months now. We validated it, it works, and we don’t even have to build it incrementally. We can skip steps and just move toward where our vision is for a lot of this stuff.

Alessio Fanelli

Yeah, I think a lot of people are realizing the roadmap doesn’t always have a business impact. It’s like, “Oh, it’s too expensive to run these tokens,” but if your roadmap was actually built to make more money, by the time you built the whole thing, you would have some sort of token pricing for it.

It’s the same way you do with sales. You would spend $1B in sales if you knew you would get $2B of revenue out of it.

Jake Cooper

Exactly. The really naive way to measure this is almost your percentage of tokens that end up in production, right? If you can measure that you’re getting this level of impact because those tokens are ending up in production, that’s awesome.

But I think the burden of proof is now going to arise. You see it internally on our stuff, too. We have a growing number of pull requests that haven’t yet been merged, and you’re just like, “Okay, how do you get this into production?”

It’s really about how quickly you can build and deploy that software, which is exciting because we build and deploy software. The SDLC is changing, and it’s something that both of us are super interested in exploring as well.

Shawn Wang

One of my theses—or it’s not my thesis; it’s that the pull request is dying.

Jake Cooper

Right. It’s going to be the prompt request.

Shawn Wang

And beyond that, code review is also kind of dying, because do you really need it if you have all the other systems in place? What else is changing about the SDLC?

What else is different? Well, I think the AI SRE is one of those things where it’s a pie-in-the-sky aspiration. What does it take to get an AI SRE?

By the way, you should expose your tooling to your customers at some point, right?

Jake Cooper

Yeah. Which tooling?

Shawn Wang

The central command center.

Jake Cooper

Oh, Central Station. We have it for template maintainers, so template maintainers can deploy and maintain templates, and they get feedback on a lot of that stuff. We’re 100% going to expose those things incrementally.

Shawn Wang

Yeah, but clustering around incidents—everyone has a version of that, but I don’t think anyone has solved it.

Jake Cooper

Yeah. Right. I don’t want to say we’ve solved it internally, but it’s gotten so good that now we can see those incidents forming pretty quickly.

Shawn Wang

Yeah. Real time.

Jake Cooper

Yeah. So at some point, those will be things that either somebody else goes and builds or we go in and build. But we've always built stuff that was purpose-built for us, and if it made sense and there was a way to make it useful for users or monetize it, or make sure that that loop becomes a profit center instead of a cost center, we want to do that at some point, right? So, yeah, SaaS is definitely dying.

Shawn Wang

Do you do first-party feature flagging and incremental rollout-type stuff as well?

Jake Cooper

So we have a feature-flagging engine that we built internally that, at some point, we will roll—

Shawn Wang

Because I don't see it as a user.

Jake Cooper

Yeah. Yeah. Yeah.

Shawn Wang

So, like, that would be—that's good, right? How come you didn't give us what you have?

Jake Cooper

Well, because we have to beta-test it. We actually care a lot, a lot, a lot about the quality of the things. There's plenty of stuff that we've used internally and then gotten to a point where it doesn't make its way entirely through the journey because it fails, right? It holds for one service, but it doesn't hold for multiple services, right?

We'd have to build these things for multiple services to make this work, right? And we know for a fact that if we release this thing, we'd have to rebuild it again and again and again. Some things are worth doing that for, but a lot of them are basic like that. That also kind of informs our roadmap: for us to make that actually a bit easier, we can do a few of these things first, and then we get to that experience, right?

We don't want to dilute the experience by basically saying, “Oh, yeah, this works, but only for this service,” right? Unless it's a very, very core initiative, which is, “Over the next few months, we're going to roll out a few things where it works for a single service, then it works for multiple services, and then it works for multiple services across the environment.” But you have to be very, very deliberate about those things. Otherwise, you end up with a bunch of broken, disparate experiences, which ultimately create a ton of support load because people are like, “How do I use this feature? How do I go in and do this other stuff?”

It's kind of the thing we talked about earlier: you expand your company in general to get those features, and then you almost compact it and smooth out those things so the experience is really, really stellar. We were talking in the hallway earlier, where you're like, “Oh my God, it's gotten so much better,” and I'm like, “Oh man, internally, we're like, ‘Damn, this part really sucks. We have to make this significantly, significantly better.’”

Shawn Wang

No, I can attest. Over the last 3 years that I've watched you build Railway, the importance of feature flagging is a very big part of Uber culture. So much so that they have too many feature flags, and then they have another thing to remove feature flags.

Jake Cooper

Yep. 100%.

Shawn Wang

What was it? There's a paper about this.

Jake Cooper

Flipr. And there's been another one.

Shawn Wang

Facebook has Gatekeeper. Yeah, so they're really important.

Jake Cooper

And agents are going to need this. That's the fundamental thing behind incremental rollouts.

Shawn Wang

OpenAI acquired Statsig. Yep. And basically, GPT-5 is just routing and flagging through different models.

Jake Cooper

And it's super important, right? Because if you assume the software development life cycle is 100% going to change, it's going to change because we're trying to do things 1,000 times faster and 1,000 times more concurrently than we currently do them, right? And so, routing.

Shawn Wang

Yeah. Right.

Jake Cooper

What ends up becoming important at scale? Before I even started Railway, I actually built a feature-flagging product and tried to sell it to people, right? I was like, “Oh, it's an easier version of LaunchDarkly or whatever,” right?

I ran into this situation where anybody who's small enough to adopt your technology doesn't care about feature flags, right? And anybody who's large enough to actually need feature flags needs so much scale that you have to build out all the existing infrastructure. So I ended up scrapping that.

But what is old is new again, because now companies are trying to move really, really quickly. You can't just YOLO this vibecoded thing straight into production. You need to say, “Hey, here's my blast radius. Here's my impact. Here's my whatever. I want to shadow it for these users,” right? Feature flags, right?

You're going to need those tools that ultimately those larger companies ended up having to build to maintain their structures. Everything's just going to get compressed by 1,000× so that everybody can do that and everybody can build those structures really, really quickly, right? That's exactly where we're at right now: you're compressing the software development life cycle, and then we're going to expand it and add way more new things to it.

Shawn Wang

Yeah. The other term that comes to mind when this kind of discussion happens, for newer developers who haven't heard it, is “cattle, not pets.” Your prod has a name like a baby; you have to keep it alive. But when it's cattle, you can just mass-farm, roll out, portion out parts of them, and kill them or whatever.

Jake Cooper

Yeah. Exactly. I actually think that maybe that's the hot take, but I think that's actually going to change. I think you can move toward having pets so long as you have a—and this is going to be a jump—so long as you have a cloning machine for your pets.

Shawn Wang

Uh-huh. Yeah. Yeah. If you can snapshot every single thing at every frame, then it actually doesn't matter if it got obliterated because you have some sort of snapshot of it, right?

Jake Cooper

All of the things that we've built right now are essentially to block out any sort of changes or alterations or whatever from that hermetically sealed DevOps pipeline. It's like, “Okay, well, you have to write a Dockerfile because I only need this specific instance—only this specific cut of the file system, et cetera,” right? What if you just had the whole file system? What if you just snapshot it and lazily load the entirety of the file system? Then you can get around this problem entirely.

You don't need the ceremony of having a Dockerfile or an Ansible script or all of these other things. You can just iterate on that loop and then snapshot it. Is this the right loop? Is this the right thing at this point in time? Okay, cool. Now I'm going to merge it into production—go merge the file system.

Shawn Wang

Yeah, why not?

Jake Cooper

It's going to be really fun.

Shawn Wang

Yeah, this is a whole other can of worms, but I think the number of things that are stateful in a VM—I think if you just catalog them and develop dedicated solutions for solving each of them, you can cut this problem down a lot. It's surprising that people weren't really trying until now.

Jake Cooper

Yeah. Well, it's surprising. It's always been surprising to me because these are the things that we work on. I'm like, it's so obvious.

Shawn Wang

First principles: you need them. Everyone, in theory, needs them. And then the big clouds don't do them, so you're like, “It's impossible or something.” I don't know.

Jake Cooper

Yeah. Exactly. You're like, “Oh, well, they—you know, Meta has all the people who write eBPF code, and they're doing something with them.” But you need that kind of stuff to solve these problems, right?

And like we talked about earlier, whatever is required, however deep we have to go to solve those problems—all the way down to the kernel TCP/IP stack—we're going to figure that out. Is there something that we need to modify to make that work for the mental model that we have for the universe moving forward? Yeah, 100% we're going to do it. We'll just keep going.

Shawn Wang

Sounds fun.

Jake Cooper

It's super fun. It's so much fun. I have to literally peel myself away from the fun, interesting problems that we have to make sure that we can scale the company in a way that works.

There are so many different fun, interesting problems, whether it's how you get the information from the customer to support to the person who built the thing internally, right? Or it's like, how do you get iteration, or how do you get context from the dashboard to users, or how do you drill down all the way to the infrastructure layer? How do you manage orchestration as a real-time operating system versus a feedback control system, right? It's just so fun, you know?

Shawn Wang

Yeah. I mean, speaking of that, maybe talk about the founder side. You're famously, like, the YC/SF consensus is: you go to YC, you get a co-founder, you do all these things. You've done none of that.

Jake Cooper

No, I’ve done a lot of different things in general, right?

Shawn Wang

In the elevator, you were like, “Actually, co-founder—it kind of makes sense if one person is the tech person and the other is the bizdev person.” Yep. But you have to contain all those multitudes yourself. How do you do it?

Jake Cooper

Okay, I was going to ask: is there a question in there or what?

Shawn Wang

Yeah. The question is, what the hell—how do you do it? The question is, how are you alive right now?

Jake Cooper

Yeah. Well, just try to get 8 hours of sleep.

Shawn Wang

Is there a balance that you ideally like—50/50, 30/70? What’s the mental model that you use as a balance?

Jake Cooper

You just have to think about all these things and be obsessed with all of them, whether it’s being obsessed with how people think about your product from a go-to-market perspective, or being obsessed with, “Well, if I can make this change at the kernel level, then I can make it so that the user’s SSH connection never drops.” That’s what I want. I want a universe in which I can snapshot all these things and it looks exactly like you would just iterate on a VM, right?

I think you just have to be obsessed with all those things at every layer of the stack. I think that’s what makes it easier for me.

I think some people are obsessed with different portions of the journey, the company, whatever, right? And I think that’s when you can get really, really good cohesion by segmenting out these things. In the elevator, I was talking about how you have a technical person, et cetera, and then you have the customer person in general.

I think if you can segment those lines out really, really well and be very, very clear about what your areas of ownership are for yourself, your company, or just where you’re going to operate, you’re going to have a good time. If you can’t be clear about those things, this is why I was saying 2 is the worst number of co-founders: you have no tiebreaker. You basically are like, “Well, I disagree on this thing, and I disagree on this thing.” How do you resolve that?

Shawn Wang

Well, you say someone’s CEO, right?

Jake Cooper

Right, exactly. Then you’re like, “Okay, you have the tiebreaker.”

Yeah, totally. I mean, listen, it’s hard. It’s hard every single way you cut it, right? It’s hard if you get help. It’s hard if you do it yourself. It’s just hard to run things, roughly speaking, right? But it’s so rewarding. It’s so fun.

Shawn Wang

What have you found useful? A coach? Any advice that has been really helpful?

Jake Cooper

I like to write a lot. I get in trouble a lot for my Twitter. I think there’s a pattern.

Shawn Wang

Who do you get in trouble with?

Jake Cooper

The people on Twitter, you know.

I was talking about it and I was like, “Hey, if you’re working weekends, you’re kind of messing up your planning,” roughly speaking. I’ve gone kind of back and forth on that, right? I think actually right now we’re at an exigent time in general where it makes sense to work more, because the goals are pretty clear in my mind.

If you have the vision and you know where you’re going, you should work a little bit harder to distill that vision and go do those things. But if you’re like, “I think we should be going on this journey, but I’m not 100% certain and I want to get a little bit of clarity,” what you need to do is disconnect and take your weekends very, very seriously.

You need to write about where you are, what you want to do, where you want to go, what problems you’re trying to solve, and think about a lot of these things. Writing is important. Sitting down—I don’t like the word “meditation” or whatever—but whatever gets you into the state of mental clarity, that’s the thing that’s really, really important when you’re trying to go on these journeys of saying, “We’re here, and we really need to be here,” in general, or, “We’re here, and I think we need to be roughly in this kind of space for this to work.”

Disconnect, hang out with the people you love, and work super, super hard when you’re working. I try and work from sunup to sundown Monday to Friday, all out, in general. Then I try and disconnect on Saturday, and I come back to work on Sunday afternoon. I do my writing plan for the week, all those other things, and it works really, really well for me.

Another hot take is that most advice is to be digested and thrown out the window. If it’s helpful, it’ll come back. If it’s helpful, you’ll have learned it over time through experience or anything else like that.

You mentioned the standard YC advice and all of those other things. We’ve made failure as a society very, very expensive, and it makes it difficult for people to trod off the paths.

Shawn Wang

Yeah, makes sense. Any other hot takes you want to get on—anything that you haven’t tweeted and gotten in trouble with that you want to preview to the world?

Jake Cooper

No. I think the agent stuff is crazy. It’s going to be the dominant way in which people are doing pretty much everything, provided we, of course, get the amount of inference required for that to happen.

Over the next 10 years, you just see a fundamental shift in terms of how people are thinking about even just authoring the logic that’s in their head.

Shawn Wang

Yeah. Maybe one way of phrasing this is: if all birds can become a GPU provider, so can Railway.

Jake Cooper

Yeah. I think there’s a lot of horror in us actually not becoming a GPU provider. I think you’re defined almost more by the things that you don’t do than the things that you do, because it’s really, really easy for you to just say yes to a bunch of different things.

I think it’s going to be very, very interesting to watch. Anthropic is an amazing company—super, super stellar—and they’re moving into a variety of different zones. They’re moving into the Figma kind of stuff that they’re after, right?

Shawn Wang

Yeah. Bret Taylor was on Figma’s board, and then they removed him on Monday, and then they launched this today.

Jake Cooper

Yeah. Things move very, very fast right now. It’s just going to be the way in which people are—

Shawn Wang

Okay, so your answer is focus. No GPUs for now.

Jake Cooper

Yeah. Focus. Never say never.

Shawn Wang

Yeah, right.

Jake Cooper

I can tell you for a fact that we will not be doing GPUs now, but we 100% will be doing GPUs at some point in the future. That’s not me leaking our roadmap, because we don’t have plans to go and do GPUs. It’s just a function of the fact that, at some point, you need FLOPs.

At some point, if you’re fully vertically integrated and you want to make it really, really trivial for people to go and iterate, build, and deploy things, you need access to this core piece of fundamental logic.

Shawn Wang

At some point, presumably, your own data center traffic is a minority of your workload right now, but is there a majority, or do you just completely turn it off?

Avi Press

Oh, at some point we got to 100% data center—our own data centers. It’s right now the vast majority of the stuff that exists on our bare-metal data centers, right?

Shawn Wang

So you’re already there—vast majority?

Avi Press

Yeah. I didn’t know the extent of the transition. It was completed at some point, and then we grew so fast that we had to basically scale back on that.

Shawn Wang

Take us back—sorry, Google Cloud.

Avi Press

Yeah, it was funny. We got to—on the Datadog dashboard, it got to 100%, and then it dipped back down into the 90s or whatever because we were—

Shawn Wang

Adding capacity.

Avi Press

Yeah.

Shawn Wang

Yeah. It’s interesting. You’re literally building a new cloud, and that’s independent. People assume that could never happen post-AWS.

Avi Press

Yeah, and it’s hard, right? We’re going to figure out a bunch of different things to make sure that the platform is deeply, deeply reliable. You have to break ground on a lot of new things when you decide you’re going to build a cloud from scratch but not copy the hyperscalers.

We’ve been very, very deliberate to invent our own infrastructure from scratch, based on reading a ton of papers in general, but almost promising to ourselves that we wouldn’t copy somebody else’s homework. We were saying, “Hey, listen, if we copy somebody else, we lose. You’re just going to become them over time.”

You have to have a core thesis about why this business needs to exist at this point in time. For us, it’s always been about the activation energy to get something deployed in production at any of the hyperscalers. As of right now, it’s far too high, and we believe that it should be instantaneous.

We believe there should be no friction between what your thought is and the reality that comes out, that you can share with your friends, right? That's what we're building toward at every layer of the stack. If we have to go down to energy, we'll go down to energy at some point, right? It matters a lot to us from the experience of giving people access to this tooling.

It's gated behind multiple layers. It's not even just gated for regular citizen developers who are now vibe coding. You have the citizen developer, the front-end developer, the back-end developer, a DevOps person—all of these layers, right? They all need to disappear so people can just ship like that.

Shawn Wang

Amazing. All right, that's the future of cloud.

Avi Press

Thank you for having me. It's been wonderful.