Latent Space: The AI Engineer Podcast - Railway: The Agent-Native Cloud — Jake Cooper
Episode Date: May 20, 2026Take the 2026 AI Engineering Survey and get >$2k in credits and AIE WF tickets!This was recorded before Railway suffered a major GCP outage on May 19, despite being a multi-AZ, multi-zone mesh ring, w...ith HA fiber interconnects between their Metal GCP AWS, because workload discoverability was unintentionally still tied to GCP. All has been resolved with a post-mortem.Railway did not start as an AI infrastructure company.It was founded in 2020 years before agents became the default way people thought about deploying software. Jake Cooper, formerly at Bloomberg and Uber, started Railway with a simple obsession: the activation energy to ship something to production should be near zero. Push code, get a URL, iterate. No Docker files, no Kubernetes manifests, no Ansible scripts stacked on Ansible scripts.For years, this was a slow grind. Railway spent its first 18 months hand-acquiring its first 100 users with Jake personally greeting every Discord signup on a second monitor.Today, Railway has raised $124m and is growing very fast. A 35-person team supports 3 million users, adding roughly 100,000 signups a week. Their bare metal data centers have a 3-month payback period vs. renting in the cloud, with 70% margins funding aggressive cloud bursting when needed. The servers they own have actually appreciated in value as RAM prices have climbed basically meaning the value of their hardware now exceeds the capital they've raised.From rebuilding Railway’s network overlay over a weekend to moving the vast majority of workloads onto its own bare metal data centers, Jake Cooper is trying to build a new cloud for an agent-native world. In this episode, Railway’s founder and “conductor” joins swyx and Alessio to unpack why the next era of software infrastructure is not just “Heroku but newer,” what agents need that humans did not, and why the old deployment loop of Git, PRs, CI/CD, and static cloud resources may be heading for a rewrite.We go deep on Railway’s infrastructure stack: own-metal data centers, three-month cloud payback periods, cloud bursting, data center debt, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable filesystems, agent-safe production forks, and why the CLI may become more important than the canvas in an agent world. Jake also shares the founder journey behind Railway, how the company survived losing $500K/month, why it now serves millions of users with only 35 people, and why he believes the pull request is dying.We discuss:* How Railway went from a slow six-year grind to adding 100,000 users a week* How Railway thinks about agents as the next dominant software species* Why agents need version control, observability, compute, storage, and orchestration at 1000x scale* The economics of Railway’s own-metal data centers and three-month payback* How Railway uses cloud bursting while scaling its own infrastructure* Why data center debt can be a better tool than venture debt for infra startups* Central Station, Railway’s internal system for clustering customer feedback and incidents* Why responsible disclosure and over-communication matter for platforms* Why feature flags, progressive rollouts, and shadow traffic are essential for agents* Temporal’s strengths, pain points, and why workflows matter for agents* Railpack, Nixpacks, Nix, and lazy-loaded content-addressable filesystems* Why “cattle, not pets” may change if you can clone the pets* Why Railway is building a new cloud from scratch instead of copying hyperscalers* The solo founder path, focus, writing, and how Jake thinks about company buildingRailway:* Website: https://railway.com/* X: https://x.com/RailwayJake Cooper:* LinkedIn: https://www.linkedin.com/in/thejakecooper/* X: https://x.com/JustJakeTimestamps00:00:00 Introduction: What Is Railway?00:02:07 Jake’s Path to Railway00:06:13 Railway’s Six-Year Growth Story00:08:52 Rebuilding the Business After the Free Tier00:11:17 Agents as the Next Software Platform00:13:29 Railway’s Infrastructure Philosophy00:15:42 Bare Metal, Cloud Economics, and the Compute Crunch00:17:22 Cloud Bursting and Five-Cloud Networking00:20:20 Data Center Debt and Infra Financing00:23:31 Data Centers in Space00:25:24 What Agents Need From Infrastructure00:28:24 CLIs, Canvas, and Agent-Native UX00:35:15 Central Station, Incidents, and Responsible Disclosure00:40:30 Safe Rollouts, SRE Agents, and Production Forks00:45:00 AI SRE, Specs, Code, and Tests00:48:24 Self-Replicating Infrastructure and the New Serverless00:53:18 Heroku, Temporal, and Workflow Engines01:04:07 Railpack, Nixpacks, and Lazy-Loaded Filesystems01:06:01 Coding Agents, Token Spend, and Roadmap Acceleration01:10:56 The Pull Request Is Dying01:12:28 Feature Flags and the Agent-Era SDLC01:16:15 Cattle, Pets, and Cloning Machines01:19:29 Solo Founder Lessons01:24:12 Focus, GPUs, and Building a New Cloud01:28:20 Closing ThoughtsTranscriptAlessio [00:00:00]: Hey, everyone. Welcome to the Latent Space Podcast. This is Alessio, founder of Kernel Labs, and I’m joined by Swyx, editor of Latent Space.Swyx [00:00:10]: Hey, hey, hey. Today we’re in the studio with Jake Cooper of Railway.Alessio [00:00:14]: Conductor of Railway.Swyx [00:00:15]: Conductor at Railway. Yeah.Alessio [00:00:16]: Choo-choo.Swyx [00:00:17]: Do you actually have that anywhere, like on your business card?Jake [00:00:20]: We call some of our volunteer moderators conductors. 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, this is pretty official.”Swyx [00:00:30]: Business cards are coming back.Jake [00:00:32]: They’re cool. They’re hip. The conductor thing is good. We’re trying to figure out what we want to call each other internally. Some people think it’s super cringe and say, “You don’t need a name for people internally.” Some people want to call each other something. We still don’t have a really good one.Jake [00:00:55]: We’ve got New Railcrews, Trainiacs. Nothing has stuck yet.Swyx [00:01:00]: I like Trainiac. Trainiac sounds good. Railwayians. For those who don’t know, what is Railway? Let’s give people a crisp definition up front.Jake [00:01:09]: Railway is the easiest way to ship anything. You go to the canvas, or you talk with Claude, and you say, “Deploy a Postgres instance, deploy my GitHub repository, run this code,” and you’re off to the races.Swyx [00:01:22]: You’ve got a nice animation on the landing page.Jake [00:01:24]: Thank you. None of my work, by the way. They don’t let me touch the design stuff anymore.Jake [00:01:25]: We want to make it trivially easy not just to deploy things, but to evolve applications over time. Most tooling right now stacks entropy on top of entropy: Docker, Kubernetes, Ansible scripts, and all these other things. If we can version all of your software and keep track of all the changes, then we can make it trivial to clone environments, fork into a parallel universe, get copies of production data, get copies of any services, make changes, validate them, and collapse them back in without reproducing everything across a staging environment.The Railway Origin Story: From Uber Systems to a New CloudSwyx [00:02:07]: I was looking at your background: Bloomberg, Uber. Nothing immediately stands out as, “This guy is going to found the next great platform as a service.” What prepared you for Railway?Jake [00:02:21]: It was curiosity to keep going deeper. I started out on front-end stuff, working on Wolfram Mathematica and porting it over. Then I briefly moved to Bloomberg, then toward Uber and distributed systems, taking the Jump Bikes systems and moving them to a distributed system built on top of Cadence, the pre-Temporal Temporal.Swyx [00:02:44]: Which, by the way, I’m happy to talk about, pros and cons.Jake [00:02:48]: Totally.Swyx [00:02:51]: But let’s do the Railway story.Jake [00:02:52]: It has been a continual step of wanting an experience. Whether it’s walking up to a bike, unlocking it, and having it work frictionlessly, or something else, the depth required to make that happen follows from the experience. A lot of the work I do, and a lot of the team does, is 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.Jake [00:03:17]: I don’t have a physics PhD. I did an EECS degree. It has always been about figuring out the next step: how do we get there? That’s what led to starting Railway for that experience and then moving all the way to bare metal data centers. I was adding patches to the kernel this week to get the experience there because I can see how much better it can be.Swyx [00:03:49]: Other patches to the Linux kernel this week?Jake [00:03:51]: Yeah. Not upstream. Our fork.Swyx [00:03:52]: That’s a flex. Railpack? No, this is different. This is the OS on top of Railpack?Jake [00:03:57]: No, this is an actual kernel patch. It’s always literally: what do we have to do to get that experience? Then figure it out. Anything is figureoutable.Swyx [00:04:10]: Would you send the patch upstream, or does it not fit other use cases?Jake [00:04:13]: Maybe. We have to work out the experience internally. It has to do with the storage layer we’re building for some of the agentic stuff. Maybe it’ll be useful upstream, but it’s deeply useful for us internally.Open Source, Forks, and Non-Deterministic VersioningSwyx [00:04:29]: You mentioned open source before. How do you think about starting from open source, and then coding agents letting you do a lot more from forks of it?Jake [00:04:38]: GitHub’s original sin is that it’s almost a series of broken pointers. You have this thing, then you clone it, and now you’ve lost the whole upstream. How do we make it trivial for people to modify really small pieces of it?Jake [00:04:51]: We think of Git in a discrete sense: I’ve either made a change and merged upstream, or I haven’t. What would it look like if it were percentage-based, a little more non-deterministic, or a stream of changes that users traverse as a percentage rolled out in general and then rolled all the way up?Jake [00:05:13]: We have the open-source kickback program and let you deploy templates because we want to make it trivial for people to version these shards over time. It solves a large problem around authentication, authorization, and security. NPM has a way to define, “Don’t take any new packages.” The ideal end state is that you roll out progressively to users with the minimum impact zone and continue rolling up. JPMorgan should probably be the last one on the patch line, for all our sakes, because our money and livelihoods are there.Jake [00:05:53]: It’s okay if Johnny Vibe Coder gets a broken patch because there’s so much entropy in the system that the rubber has to meet the road at some point. You have to test at varying levels.The Long Grind: First Users, Free Tier, and Making the Business WorkSwyx [00:06:13]: I wanted to pull up this glorious chart, which is your usage or number of daily signups?Jake [00:06:22]: Daily signups, I think.Swyx [00:06:24]: You started six years ago. It was a slow grind, and now you’re on a rocket ship. You say, “Don’t doubt your fight and don’t quit.” Maybe pick out certain points that were key inflections for the company.Jake [00:06:40]: At the start, it’s about getting your first 100 users, hell or high water. We had a website and a support link. The support link was the Discord channel. I had notifications on with two monitors: the monitor I was working on and the other monitor with Discord. If anybody came in, I was immediately like, “Hey, how’s it going?” It was rare, so getting those first 100 users to come back was the start.Jake [00:07:14]: Then you build a consultancy factory because users want all these things. You have to go back to the board and ask, “What is the actual product offering I want to build on top of this?”Jake [00:07:28]: VCs want charts that always go up and to the right, but in reality you don’t necessarily want charts that look like that. For us, there have been periods of expansion where we add features to test use cases, and periods of compaction where we ask, “If the experience we have is good, how do we make it significantly better?” Maybe we strip out features that don’t fit our ICP anymore.Jake [00:07:57]: The boom from 2022 to 2023 came from the free tier. Everybody under the sun was using it.Swyx [00:08:09]: A lot of Reddit bots and Discord bots.Jake [00:08:12]: And crypto miners. When you build an open product on the internet where anybody can sign up, the internet is a horrible place with so many things. You go through periods of asking, “How do I reach as many people as possible?” Then, “How do I fit the exact use case for the people who really matter and are really excited about this specific thing?”Jake [00:08:39]: Then there was a two-year period of making the actual business work. During the free-tier era, we were losing about half a million dollars a month.Swyx [00:08:59]: On a $20 million bank account.Jake [00:09:02]: On a $20 million bank account with maybe $50,000 a month in revenue. That’s a horrible business. I don’t know how anybody invested. But you have to go through it and say, “We have an experience people love, but the business has to work.”Jake [00:09:17]: There are two schools of thought. You can run the horrible business all the way up with bad margins, or you can go back and make it work. We’ve always wanted a super lean team. We’re 35 people right now. It’s very small.Swyx [00:09:36]: Supporting three million already?Jake [00:09:38]: Yeah. We’re adding 100,000 users a week right now, so it’s growing fast. We don’t want to add headcount for the sake of headcount or throw bodies at problems. We want to build systems. It’s hard to build systems during expansion because you’re adding things to the system because people are asking for them or things are breaking.Jake [00:10:00]: We had to cut off the free users for a little while, rebuild the business, and make sure it worked. We want to reach as many people as possible because software is important. It’s become difficult to create things in the physical world, so it’s important to make it easy for people to build in the virtual world and have access to creation. But there are legs to that journey.Jake [00:10:30]: You can see divots in the charts. If you follow between 2025 and 2026, it’s either summer or winter. People go on holiday with family.Swyx [00:10:50]: It affects that much?Jake [00:10:51]: Yeah. It’s kind of B2C and kind of B2B. People are shipping constantly, then they stop. Our activation curve now shows more people activating on weekdays because we have more business users, so it smooths out over time.Agents as the New Interface to DeploymentSwyx [00:11:17]: Was there a point where you started prioritizing AI development or agent development?Jake [00:11:24]: We’ve prioritized agentic as a top-of-funnel thing. Over the last six months, we’ve deeply prioritized agentic as a mechanism to build and deploy things because we believe the curve is so steep and that is how people will build and deploy software.Jake [00:11:42]: It almost fundamentally doesn’t matter whether this is dot-com or not because we’re all on the internet anyway. If agents are going to deploy a bunch of things and we hit an inference wall at some point, we’ll fix those problems. The dominant species over the next 10 years is that we’ve moved from assembly to C to C++ to JavaScript to words. You’re going to need to close that loop.Swyx [00:12:13]: When you say this is dot-com, did you mean buying the domain, or the general case?Jake [00:12:17]: I mean the dot-com era, when companies had a huge run-up because people understood the internet was important. Then they hit bottlenecks, fundamental laws of physics, math didn’t work, and everybody came back down to earth. But it didn’t matter because the internet became so impactful. If you operate on a long enough time horizon, you should build these things anyway because you can see where it’s going.Jake [00:12:45]: That’s where I think a lot of agent stuff is. You get to a point where you’re running thousands of agents in parallel. What is the inference cost? What is the compute cost? How do you make that efficient? How do you coordinate all this? We have issues coordinating humans; we don’t even have good tooling for that. Now we have to figure out how to get agents to coordinate, safely version changes, and know when to raise their hand for someone to intervene. Otherwise it becomes an interrupt factory.Railway’s Infrastructure Thesis: Network, Compute, Storage, and MetalSwyx [00:13:19]: Let’s go right into the technical side. What are the core infrastructure or architectural beliefs of Railway that allow you to do what you do?Jake [00:13:29]: The primitives matter a lot for us. We need network, compute, storage, and orchestration 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 higher-order control to place workloads in very specific places.Jake [00:13:48]: The reason is that you have to be very efficient with agents: memory reuse and all these other things, or you’re going to massively blow up your cost structure. Being able to rack and stack your own servers and build your own metal unlocks performance and cost. Experiences where you’re running 1,000 agents in parallel are not massively cost prohibitive.Jake [00:14:13]: Token use and compute use are blowing up. Over time, those things have to get a lot more efficient. You can get a lot of margin to make those experiences solid by building your own metal. That’s all in service of offering a differentiated experience to as many people as humanly possible.Swyx [00:14:51]: You have a data center in Singapore.Jake [00:14:53]: Yeah. We have two in every other region now. In Singapore, we’re adding a second one in Q3.Swyx [00:14:58]: What’s it like? I’ve never built a data center. Do you go to Equinix and say, “I want some slots?”Jake [00:15:05]: Yeah. Equinix. You basically go and say, “I want power and I want a cage.” They say, “Great, here’s what it’s going to be.” You rent the cage for a period of time, fill it with racks and servers, and hook up internet to it. That’s all the pieces.Swyx [00:15:36]: Then you handle everything else.Jake [00:15:37]: You handle everything else.Swyx [00:15:39]: What’s the math versus clouds doing it for you?Jake [00:15:43]: If we rented in the cloud, our payback period when we go to metal is about three months.Swyx [00:15:50]: Which is crazy.Jake [00:15:51]: It’s nuts. That’s four years of depreciated hardware. You’re going to see a lot of this compute crunch because hyperscalers are buying up a lot of stuff. We’re working directly with OEMs, resellers, and people building these machines: Supermicro, Dell, and others.Jake [00:16:11]: Upstream, there’s a bunch of supply pressure. When we raised our last round, between deploying capital for servers and now, the amount of money we’ve raised is less than the amount of money we have in the bank plus the value of the servers because the servers have appreciated as RAM has gone up. It’s nuts how valuable hardware has become.Jake [00:16:50]: If you look at hyperscalers, they deployed around $80 billion of capital expenditures this year, and next year will be more. That’s a massive infrastructure build-out. You look at that and think it’s crazy that they’re spending way more than the Manhattan Project. But if every person is going to run dozens or hundreds of agents in parallel, you have no conceptual idea how much compute is required to make that experience happen, even if you’re deeply efficient and sharing resources. And that doesn’t even count inference.Swyx [00:17:22]: How do you plan the build-out? The growth chart is so vertical. Are you usually at 100% utilization as soon as racks are live? How far ahead are you planning?Jake [00:17:33]: We still maintain cloud presence for bursting. We work with AWS, GCP, and a few other clouds. We can rent, and then the moment we get space or power, we compact those workloads off the cloud. We started on the clouds, then built a system to migrate to our own metal. There’s nothing that says you can’t continually do that again, and that’s exactly what we do. We never want to be compute constrained.Jake [00:18:09]: At the start of the year, we actually became compute constrained because one upstream provider wasn’t able to give us quota at the rate we needed, and the hardware was slower. I spent a weekend rebuilding our entire network overlay so we could straddle five clouds: Oracle, AWS, ourselves, GCP, and one other one. We can do more than that now.Jake [00:18:38]: We got into a spot where we were trying to pack instances tight because we couldn’t get enough compute. That led to a few reliability issues, which are now past us. I made a tweet pointing out that it’s becoming harder and harder to acquire compute at the rate these models need to acquire compute. We got bit by it.Swyx [00:19:15]: How do you think about pricing knowing you might not have your own metal available at all times? Are you pricing assuming you need extra margin if you end up going into the cloud?Jake [00:19:26]: Because we’ve built out our metal data centers, our margins on metal are around 70%. We can deeply subsidize the cloud business if we want to scale at a reasonable rate. We have a few levers: metal, which makes the margins; cloud burst; debt to buy servers; and venture capital. It’s an interesting operational problem: how much cash do we have, how much should we raise, how quickly can we deploy it, and can we scale revenue as quickly as we scale compute?Jake [00:20:05]: If we continue making it trivially easy for people to build and deploy, then the faster we close that loop and the more operationally excellent we are with capital, the faster the business can scale. It’s almost a straight linear deployment rate.Financing Infrastructure: Hardware Debt, VC, and Operational LeverageSwyx [00:20:20]: I think infra startups raising debt is a tool people don’t utilize enough or know enough about. What can you tell us about that? Is it secured against your CPUs?Jake [00:20:32]: It’s secured against our hardware.Swyx [00:20:37]: What rates do you get? Who are the lenders?Jake [00:20:39]: We pay prime plus a spread, and we can refinance any of the debt as rates go down. The terms are pretty good. The unfortunate thing is that Twitter has no nuance, so people say, “Venture debt bad.” But as with all things, there are specific tools and areas where you can be deliberate instead of using one tool as a hammer. Venture capital is not the hammer for everything. You have to explore and figure out what works.Swyx [00:21:12]: VC is usually the most expensive financing you can get.Jake [00:21:15]: Yeah. I also think people think about VC incorrectly from a capital-raising perspective. Most people think, “How do I raise as much money as possible from whoever is probably the best I can get at that time?” That’s close to right, but what we’ve tried to do is figure out what unfair advantage we can buy with that equity.Jake [00:21:34]: It’s the most expensive equity you’re going to give away at that point in time, assuming the company keeps getting better. How do you use it to work with someone stellar who complements you? In the seed stage, I had never started a company. Ray Tonsing had good advice, and I could text him all the time. He was really fast. Awesome.Jake [00:22:01]: Then with John and Erica at Unusual, they said, “You roughly know what you’re doing building a product. We’ll mostly leave you alone and be available for advice.” Amazing. Then we got to Series A and the business was an operational tire fire because we didn’t know how to scale a business. Work with Erica, and Jordan is over at Redpoint, so bonus.Jake [00:22:28]: Now we’ve raised from TQ and FPV as we’re moving into enterprises. Every step of the way, we’ve asked: who can we partner with at this specific time to unlock the next section of the journey? I don’t know enterprise sales. As an engineer, I can eyeball what features we might need, and we have wonderful people internally who can help. But you want boardroom dynamics where everyone is aligned and asking, “How do we win this?” instead of bickering about strategy.Data Centers in Space and the Physics of ComputeSwyx [00:23:31]: You had a tweet about data centers in space. Why no data centers in space?Jake [00:23:37]: It’s not “no data centers in space.” My hot take is that I think it is solvable. I’ve just never seen anybody solve it.Swyx [00:23:49]: You said, “How are you going to dissipate that much heat in a vacuum?” You’re making a physics claim.Jake [00:23:55]: I haven’t seen anybody prove how you’re going to dissipate that much heat in a vacuum. It doesn’t mean it’s not possible. It just means nobody has brought it up yet.Swyx [00:24:05]: Astrophage.Jake [00:24:06]: I don’t know what that is.Swyx [00:24:07]: The Martian thing. Okay, you’re very logical.Jake [00:24:09]: It could work. A lot of people are putting the cart before the horse. They say, “We’re going to put data centers in space.” Okay, but how? “We have time to figure it out.” It’s like in The Martian where they ask how they’re going to intercept something and say, “We’ll figure it out.”Swyx [00:24:36]: Making a bet on human invention is weird because you blind trust that it can be solved. But with physics, there are first-principles bounds you can put on it. Maybe not. Maybe you’re asking to travel time or break a fundamental thermodynamic law.Jake [00:24:57]: I don’t know how VCs do this either. How do you know what’s not possible and a grift versus what’s possible but sounds completely insane? “We’re going to put data centers in space.” Coin flip as to which it is, and I guess you’ll know in 10 years. That’s one cycle.What Agents Need: Versioning, Observability, and 1,000x ScaleSwyx [00:25:23]: Moving back to agents. The branching, fast spin-up, and orchestration you do feels like pre-work that happened to be exactly what agents want. What do agents want differently than humans?Jake [00:25:37]: They want the ability to version things. It’s not that different; it materializes slightly differently. Agents want a way to test changes incrementally. Engineers have feature flags. Is there a reason agents can’t use feature flags? I don’t think so.Jake [00:25:54]: They want version control. Can we use Git or not Git? That one is up in the air. I think something outside Git will emerge for how we version these things over time. They need observability. You need to query what happened, when it happened, which steps failed, traces, logs, metrics, and all the rest. They need network, compute, and storage. They need to write files, save files, iterate on files, and snapshot file systems.Jake [00:26:25]: A lot of what humans needed is in line with what agents need. Branching and forking are not different; we’re just moving 1,000 times quicker. It can look like you need something massively different, but what you need is something massively better than what existed. You need orchestration massively better than Kubernetes. You need networking probably better than Envoy. It goes all the way down the stack.Jake [00:26:55]: If the workload profile doesn’t change so much as it gets massively compressed because you need thousands of these things, what assumptions change? etcd is going to melt. You need to replace it with something. You can go all the way down the stack and say, “That part has to change, that part has to change, and that part has to change.”Jake [00:27:19]: The interesting thing about the super-exponential curve is that you have to build systems where you can rip out those parts at any time because a new bottleneck might emerge. You get good at parallel agents, and a different part of the system breaks. So it’s similar to what humans needed, but at 1,000x scale.Jake [00:27:55]: How do you do code review in the age of agents?Swyx [00:28:00]: You throw more agents at it.Jake [00:28:01]: You don’t. But then who reviews for CVEs and all these other things?Swyx [00:28:07]: More agents.Jake [00:28:08]: And that’s how we hit the inference wall. You can continually throw agents at the problem, but I think there’s a limit to the number of agents you can throw at a problem.CLI, Agent Handles, and Closing the LoopSwyx [00:28:24]: You already had a CLI before it was cool. How is the shape of what you’re exposing changing, if at all?Jake [00:28:28]: CLIs have always been cool. The CLI changes because we think about how to give Claude, Codex, ChatGPT, or any model a handhold.Jake [00:28:50]: A CLI is a single command: deploy, get logs, and so on. Things that were prohibitively annoying to humans are not annoying to agents. They’re nice. If I handed you a CLI with 40 arguments and 600 flags, you’d think, “I’m never going to use all of this.” But if you hand it to an agent, it says, “This is excellent. I have so many handles to work with.”Jake [00:29:24]: If you’re going to expose things to agents that way, you want as many handles as possible where they can get information, query dynamic information, and close the loop quickly. Most problems right now are about how to close the loop as quickly as possible. Where does the agent get stuck, and how can you remove that?Jake [00:29:49]: Telemetry is important. If you can tell where the agent gets stuck from the CLI and say, “12% of people deviate from the happy path because of this, and now I add this argument and drive it down to 2%,” you massively increase the rate of loop closure.Jake [00:30:03]: That’s how we think about not just the CLI, but every point in the dashboard. It’s a user journey: I hear about Railway. I get something deployed. I get my first green build or aha moment. I see an endpoint, logs, whatever. Then I iterate. The iteration loop is indefinite. The user wants to deploy a new thing, a Postgres instance, change code, and keep iterating.Jake [00:30:36]: If you focus on the iteration loops and what’s blocking them from closing quickly, one thing we say internally is: you never want to be waiting on compute anymore. You always want to be waiting on intelligence. If you’re waiting on compute, there’s a bottleneck that needs to be destroyed because eventually that bottleneck becomes so large that another workflow emerges to change it.Jake [00:31:04]: We’ve built a product where you push code, build it, and so on. But I fundamentally believe the push-pull loop is going away. We’ll get to a point where you make a small change in production, that change is versioned across your infrastructure, you’re working alongside copy-on-write versions of your database and infrastructure, and then you merge it in and it’s instantaneously live. That’s the holy grail of loops. The push-pull-rebuild thing is a point of friction that we’re removing entirely.Canvas as Output: Dashboards, Context Anchors, and HyperstructuresSwyx [00:31:43]: It’s incredibly fast. If anyone hasn’t tried it, that fast feedback is great. My hot take is that Railway was famous for its canvas, which visualizes your infrastructure and lets you manipulate it visually. But that was for humans. For the next phase of growth, Railway CLI is more important than canvas.Jake [00:32:05]: The canvas is funny because it’s a mechanism to show changes over time. You’re right that previously we used it a lot as an input. Moving forward, its goal is more like an output. You would go to the canvas, make changes, see them, and watch your infrastructure evolve. Now agents have access to the CLI and can make those changes. So the canvas becomes an output: what information does the human need at this moment to make suitable decisions about control requests? Do I approve this or not?Jake [00:32:57]: It also has to be an anchor for your context, a port in the storm. Think of it like layers in a file system. You start with a project, then drill down into services, then into a function or code, because you want to represent the entire thing not just in your head, but in the canvas. Other people can share that representation, think on the same wavelength, and move quickly.Jake [00:33:33]: A lot of organizations get in trouble as they scale because all the context lives in someone’s head. “How does this microservice work?” “I have no idea; go ask this person.” Then you have whole categories of products built around context discovery. A lot of that melts away if you have a solid hierarchy and can infinitely nest services, code, context, and everything else all the way down. That’s what lets you build these structures over time.Jake [00:34:18]: It’s also what lets us build what I’ve called hyperstructures: things that are way bigger. You look at the Golden Gate Bridge and ask, “How did we build that?” There’s a meme that we lost the technology. To some extent, yes, because the coordination that built those things evolved and changed. We lost some of the art of building structure as we jammed everything into Slack.Swyx [00:34:52]: But you jam everything in Discord.Jake [00:34:53]: Same point. It doesn’t matter. It’s message passing and interrupts, message passing and interrupts.Swyx [00:35:00]: So you’re arguing there should be something better and more structured than Slack?Jake [00:35:04]: Yeah. For sure. I think Slack is awful, and Discord is awful too.Central Station: Context Routing, Support, and Incident ClustersSwyx [00:35:09]: This is the equivalent of my mom test. What have you done that has your solution to this?Jake [00:35:15]: Internally, we’ve built a tool called Central Station that aggregates all the context from our users. Every piece of feedback, every customer support item, everything gets aggregated into clusters. If an incident is brewing, we can determine how many users are affected and break off a discussion based on that.Jake [00:35:40]: That is more helpful than long-running channels where you’re trying to decide which channel to put something in. If you can dynamically aggregate information and dynamically route it to the right person based on context, it works better. We know internally that these four people are close to networking. If we see a networking thing, we can drill it down to those four people. If it’s with this part, we can look at the commits. This is no longer a manual process internally.Jake [00:36:13]: If you go to station or help.railway.com, that’s why we built it. We wanted to scale with a massive amount of leverage by aggregating feedback.Swyx [00:36:27]: This is built in-house?Jake [00:36:28]: Yep.Swyx [00:36:29]: I remember helping out on this one with Angelo in 2023. You scale a lot with a very small team.Jake [00:36:38]: Yeah. We’re about 10 times bigger now.Swyx [00:36:40]: You have your full developer code here? Very cool.Jake [00:36:44]: If you go to railway.com/stats, we expose this as a pub-sub-able thing. It’s all real-time metrics. There’s a way to get it as JSON somewhere if you care.Jake [00:37:01]: We’re big on trying to build everything in public and talk about what we’re working on. We’ve had issues in the past, and we’ll say, “Here’s how we’re fixing these things.” We’ve gotten compliments and flak for incident reports. We’re always trying to make them better and talk with people.Incidents, Disclosure, and Progressive RolloutsSwyx [00:37:20]: You had a big one recently. I liked that it was scoped to 3,000. You presumably used Central Station. Talk through what happened and how you address it internally as a team.Jake [00:37:38]: Internally, this one really sucked. It had to do with an upstream provider that didn’t do the behavior it said it documented, which is unfortunate given they wrote the RFC for how the behavior should work. We rolled those things out, and Central Station caught it initially when a couple users said caches weren’t invalidating. We turned it off immediately.Jake [00:38:03]: When you roll out to a large user base of three million people, you get a lot of disparate behaviors. We tested in staging and had tests, but we hit an edge case. We’ve hardened those systems, and now we can make that better. But it was a tough one.Swyx [00:38:39]: I always wonder how private disclosure is supposed to work if people find an issue. Are they supposed to contact you first? When you run a platform, these things will happen. What channels should people pursue to quietly resolve it before it becomes a bigger incident?Jake [00:38:59]: There’s responsible disclosure. We err on the side of over-disclosing and letting you know something is wrong versus having your provider gaslight you. We’ve erred on sharing those things more publicly, even if they impact a small subset of users. That’s a decision we’ve made internally. We have four values. One is honor. The honorable thing is to notify people to the widest degree at which they may have been affected or there was an issue, and then confront it head-on: why did it happen, what can we do better?Swyx [00:39:45]: Not the whole user base. That’s because of incremental rollouts and other things?Jake [00:39:50]: Yeah. Progressive rollouts.Swyx [00:39:54]: That should be the norm at all large platforms.Jake [00:39:58]: It should. A variety of companies do this. There’s the quote that Meta runs 10,000 different versions of Meta. To our earlier point about agents, they need the same thing. They need shadow traffic and all these other things. We’ve built so much ceremony around production being sacred that we need to make it trivially easy to test different behaviors in a safe environment. Then you can make mistakes in a safe environment.Safe AI SRE: Customer Agents, Forked Environments, and Production ParityAlessio [00:40:30]: Do you see a world where these things get automatically caught, not necessarily by your agent, but by your customer’s agent? The cache invalidation issue seems easy to check if you know to look for it.Jake [00:40:44]: It’s hard because to determine it, we almost need to hook into your observability infrastructure. That’s why we have the template loop on the platform: so you can roll things out progressively. You can roll out to Johnny Vibe Coder initially, or push a shard that someone consumes at their own leisure. Or you can roll it out over weeks: 0.1% of people, 1% of people, early adopters, then all the way up. That’s the non-deterministic version control we talked about earlier.Jake [00:41:30]: I believe that’s where most things should go, because most companies end up building staged rollout systems in-house. It’s the same thing built again and again at every company. There’s a massive opportunity to consolidate developer debt.Alessio [00:41:45]: You should have a free tier. Model providers give free tokens if you let them use the data. You could give free compute if someone is the number-one shard that goes out and lets you plug into their observability.Jake [00:41:55]: We do that. That’s why we talked about the impact on 3,000 people. We start with lower-impact people. Larger companies on the platform are last to receive those rollouts so they have a version of the platform that’s deeply stable.Alessio [00:42:16]: I have three services, so I’m sure I get the first rollout. You can nuke my thing at any time. There are all these SRE agent companies. Observability people also want agents that fix upstream problems. You have your own agent in the canvas now. How do you see that playing out?Jake [00:42:39]: It’s the stacking entropy problem. If you don’t have primitives to make iteration in production safe, it becomes difficult. If you’re an observability provider saying, “Here’s the fix to this error,” assume 80% are good and make sense. But in the last 20% long tail of complex issues, if you let somebody stamp it, you create an opportunity for an incident.Jake [00:43:08]: That’s why forked environments are important. People have staging, but it always drifts from production. You need primitives, workflows, and experience built first-party on the platform so you can fork any service at any point in time.Jake [00:43:33]: I think of the canvas as a sheet of transparency paper. The agent is a little guy you push up into the canvas. It should say, “I need to copy that service and that service so I can test these two things.” It gets a read-only copy of production. Anything that’s PII gets marked as a transform when we clone the database, create a copy-on-write version, or read from it. Then the agent makes changes and asks, “Does this actually work?” as close to production as possible.Jake [00:44:22]: That’s how close you have to be, or you get massive drift. The system becomes unstable. You see this with massive systems built on Docker for local, Kubernetes for production, and a specific thing for something else. That complexity slows developers and becomes unstable at scale, making it hard to iterate. We want to compress that way down and say, “As close to prod as possible is where we want to be.”From AISRE Skeptic to Agent BelieverSwyx [00:45:00]: I was texting Erica for questions, and she says you were originally not a believer in AISRE. Have you come around on it?Jake [00:45:10]: I flipped, but I’m still not a believer in AISRE if you don’t have the primitives to make it safe. If you unleash AISRE on production infrastructure without safe primitives for copying volumes and making sure things are fine, it’s going to nuke your production database. It’s not a matter of if, but when. I’m a big believer in making those loops safe.Jake [00:45:33]: I was a deep AI skeptic until 2023. In 2024, I thought, “Maybe I can roughly make this thing do it.” In 2025, I thought, “Now I can hold this.” Over winter break, everybody came back saying, “It’s almost impossible to hold this.”Swyx [00:46:01]: Did you see this on the Claude docs? CloudBot? OpenCloud?Jake [00:46:06]: It’s gotten to a point where it’s harder to hold it wrong than to hold it right. There’s a scene in Avengers where Vision picks up Thor’s hammer and says it’s terribly well-balanced. It self-balances and works well. I’m a deep believer at this point that this will be the dominant species: assembly, C, C++, JavaScript, words.Swyx [00:46:35]: It feels like a big jump.Jake [00:46:37]: It is. But it’s not like you abandon CPU-based discrete logic and move straight to fuzzy logic. You need both. Your skills should call code or applications or some static structure. You can use skills to distill what the procedure should be or how the code should act.Jake [00:47:02]: I’m coming to a thesis: you need three points. You need a clear spec defining the system, the code, and the tests. When you say it out loud, if you’ve been in engineering long enough, you’re like, “Of course. That’s an RFC, tests, and code.” But they all matter. Having them together lets them reinforce each other: the spec and tests match, but the code doesn’t, so reconcile it. Or the tests and code match but the spec doesn’t, so reconcile that. That’s the iteration loop.Jake [00:47:41]: That’s why you’re seeing people talk about software factories, docs, and reconciliation. Some of that is architectural astronomy if you don’t implement it, but that loop is where most things will end up.Swyx [00:48:07]: For listeners, we’ve been talking about this on the pod for three years: the holy trinity of specs and tests. Itamar Friedman from Qodo is the reference if people want to look it up.Self-Modifying Infrastructure and the End of Push-Pull-RebuildSwyx [00:48:18]: One thing I want to mention on the OpenCloud idea is self-modification. I don’t know how Railway would support it, but I have my OpenClaw, and I just tell it it has the Railway CLI and can do whatever. In theory, whatever capabilities or new infra it needs, it can call the Railway CLI, provision it, and add it to itself. The agent can modify its own infra.Jake [00:48:45]: It’s nuts. I have a loop set up where you put the Railway CLI on top of something that runs on Railway. You’re authenticated as whatever the current box is, and you can make any changes to it. Then you call Railway deploy, and it deploys itself.Jake [00:49:04]: It’s like: “I need to spin up this instance of this environment. I already exist in this environment. Excellent, I have access to a Postgres instance now.” That’s where we want to go with agentic, self-replicating infrastructure. That’s your loop: iterate in production. You continue making changes. If it works, merge it upstream. If it doesn’t, throw it away.Jake [00:49:37]: How do you make throwaway copies trivial to spin up and super cheap? The era of “I have an AWS instance with four vCPU and 16 gigs of RAM” is going to get destroyed. If you do that for agents, you need a thousand of those machines. It’s prohibitively expensive compared with what we’ve spent a ton of time figuring out: the atomic unit of deploy, whether you call it isolates, sandboxes, or something else. Only pay for what you use, spin up instantaneously, and close the loop as quickly as possible.Jake [00:50:15]: If the system can self-replicate safely and say, “This is my environment, I’m making these changes,” it can come back with, “Does this look good? This is a new state of infrastructure given this prompt. I think I’ve solved it.” Then you go back and say, “Actually, it looks different.” It does the loop again. Then you say, “Cool. Apply.”Swyx [00:50:38]: That’s retroactively obvious, which is the most useful kind. Any other comments on agent deployment on Railway?Jake [00:50:51]: It’s getting better every day. I’m on X or Twitter. You can always yell at me about the parts not working as well as they should, because plenty of things should work way better.The New Serverless: Stateful, Long-Running, Pay-for-What-You-Use LinuxSwyx [00:51:04]: At this stage, when people want massively or embarrassingly parallel compute, they usually talk serverless. I feel like there’s a new serverless compared to the previous five years of serverless. You’re in that new bucket. Do you have comparisons or philosophical differences you want to call out?Jake [00:51:31]: It’s somewhere in between. It’s the ability to run stateful, long-running workflows or executions.Swyx [00:51:42]: Vercel has Fluid Compute, Cloudflare has some container thing, Google has App Runner and others.Jake [00:51:55]: That’s where everything is roughly going, and it’s why we’ve been working on this for six years. We believe users need access to a computer: a box that speaks Linux. They need to deploy what they want. Other systems change the surface area of what you can build. For us, users need a computer and need to deploy anything they truly want. That’s why we’ve focused on the primitives: network, compute, storage. If we give you those and expose them so you can run things indefinitely, that’s where we believe it’s going.Jake [00:52:43]: Twitter has no nuance, so everyone says “servers” or “serverless.” It’s always somewhere in the middle: I want to run it for a long time, but I don’t want to provision the resource statically or pay for things I’m not using. That’s been our thesis from day one: pay only for what you use, run it indefinitely, and it is full Linux.Swyx [00:53:12]: That’s why I like the naming of Fluid. It’s fluid. Flexible.Heroku, Focus, and Carrying the Torch Without Becoming the PastSwyx [00:53:18]: Another milestone is the Heroku official deprecation. You’re 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? Any behind-the-scenes of, “This is the moment”?Jake [00:53:42]: You have people where you’re like, “You were running stuff on here? You, as this company?” It’s crazy that names you would know are running on it and now coming to us saying, “We want to move a lot of this off.”Swyx [00:54:00]: Any behind-the-scenes on why Salesforce let Heroku stagnate?Jake [00:54:05]: I can only guess. It’s hard when it’s not your business. Salesforce’s business is to build a great CRM. That’s their focus. Then you acquire a compute business as an offshoot. A lot of early Meta people talk about focus. Boz has a write-up about how in the early days of Meta they had no money, so they were forced to focus. Then they turned on the money tree and had no reason not to split their focus.Jake [00:54:52]: But that dilutes your product. You get offshoots where you ask, “Is this the focus of the business?” If it’s not core, it languishes. A lot of companies get in trouble when they split focus because they’re fighting a multi-front war, not just externally but internally for alignment. Where are we going? What are we doing? What is our purpose?Jake [00:55:24]: If you’re Salesforce-built and mission-driven, you want to work on Salesforce. Heroku is off to the side. It’s not core to the business. Getting resources, budget, focus, and alignment internally becomes hard. It was a matter of time.Swyx [00:56:06]: Kudos for them to call it out instead of leaving it unknown.Jake [00:56:12]: Their release was a little odd. They called it out, but they didn’t say they were shutting it down. Behind the scenes, I think they issued messages to people saying they should close accounts and that they were going to deprecate and remove things over time.Jake [00:56:30]: It’s crazy because some of my first deployment experiences were on Heroku. You start with dragging things into an FTP server, then you try to get a deploy working, and then it’s Heroku. It was the on-ramp for us. But the wheel turns. New things emerge. We’re happy to carry the torch for a lot of that. But we don’t want to be the new Heroku. We want to be the way people build and deploy software, and ultimately the way people monetize software over time.Swyx [00:57:19]: It’s still a big crown to be the new Heroku. There are 50 companies that fought for that.Jake [00:57:23]: Everybody is holding some portion of it. We’re happy to support people and companies. The platform works differently. The game loop is similar, but we’ve been dogmatic about where these things are going: primitives, agents, fan-out. Some things fit; some workflows need to change. We have an approximation of Heroku pipelines with the environment system. It’s exciting. We’ve got a ton of people we can support, and it’s growing a lot.Temporal, Workflow Engines, and State MachinesSwyx [00:58:12]: I have one more technical question about Temporal. I’ve sold my shares. You’re a power user and one of our earliest customers. I met you through Temporal. You built on Temporal. You have complaints. This may be the most neutral and informed conversation anyone will hear about Temporal without someone working at the company.Jake [00:58:39]: That’s fair. I’ve used Temporal for almost 10 years because of Cadence at Uber.Swyx [00:58:52]: Give people a sense of what Cadence was at Uber.Jake [00:58:57]: Cadence was the precursor to Temporal. It powers trip actions, rides, when you rent a Jump bike or scooter or car. You’re running workflows for a period of time and saying, “This ride will run indefinitely until it finishes.” You attach information: you paused in this zone, so add this charge to the bill. When you end the trip, the workflow is done. That experience was powered by Cadence at the time.Swyx [00:59:34]: I used to say it’s like programming the entire user journey top-down as one function.Jake [00:59:39]: It’s a powerful idea and important. It’s also important for the next phase of the agentic journey. You want an agent to do a specific task, be complete or incomplete on that task, and move on to the next thing. You need a way to manage workflows dynamically.Jake [00:59:59]: Temporal was always great in theory, and great when you got it working the way you wanted in production. But it required you to model the entire journey in your head. If you didn’t, you could cause issues where replaying the state of the workflow causes non-determinism.Swyx [01:00:25]: Because it works on deterministic workflow history.Jake [01:00:28]: Exactly. I describe it as a jet engine. If you know how to operate it and run it, it’s great. But you can’t hand it to people trying to build complicated things if they don’t have the whole state in their head.Jake [01:00:48]: We run our whole deployment pipeline on top of it. That’s a reasonably complicated workflow: pre-commit hooks, signaling, queuing, and all the rest. We ran into the same thing at Uber. As you express a large workflow, it gets more complicated, with more states in the state machine that you have to map back to the workflow.Swyx [01:01:15]: It’s a lot of ifs.Jake [01:01:16]: Exactly. At Uber, we built a system for doing the state machine and testing it. We’ve started to build some of those things here because it’s grown heavily. It’s not quite love-hate. When it works well, it works super well. But if someone who doesn’t have full context puts something into the system that invalidates state or causes non-determinism, or spins off a ton of activities, you have to keep track of underlying SRE knobs like activity slots. Those should scale with memory, vCPU, and so on. It becomes a bear to scale.Swyx [01:02:10]: You need a capable sysadmin running things behind the scenes. If you moved off, what would you do?Jake [01:02:19]: We’d build our own workflow engine. We have a few internally that we’ve worked on.Swyx [01:02:27]: This is one of those classes of things you typically wouldn’t vibe code, but I’m wondering if you can.Jake [01:02:33]: I still don’t think you should vibe code it. You still want to run decent tests to make sure it works.Swyx [01:02:39]: Timo didn’t invent that from scratch either. There are libraries you can run. On top of that, it’s just a state machine that you have to map out. Ultimately, you define the instructions you want and run them through a state machine.Jake [01:03:00]: It’s very doable. Workflow stuff is interesting. Restate is doing neat stuff here.Swyx [01:03:10]: You’re tied into JavaScript. Are you a JavaScript maxi?Jake [01:03:13]: Internally, we have TypeScript, Rust, and Go. We don’t add more languages. Actually, we have a little C because we write BPF code and hooks. But those are the languages.Swyx [01:03:28]: Is this for sidecars?Jake [01:03:32]: No. It’s for the networking stack, volumes, and things like that. We use TypeScript a lot because it powers the dashboard, but we’re moving a lot of workflow stuff off the dashboard stack and into the infrastructure stack.Railpack, Nixpacks, and Content-Addressable FilesystemsSwyx [01:04:00]: Cool. Any other technical infrastructure stuff? Railpacks?Jake [01:04:07]: We built an engine for determining dependencies based on source code. It’s called Railpack. We built the first version, Nixpacks, on top of Nix, and then we moved.Swyx [01:04:17]: People have been trying to get me to adopt Nix and NixOS for four years. Is it ever going to be a thing?Jake [01:04:23]: I don’t know. We’re excited about it, but it has pain points. Think of it as a stack of versioned binaries at specific slices in time. If you want version X and version Y, you bloat the package space, which blows up image size and makes real-world workloads difficult.Swyx [01:04:53]: But you content-address it and cache it. In theory, there are optimizations.Jake [01:05:00]: In theory, yes. But with a large enough user base and disparate enough machines, you run into a problem Meta described in the XFAAS paper, their internal serverless system. It becomes difficult at scale unless you break out specific runtimes.Jake [01:05:24]: We didn’t want to do that because we wanted to truly allow you to deploy anything. That was our initial thing with Nix. But we’ve moved toward interesting work around content-addressable file systems that can lazy-load anything from any point and page it into memory.Swyx [01:05:48]: Amazing.Jake [01:05:49]: The future is very bright. It’s crazy, and it’s going to be nuts.Coding Agent Spend, Roadmaps, and Token ROISwyx [01:05:54]: Founder journey stuff?Alessio [01:05:56]: Your cloud usage: you tweeted you’re going to spend $300K this month?Jake [01:06:01]: I think we got to $200K.Alessio [01:06:02]: Coding agents?Jake [01:06:03]: Yeah.Swyx [01:06:04]: Across the company?Alessio [01:06:05]: You only have 35 people, so I’m sure they’re not all spending $10K a month. What’s the distribution?Jake [01:06:10]: I think I’m at about $25K. We have power users all the way down. We came back from winter break, and I basically said, “If you’re writing code by hand, you’re doing this wrong.” The tools are good enough now that you can move extremely quickly. There are issues and pain points, but you should be reviewing the code you are writing instead of writing it by hand.Jake [01:06:40]: Architectural patterns matter more now than ever, but you shouldn’t spend your time generating code you would write. If you know how to write it, ask the agent to write it and reconcile it until it looks like you would have written it yourself.Jake [01:06:58]: People misconstrue my propensity to push people toward agents as connected to our growth and some reliability bumps. They’re not necessarily related. The tools are good enough to move extremely quickly and build things way larger than you could before.Jake [01:07:19]: To the earlier point about cooling data centers in space: I don’t know. But with software, you can ask, “How would I build block storage from scratch? How would I do these things?” I have ideas because I have history and have read papers. Let me work them out and build massive test benches with thousands of tests, because those are now free to author. If you’re not using AI systems to speed-run your roadmap and reconcile your existing system onto the future, you’re missing a large point of what’s happening.Alessio [01:08:12]: What’s the path to spending $3 million a month? Is it bound by ideas and things customers can absorb?Jake [01:08:19]: For most companies, it’s bound by deployment at this point. That’s why we’ve seen a massive boom in users and companies, from Fortune 50s down, asking how to get developers to move faster. You’ll probably hit your CFO before any technical limits because they’ll look at the eye-watering amount of money spent on tokens. Inference costs have to come down, but we’re inference constrained now. There will be price discovery around what makes sense for an org to adopt.Jake [01:09:06]: I think you’ll end up with the F1 driver concept. If someone is really adept at these things, it makes sense to put them in a $3 million car. If they’re not, it probably doesn’t make sense. You’ll take a few people and say, “You can drive the F1 car. We need to go in this direction. Figure out if it works and prototype it.”Jake [01:09:33]: We’ve done some of that and vastly accelerated our roadmap. We thought we’d ship something in a few years; now we can probably ship it in a few months because we validated it and don’t have to build it incrementally. We can skip steps and move toward our vision.Alessio [01:09:58]: A lot of people are realizing the roadmap doesn’t always have a business impact, so they say tokens are too expensive. But if your roadmap were built to make more money by the time you built it, you’d have token pricing for it, the same way you do with sales. You’d spend a billion dollars on sales if you knew you would get $2 billion of revenue.Jake [01:10:19]: Exactly. A naive way to measure this is the percentage of tokens that end up in production. If you can measure impact because those tokens end up in production, that’s awesome. But the burden of proof will rise. Internally, we have a growing number of pull requests that haven’t merged. The question becomes: how do you get this into production? It’s about how quickly you can build and deploy software, which is exciting because that’s our whole thing.The SDLC Shift: Prompt Requests, Feature Flags, and Safe RolloutsSwyx [01:10:56]: The SDLC is changing. One thesis is that the pull request is dying. It’s going to be the prompt request. Beyond that, code review is also kind of dying if you have all the other systems in place. What else is changing about the SDLC?Jake [01:11:19]: The AISRE and the tools to make it happen. AISRE is pie-in-the-sky aspirational. What does it take to get an AISRE? What tools do you need to build?Swyx [01:11:32]: You should expose your tooling to customers at some point. The Central Station command center.Jake [01:11:39]: We have it for template maintainers. Template maintainers can deploy and maintain templates, and they get feedback. We’re going to expose those things incrementally.Swyx [01:11:51]: Clustering around incidents. Everyone has a version of that, but I don’t think anyone has solved it.Jake [01:11:56]: I won’t say we’ve solved it internally, but it’s gotten so good that we can see incidents forming pretty quickly. At some point, those will be things either someone else builds or we build. We’ve always built things purpose-built for us. If it makes sense to make it useful for users, monetize it, or turn that loop into a profit center instead of a cost center, we want to do that.Jake [01:12:28]: Pull request is definitely dying.Swyx [01:12:29]: Do you do first-party feature flagging and incremental rollout stuff?Jake [01:12:34]: We have a feature-flagging engine we built internally and will eventually roll out.Swyx [01:12:38]: I don’t see it as a user. How come you didn’t give us what you have?Jake [01:12:43]: We have to beta test it. We care a lot about the quality of the things. There’s plenty we’ve used internally that doesn’t make it all the way through the journey because it fails. It works for one service but not multiple services. We’d have to build it for multiple services and know that if we released it, we’d rebuild it again and again. Some things are worth that, but many inform the roadmap.Jake [01:13:18]: We don’t want to dilute the experience by saying, “This works, but only for this service,” unless it’s a core initiative. Over the next few months, we’ll roll out things that work for a single service, then multiple services, then multiple services across the environment. You have to be deliberate. Otherwise you create broken disparate experiences and support load because people ask how to use the feature.Jake [01:13:52]: It’s the earlier expansion and compaction pattern. You expand the company to get features, then compact and smooth them out so the experience is stellar. You told me in the hallway, “It’s gotten so much better.” Internally we’re saying, “This part really sucks. We need to make it significantly better.”Swyx [01:14:11]: I can attest to that over the last three years watching you build Railway. For listeners, feature flagging is a huge part of Uber culture. So much so that they have too many feature flags and another thing to remove feature flags. Facebook has Gatekeeper. Agents are going to need this. It’s fundamental to incremental rollouts. OpenAI acquired Statsig. GPT-5 is routing and flagging through different models.Jake [01:14:56]: It’s super important. If the software development lifecycle is going to change because we’re doing things 1,000 times faster and 1,000 times more concurrently, what becomes important at scale?Jake [01:15:16]: Before I started Railway, I built a feature-flagging product and tried to sell it. It was an easier version of LaunchDarkly. I ran into a problem: anyone small enough to adopt your technology doesn’t care about feature flags, and anyone large enough to need feature flags needs so much scale that you have to build out all the infrastructure. I scrapped it.Jake [01:15:42]: But what is old is new again. Companies are trying to move quickly, but you can’t YOLO a vibe-coded thing straight into production. You need to say, “Here’s my blast radius, my impact, and I want to shadow it for these users.” Feature flags. You’re going to need the tools larger companies built to maintain their structures. Everything gets compressed by 1,000x so everybody can build those structures quickly.Jake [01:16:07]: That’s exactly where we are: compressing the software development lifecycle, then expanding it and adding more new things.Cattle, Pets, and Clonable InfrastructureSwyx [01:16:15]: Another term that comes to mind for newer developers is “cattle, not pets.” People treat production like a pet. It has a name. You baby it and keep it alive. With cattle, you can mass farm, roll out, portion parts out, and kill them.Jake [01:16:37]: I think that might change. You can move toward having pets as long as you have a cloning machine for your pets.Swyx [01:16:52]: Yeah.Jake [01:16:52]: If you can snapshot every single thing at every frame, it doesn’t matter if something gets obliterated because you have a snapshot of it. The things we’ve built right now are designed to block changes from the hermetically sealed DevOps line. You have to write a Dockerfile because you need a specific cut of the file system.Jake [01:17:14]: What if you had the whole file system? What if you snapshot it and lazily load the entire file system? Then you get around this problem entirely. You don’t need the ceremony of Dockerfiles, Ansible scripts, or other things. You can iterate, snapshot, ask if it’s the right loop or state, and then merge it into production. Merge the file system.Swyx [01:17:45]: Why not?Jake [01:17:46]: It’s going to be fun.Swyx [01:17:47]: This is a whole other can of worms, but if you cataloged the stateful things in a VM and developed dedicated solutions for each, you can cut the problem down a lot. It’s surprising people weren’t trying until now.Jake [01:18:04]: It has always been surprising to me because these are the things we would work on. It’s obvious.Swyx [01:18:11]: At first principles, you need them. Everyone needs them in theory. Then the big clouds don’t do them, so you assume it’s impossible.Jake [01:18:18]: Exactly. You think, “Meta has all the people writing eBPF code, and they’re doing something with them.” But you need that kind of work to solve these problems. Whatever is required, however deep we have to go, we’ll go all the way down to the kernel’s TCP/IP stack if needed. If we need to modify something to make it work for the mental model of the universe moving forward, we’ll do it and keep going down.Swyx [01:18:52]: That sounds fun.Jake [01:18:53]: It’s so much fun. I have to peel myself away from fun, interesting problems to make sure we can scale the company in a way that works. There are so many fun problems: getting information from customers to support to the person who built the thing internally, safe iteration, context from the dashboard to users, drilling down to the infrastructure layer, and managing orchestration as a real-time operating system versus a feedback control system. It’s just so fun.Solo Founder Lessons: Obsession, Writing, and FocusSwyx [01:19:29]: Speaking of the founder side, you’re famously outside the YC/SF consensus. You go to YC, get a co-founder, and do all these things. You did none of that.Jake [01:19:40]: None.Swyx [01:19:45]: In the elevator you said a co-founder makes sense if one person is the tech person and the other is the biz dev person. But you have to contain those multitudes yourself. How do you do it?Jake [01:19:58]: I try to get eight hours of sleep.Swyx [01:20:11]: Is there a balance: 50/50, 30/30/30? What’s the mental model as a solo founder?Jake [01:20:17]: There’s no balance. You have to think about all these things and be obsessed with them. Be obsessed with how people think about your product from a go-to-market perspective, and be obsessed with the kernel-level change that makes a user’s SSH connection never drop. I want a universe where you can snapshot everything and it feels like iterating on a VM.Jake [01:20:47]: You have to be obsessed at every layer of the stack. That’s what makes it easier for me. Some people are obsessed with different portions of the company journey, and if you can segment those lines well and be clear about ownership, you’ll have a good time.Jake [01:21:12]: I said two is the worst number of co-founders because you have no tiebreak. You disagree, and how do you resolve it?Swyx [01:21:38]: Usually someone is CEO, so they have the tiebreaker.Jake [01:21:43]: Totally. It’s hard every way you cut it. It’s hard if you get help, and it’s hard if you do it yourself. Running things is hard, but it’s so rewarding and fun.Swyx [01:21:56]: What have you found useful? A coach? Any advice that has been helpful?Jake [01:22:01]: I like to write a lot. I get in trouble a lot for my Twitter. I once said if you’re working weekends, you’re messing up your planning. I’ve gone back and forth on that because right now we’re at an extenuating time where it makes sense to work more. The goals are clear in my mind. If you have the vision and know where you’re going, work harder to distill that vision and do those things.Jake [01:22:33]: If you’re not certain and need clarity, disconnect and take your weekends seriously. Write about where you are, what you want to do, where you want to go, and what problems you’re solving.Jake [01:22:56]: Writing is important. I don’t love the word meditation, but whatever gets you into mental clarity is important when you’re trying to say, “We’re here and need to be here,” or “We’re here and I think we need to be in this general space for this to work.”Jake [01:23:22]: Disconnect, hang out with people you love, and work hard when you’re working. I try to work sunup to sundown, Monday to Friday, all out. I disconnect on Saturday and come back Sunday afternoon to write, plan the week, and do everything else. It works well for me.Jake [01:23:43]: Another hot take: most advice should be digested and thrown out the window. If it’s helpful, it’ll come back. You’ll learn it through experience. We have made failure very expensive as a society, and it makes it difficult for people to walk off the paths.GPUs, Focus, and the Dominant Role of AgentsSwyx [01:24:03]: Anything you haven’t tweeted and gotten in trouble with that you want to preview to the world?Jake [01:24:12]: The agent stuff is crazy. It’s going to be the dominant way people do pretty much everything, provided we can get the inference required for that to happen. Over the next 10 years, you’ll see a fundamental shift in how people think about authoring the logic in their head.Swyx [01:24:36]: One way of phrasing it is: if Allbirds can become a GPU provider, so can Railway.Jake [01:24:44]: I think there’s a lot of “everyone becomes a GPU provider” that is actually not becoming a GPU provider. You’re defined more by the things you don’t do than the things you do, because it’s easy to say yes to a lot of things.Jake [01:24:56]: Anthropic is amazing and moving into different zones. They’re moving into Figma-like things.Swyx [01:25:09]: As we’re recording, Mike Krieger was on Figma’s board, they removed him Monday, and then they launched this today.Jake [01:25:18]: Things move fast right now. But agents are going to be the way people operate.Swyx [01:25:25]: So your answer is focus: no GPUs for now, but never say never.Jake [01:25:27]: Focus. We will not do GPUs now, but we 100% will do GPUs at some point in the future. That’s not me leaking our roadmap because we don’t have plans to do GPUs. It’s just a function of needing FLOPS at some point. If you’re fully vertically integrated and want to make it trivial for people to iterate, build, and deploy, you need access to this core piece of fundamental logic.A New Cloud From First PrinciplesSwyx [01:25:57]: Presumably your own data center traffic is a minority of your workload right now, but is there a point where it’s a majority or you turn off public clouds?Jake [01:26:10]: At some point, we got to 100% data center: our own data centers. Right now, the vast majority of what exists on our platform is on our bare-metal data centers.Swyx [01:26:21]: So you’re already there.Jake [01:26:23]: Yeah. The transition was completed at some point, and then we grew so fast that we had to scale back on that. It got to 100% on the Datadog dashboard and then divoted back into the 90s because we were adding capacity.Swyx [01:26:45]: You’re literally building a new independent cloud, and people assume that could never happen post-AWS.Jake [01:26:53]: It’s hard. We’re going to figure out a bunch of things to make sure the platform is deeply reliable. But you have to break ground on new things when you decide to build a cloud from scratch but not copy the hyperscalers.Jake [01:27:10]: We’ve been deliberate about inventing our own infrastructure from scratch based on reading a ton of papers, while promising ourselves we wouldn’t copy someone else’s homework. If we copy someone else, we lose. You become them over time. You need a core thesis for why this business needs to exist now.Jake [01:27:33]: For us, the activation energy required to deploy something in production on hyperscalers is far too high. We believe it should be instantaneous. There should be no friction between your thought and the reality that comes out and that you can share with friends. 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.Jake [01:27:58]: It matters for giving people access to this tooling. It’s gated not just for citizen developers who are now vibe coding. You have multiple layers: citizen developer, front-end developer, back-end developer, DevOps person, and more. Those layers need to disappear so people can just ship.Swyx [01:28:20]: Amazing. That’s the future of cloud.Jake [01:28:22]: Awesome. Thanks for coming on. Thank you for having me. It’s been wonderful. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.latent.space/subscribe
Transcript
Discussion (0)
Hey, everyone. Welcome to the Latinspace podcast.
This is Alessio, funder Colonel Laps, and I'm joined by Swix, editor of Leland Space.
Hey, hey, hey, and today we're in the studio with Jay Cooper of Railway.
Conductor of Railway.
Conductor at Railway.
Yeah, yeah.
Too, too.
Do you actually have that, like, anywhere on like your business card?
Well, 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 super micro folks, and I was like, damn, that's
actually like, this is pretty official.
They're coming back.
Business cards?
Yeah, yeah, they're cool.
They're hip.
They're jig.
But yeah, the whole conductor thing, like we call someone for our volunteer moderators, conductors, you know, yeah.
So it's a good one. It's a good one. Like, we're trying to figure out what we want to call each other internally.
And there's varying levels of thought. Some people are like, oh, it's super crinch.
Like, just don't, like, you don't need a name for, like, you know, people internally.
And some people are like, oh, yeah, we want to call each other like this thing or whatever.
I was like, we still don't have a really good one, you know.
We've got like new rail recruits. We've got like trainiacs. We've got like, nothing's like really stuck.
I like trainiac.
I like trainiac.
Yeah. Brilliant.
Okay, so, well, for those who don't know, what is Railway,
let's give people a crisp definition up front.
Yeah, railway is the easiest way to ship anything.
You just go to the canvas or you talk with Claude,
and you say deploy Postgres instance, deploy my GitHub repository,
run this code, et cetera, right?
And it'll just be up and away to the races, right?
Yeah, you got a nice animation on the landing page.
Oh, well, thank you.
None of my work, by the way.
They don't let me touch any of the design stuff anymore.
But yeah, we want to make it trivial easy for not just to, like, deploy things,
but for you to almost evolve applications over time.
Like, we believe that most of the tooling right now is kind of like stacked up,
like you're stacking entropy on top of entropy on top of entropy, right?
So you have like Docker and Cube and then like Ancable scripts and all of these other things, right?
And if we can kind of like version all of your software for you and keep track of all the changes,
then we can make it actually trivial for you to clone environments, you know, fork into a parallel universe,
get copies of like production data, get copies of like any of your services, make those changes,
validate those changes, collapse it in without kind of having to just,
like reproduce everything across a, you know, a staging environment or all of those other things, right?
Yeah.
Amazing.
One thing I was looking at your background, right?
Like Bloomberg, Uber, there's nothing immediately that stands out to me as like,
okay, this guy's going to found like the next great platform is a service.
What prepared you for a real way?
It's almost like a curiosity to just like ever go deeper, right?
And so like, you know, started out on like front end stuff, you know, like working on the like
Wolfram like Web Mathematica and like porting it over there.
And then, you know, briefly moving.
to Bloomberg and then moving towards Uber and like distributed systems and kind of like taking all the jump bikes kind of systems and and moving them over to a distributed system built on top of cadence like the pre temporal.
Yeah, the pre temporal.
Temporal.
Which, by way, I'm happy to talk about pros and cons.
Yeah, I think like it's like it's my.
Let's do the roadway story.
And so like it's just been a continual step of like I want this experience whether it is like walking up to like a bike and just unlocking.
it and having it be like frictionless to like work or whatever and then like necessitating the like
depth required to go in and make that happen right like a lot of the work that that I do and a lot of
the team does is like it's all in the surface of that experience right and like we fundamentally don't
care like how deep we have to go whatever like we will swim to the bottom of the swimming pool to go
and get the experience right and I think that's what a lot of of you know kind of the trajectory was right
and so it's not like I have a physics PhD or whatever I did like an EECS degree you know it's just it's
always been about just trying to figure out that next step of like how do we get there, right?
And that's like what's led to, you know, starting railway for that experience and then like
moving all the way to bare metal data centers, right? Like, you know, I was adding patches to the
kernel this week, right? Just to like get the experience there because I'm like, see it and like how
much better it can be, right?
You have patches to the earnings colonel this week? Yeah, well, not upstream. That's our, our, our,
rail pack. No, this is different. This is the op-oos on top of real pack. Yeah, no, this is
like, this is that actual kernel like patches. But it's, it's always literally just,
what do we have to do to get that experience and just like figure it out, right?
Like anything is figure outable, right?
Like, you'll just figure it out, you know?
Would you send the patch upstream?
Or is it just because like it doesn't fit?
Maybe it's like we have to work out the experience for us.
Internally, it has to do a lot with the like storage layer that we're building for some of the agentic stuff.
So maybe it'll be useful to people upstream, but it's deeply useful for us internally.
I mean, you mentioned open source before.
kind of curious about how you think about starting from open source and then coding agents
to let you do a lot more from forks of it.
I think it's funny because I think GitHub's original sin is that it's like almost a series
of broken pointers.
It's like you have essentially this thing and then you clone it and then, okay, great,
like I've just lost that whole upstream, right?
How do we make it trivial for people to modify really, really small pieces of it?
Right.
And you think of Git almost in this like discrete sense of like, I've either made a change,
I've merged upstream or haven't, right?
What would it look like if it was like percentage-based or a little bit more nondeterministic or anything else like that?
More of like a stream of changes that you kind of like traversed as a user more as kind of like a percentage of this is rolled out in general and it's been ruled all the way up, right?
You know, we have the open source like kickback program and allowing you to deploy those templates because we almost want to make it trivial for people to like go and version these shards over time.
It solves like a really, really large problem in terms of authentication authorization, security, like, you know, NPA.
has that thing where you can almost define, hey, don't take any new packages or whatever.
Like, the ideal end state is actually like you should roll out progressively to the users who
have the minimum impact zone for any of these things and just continually roll up, right?
Like, J.P. Morgan or something else like that should probably be the last one on the patch line
for that, right? For all of our sakes, right? Like, because we have all of our, you know, money or
lively, all of those other things. It's okay if, like, Johnny Vibecoder gets like a broken patch
or something else like that
because ultimately
there's so much entropy in the system
that you do have to
you do have to roll
like Robert has to be rowed at some point
like you have to test
at varying levels right
so yeah
a little diversion from
wherever we started but you know
so I just wanted to like
pull up this glorious chart
you say
which is basically your usage
or number of
daily signups I think
daily signups
so you started six years ago
and
yeah
like a slow grind.
Slow grind.
And now, now obviously you're on a rocket ship.
You say, don't doubt your vibe and don't quit.
But, like, maybe if you want to pick out, like, certain points that were, like,
sort of key inflections to the company that might be fun.
Oh, yeah, yeah.
Well, I mean, at the start, it's basically, like, how do you get your first 100 users,
like, hell or high water, right?
And so, like, starting in, you know, we had a website and we had a support link.
And the support link was the Discord channel.
And you just showed up there.
And I had notifications on.
I had two monitors.
I had the monitor I was working on.
And then I had the other monitor.
And if anybody came in, I was.
like, oh, hey, how's it going?
And it was like super rare or whatever.
So trying to get those initial first hundred users to like actually kind of come back to it.
And that's, I think, where you can kind of like see the really like in between January
2021 and 2022, like probably the middle.
Like they're kind of right.
And that's like the start.
And then you ultimately end up building a consultancy factory of like users wanted all
of these things in general.
And so you kind of have to go back to the board a little bit and be like, well, what is
the actual product offering that I want to build on top of these?
And I think, like, incidentally, it's funny, like, I think VCs really want, like, charts that, like, always look like this or whatever, right?
But I think in reality, you actually don't want charts that look like that.
Most companies, I think, or at least for us, there's been periods of, like, expansion of, like, okay, we're going to go and add these features to, like, go into test these use cases.
And then there's been periods of, like, compaction where we're saying, like, okay, how do we have, if the experience we have is really, really good, how do we make it significantly better, right?
Like, maybe we're even stripping out features that don't, like, fit our ICP anymore.
Like, how do we go in and do that?
And I think throughout this whole chart, you can see a lot of those things.
Like, the boom in the, like, 2022 to 2023 is, like, we had a free tier and, like,
everybody under the sun was, like, using it and all of those other things.
A lot of Reddit bots and stuff.
Yeah, right.
And, like, I think there's a, there's a thing that's really, really tough to, like, teach people
or tell people about is, like, when you build an open product on the internet where anybody
can sign up, the internet is a horrible place that has, like, so many things, like,
Oh, yeah.
People have told you about my PCN.
Yeah.
Yeah.
And then crypto miners.
You got like all these other things, right?
And so you kind of go through these periods of like, well, how do I reach as many people as possible?
And then like how do I fit in exactly the use case for the people who are really, really going to matter?
And we're going to be really, really excited about specifically this thing, right?
And we go back and forth internally.
And then there's like a, what is that, a two-year period of like making the actual business work in general, right?
So like free to your era, losing.
I think half a million dollars a month.
And like, you know, we're making...
On like a 20 million bank account.
Yeah, yeah, and like a 20 million bank account with like, I don't know,
like maybe $50,000 a month in revenue or something else like that is horrible.
I don't know why I'm going to invest in.
But anyways, you have to kind of go through and be like, cool, like we have an experience
that people love in general, but like the business has to work, right?
And I think there's like, I guess, two schools of thoughts that you can continually run the
horrible business all the way up in general and have bad margins.
Or you can actually go back and kind of make it work, right?
And for us, you know, we've always really wanted to have like a super lean team, right?
So we're 35 people right now.
You know, it's very, very small.
We have like, what, three million.
Supporting two months?
Three million already?
Yeah, yeah.
Because we're adding like 100,000 users a week right now, right?
So it's like it's growing really fast, right?
But we've always wanted to have a really, really lean team.
Like we don't want to just like add headcount for the sake of head count.
Just like, throw bodies of these problems.
We want to build like systems, right?
And it's really, really hard to build systems when you're kind of 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, like, you know,
we're going to cut it for now.
Like, we can't support these, like,
these free users that like we want,
like we want to reach as many people as possible
because we believe that, you know, software
is this really, really important thing
where if you can kind of like create something,
it's become really difficult to create things in a 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's kind of like legs on that journey.
So we basically had to kind of close off the free kind of users for a little while,
rebuild the business,
make sure that it worked in general, right?
And then I think you can kind of like see the building of that in general, right?
And then I think you see kind of some divvits in those charts, right?
Like if you actually follow between, I think, 2025 and 20-26,
it's either summer or winter.
That's basically it, right?
Like, either people go on holidays with their family or they go on a holiday.
Oh, it affects that much.
Yeah.
Yeah, yeah.
Well, because it's like it's kind of B2C,
It's kind of B2B in general, right?
And so you have a lot of these users where, like, they're shipping constantly,
and then, you know, they'll kind of like stop or whatever, right?
And so maybe for summer or like maybe like our activation curve is like now we see a lot of people like activating in the weekday, right?
Because we have a lot more like business users in general.
So that gets a lot less sheer, so to speak, right?
And it kind of like smooths that over time, you know?
Yeah.
Is there any point at which you started prioritizing AI developments or agent development?
I think like we've, so we've prioritized almost like Agenic as like a top of funnel thing.
And probably over the last six months, we've probably deeply prioritized like Agenic as a mechanism to go and build and deploy things.
Just because we believe fundamentally like the curve is so sheer and like that is the way that people are going to go and build and deploy software.
And it almost like fundamentally doesn't matter if it's if like this is dot com or not because we're all on the internet now anyways.
right? And so if agents are going to go and deploy a bunch of things and we hit an inference
wall at some point, then like at some point we will go in and fix those problems. But like
that will be kind of the dominant species over the next like 10 years is we've moved from
assembly to C to C++ to JavaScript to now like words, right? And you're going to need to close that
loop, right? But that's that's where it goes, you know?
When you say this is dot com, do you mean like buying the domain or?
No, no, no, no. I mean like actually just like, you know, they had 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
kind of like bottlenecks, fundamental laws of physics, math didn't work, all of those other
things. And everybody kind of like, you know, went back down to the earth. Right. But at the
end of the day, it didn't matter because the internet is like so, so impactful for our lives
that if you operate on a long enough time horizon that you should be like you should just build
these things anyways because you can see where that's going. Right. And that's where I fundamentally
believe a lot of the agent stuff is. Right. And we can talk about a little bit of it later,
but you're going to get to a point
where you're running
thousands of these agents
like in parallel, right?
Like one, what's the inference cost
for that?
What's the compute cost?
How do you going to make that efficient
all of those other things?
But like two,
how do you coordinate all this stuff?
Like we have issues coordinating humans
in general, right?
We don't even good tooling for that.
And then we're starting to figure out,
like, how do you get agents to coordinate?
How do you go and get them to be able to like
safely version changes or like
for them to know when to like put their hand up
to get somebody to intervene, right?
Otherwise it just becomes like a interrupt
factory that's like crazy, you know?
Well, so maybe we'll go right on the technical side of things.
Yeah, yeah.
What are the core, like, infrastructure or architectural beliefs of your way that allow you
to do what you do?
Yeah.
I think the primitives matter a lot for us, like a lot.
We need to be able to do network, compute, and storage and orchestration all kind of
around it.
You kind of need control over a lot of those things.
Like, we've talked a lot about, like, how we don't really use Cube, like, Kubernetes,
because we want the higher order of control to be able to, like, go in
and place workloads in very, very specific places, right?
The reason for that is, like, you know, it's kind of the thing we talked about previously,
but, like, you have to be very, very efficient with these agents, like, memory reuse, all of those other things,
or you're going to massively, massively blow up your cost structure, right?
I think also, incidentally, being able to rack and stack your own servers and build your own metal,
it unlocks a level of, like, performance, one, but, like, two, costs where you can say,
oh, those experiences that you want to offer where you're running a thousand agents in parallel,
are not, like, massively cost prohibitive, right?
Because, like, if you look at just, like, token use right now
or compute use or anything else like that,
those things are blowing up massively, right?
Over time, those things are going to have to get a lot and a lot more efficient.
You can get a lot of almost, like, back of the napkin, balance sheet, margin,
whatever you want to call it, to kind of make those experiences, like, solid
by building your own metal, right?
And so kind of to the earlier point of, like,
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, like, humanly possible, you know?
Yeah.
You have a data center in Singapore.
Yeah.
So we have two in every other region now, Singapore.
We're adding a second one in Q3.
So, yep.
So, like, what's it like?
I mean, I've never built a data center.
Yeah, we'll have to, like, go to one or whatever.
Go to, like, Equinox and say, hey, I want some.
Yeah, so, yeah, so, yeah, I mean, I can run you.
Equinix.
Yeah.
Yeah, yeah.
Yeah, yeah.
I mean, you can put a, you can put a data center in the steam room.
We get nice and hot or whatever.
But, yeah.
Yeah, you basically just go and you say, hey, listen, I want power and I want a cage.
And they're like, great, here, this is what it's going to be.
And then you rent the cage for a period of time.
And then you have to fill the cage with racks, servers, and then hook up internet to it, right?
That's realistically all.
And then you handle everything else, right?
Yeah, you just handle everything else, right?
And like, what's the math versus obviously the clouds?
Yeah.
Our payback period, when we go to metal, if we rent it in the car,
cloud, our payback period is about three months. It's crazy. It's nuts. Yeah, and that's like
four years worth of like depreciated hardware, right? And so I think it's like you're going to see
a lot of this almost like compute crunch, so to speak, because a lot of the hyperscalers are
buying up a lot of stuff. Like we're working directly with OEMs and like resellers and like directly
with people who are like building these machines like Super Micro Dell, all of those other things
to go in and get these things working. But, you know, upstream there's like a bunch of supply stuff.
It was funny because when we raised our last round in between basically 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 what the value of the servers are because the servers have actually appreciated in value because RAM has gone up in general, right?
So it's kind of nuts just in terms of like how valuable hardware and all of this stuff is.
right? If you look at especially a lot of that, like, hypers like what, they deployed, like, $80 billion of, like, capital expense. Sure, it's like this year and, and, like, into next, it's going to be, like, more in general, right? There's a massive, massive scale, like, infrastructure build does. And you can't have that bad, like, wow, that's crazy. They're spending, like, way more than the Manhattan Project. But, like, again, if you go back to every person is going to run, you know, dozens, hundreds, whatever of agents in parallel, like, you should spend more than Manhattan projects. You have no, like, you have no conceptual idea of, like, how much.
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, and that doesn't even count inference.
How do you plan on the build out?
Like, I mean, the growth chart is so vertical that, like, you know, like, are you
usually 100% utilization rate as soon as you're live with these tracks?
So, like, how far ahead are you on?
Yeah, so, so, um, like, we still maintain, like, cloud presence for like bursting, essentially.
And so what we can do is, um, you know, we work with AWS and GCP and there a few
of those, you know, other clouds, like, we can just rent.
And then the moment we kind of get space or power or whatever, you almost just, like,
compact those off the cloud, right?
Like, we, because we started on the clouds and then we built a system to allow us to
migrate to our own metal.
And so there's nothing that says you can't just continually do that again, which is exactly
what we do right now, right?
And so we never want to be in a spot where essentially we are, you know, compute constrained,
right?
And at the start of the year, like, we actually got to a point where we were compute
constrained because the one upstream provider that we were actually working with wasn't able to give
us quota at the rate that we needed to. And the hardware was like slower, right? And so we had to do a
bunch of different stuff. I spent a weekend rebuilding our entire like network like overlay essentially
so that we could straddle five different clouds. Right. Yeah. Oracle, AWS, ourselves, GCP and like one other
one, right? And we can do more than that now, right? But, you know, we got into a spot where like we were just
trying to like pack instances tight because we couldn't get the amount of compute that we needed,
right? And it was really unfortunate because as a result, like some of a, we had a few like
reliability kind of things, which are now kind of past us, but it was all a result of this kind
of like, there was a tweet that I made where like, you know, I like gotten in trouble because
I was trying to point it out, but I actually caught this super base folks in the crossfire.
But like the tweet was about there's, 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, right?
And we got bit by it, which is, you know, fair and reasonable in the karma scheme of me, you know, trying to point it out.
So, yeah.
How do you think about pricing, knowing that you might not have Euro metal available at all time?
Like, are you pricing assuming that you'll need to, like, pay yourself extra margins if you had to end up going in the cloud?
Because we've built out our metal data centers, like, our margins on metal are, like, quite high for the, like, 70%.
And so we can actually deeply subsidize the cloud business if we want to scale at a reasonable rate.
And so we have a few different, like, it's actually very far.
from like an operations perspective because you have a few different levers on how you can go and scale it.
You have the metal which actually like makes your margins. You have the cloud burst, et cetera.
You have debt you can use to like buy servers in general.
So it's a very interesting like operational like problem to basically say like, okay, we have this much cash.
Oh, and then you've obviously venture capital that you can raise on top of it, right?
And so you have this much cash.
How much money should we raise?
How like how quickly can we go and deploy it, et cetera?
If we can scale revenues basically as quickly as we can scale compute, provided we continue to make it trivial easy for people to go and build and deploy in that.
Like, the faster you can close this loop and the more operational excellent you are with the capital, like, just the faster your business can, it's just a basically like straight linear kind of like deployment rate on some of that stuff, you know?
I think infra startups raising debt is a tool that people don't utilize enough or know enough about.
Oh, my God.
Yeah.
What can you tell us about that?
Yeah.
Is it secured against your GPUs or what?
Yeah, it's just secured against our like hardware.
Yeah.
What rates do you get?
Like, who are the lenders?
We just pay, like, prime at whatever it is.
Plus, like, we can refinance any of the debt as it goes down.
Like, the terms are pretty good from that perspective.
I think, like, the unfortunate thing is, like, Twitter has no nuance or whatever.
So they're like, venture debt bad or whatever.
It's like, well, no, like, as with all things.
It's not venture debt.
Yeah, yeah, or whatever.
Yeah, it's data standard debt, right?
But, like, yeah, I think there's specific tools and specific areas where you can be very, very deliberate about not just using
one specific tool as a hammer,
like venture capital is a hammer for everything.
You just have to kind of go out and explore it
and figure out how it kind of like works.
Yeah, VC is the most expensive financing you can get.
Yeah, yeah, yeah.
I think incidentally, I think also people think about VC
completely wrong from a raising capital perspective.
Okay, tell us how it's VC is wrong.
Yeah, well, I think most people are like,
okay, how do I raise as much money as possible from like
whoever is like probably the best that I can get at that point in time.
And I think that's like kind of close to right,
but I think what you should be doing or at least what we've tried to go in
to do is like try and figure out what almost unfair advantage you can buy with that equity
because it's the cheapest equity or it's the most expensive kind of equity you're going to give away
at that point in time assuming your company's going to get better and better and better and how do you
use that to like go in and work with somebody who is stellar and who's going to go in and compliment
you right like you know yeah like series A lucky yeah right like you know great i've never started a company
race race from lock he's got good advice i can text them all the time he's really fast etc
like awesome right then you kind of like move on and and you kind of like you know worked with uh
you know, John and Jordan at unusual, right?
And they were like, yeah, you roughly know what you're doing in building a product.
Like, we're just going to mostly, like, leave you alone and be totally available for advice.
Amazing.
Awesome.
Get to Series A.
Business is a total, you know, operational tire fire, right?
Because we just don't know how to scale a business, right?
Go and work with Erica.
And, you know, Jordan's over at Redpoint.
So bonus.
Like, you know, we get to work with them continually, right?
And then now moving into, like, you know, raised from TQ and FPV, like, we're moving into the enterprises now.
and like feeding into there, right?
So every step of the way, we've kind of moved towards like,
who can we partner at this specific time who's going to help us unlock that
section of the journey?
Because guess what?
I just,
I don't know enterprise sales.
I can roughly like eyeball it and be like, yeah, as an engineer,
I think these are the kind of features that we're going to roughly go in a need.
And we have some wonderful people who are going to help us internally.
But you really want to work with those people who are like at the boardroom dynamic
level are going to be like, oh, yeah, we're all aligned.
And that's obviously what we want to go in and do.
We can spend our time basically saying, how do we win this versus like bickering about
strategy, right?
No, I just had to pull up some beautiful data center charts.
Yeah.
I feel like you've done others.
I just couldn't find them.
Well, these are good.
I mean, like, they all kind of look the same.
Like, the server's in a rack.
Look at our box.
Yeah, exactly.
This is our box.
It's like, yeah.
It's like, yeah.
It's like, you know.
It's like, you want to see more racks.
It's like, you know.
I want the Jay Cooper signature edition.
Yeah, yeah.
We actually have, we have plans internally.
Yeah.
So it'll be fun.
We've got a few different promos that we're going to do in like stunts for the year.
So those will be fun.
Yeah.
You had a tweet about data centers in space just before we wrap this section.
Yes.
Why no data centers in space, man?
Why not data centers in space?
Okay.
So it's not no data centers in space because actually I think like my hot take is like,
I think this is solvable.
I've just never seen anybody solve it, right?
Because you need to like.
No, no, no.
You said how are you going to dissipate that much heat in a vacuum?
You're making a physics claim.
Yeah, yeah.
Well, because I haven't seen anybody like prove how you're going to go and dissipate that much heat in a vacuum, right?
Like, it doesn't mean that it's not possible.
It just means that, like, nobody's kind of put it up in.
Pardon?
Astrophage.
I don't know what that is.
The Martian thing.
Okay, you're very long time.
Yeah, yeah, that's fair.
But, yeah, I mean, it could work in general, right?
But I think a lot of people, and I think, incidentally, this is probably what you have to sort of do,
is like, they're putting almost the cart before the horse is 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?
It's like, you know, in the Martian where they're like, oh, how are we going to, like, intercept
Yeah, yeah, extrophage.
Oh, okay, right.
It's like, how are we going to do that?
It's like, well, we'll figure it out.
We have so however long to go in and figure that out, you know?
Yeah, yeah.
Yeah, making a bet on, like, human invention is weird because you just have to blind trust that it can be solved.
100%.
I feel like physics and there's like some first principles bounds that you can put on, like, maybe not.
Yeah, I know, right?
Like, maybe you're asking to travel time here or like, like, break some fundamental thermodynamic law.
Yeah.
And I don't know how VCs do this.
like incidentally too because it's like
how do you know what's like
basically not possible
and like is a grift versus like
is possible but like sounds
completely insane right and you're like oh cool like
we're going to put data centers in space it's like
okay coin flip as to whether
that's like one or the other you just don't know I guess
and I guess you'll know in like 10 years
cool that's fun cycle
okay okay yeah so
moving back to agents yeah I think
the branching that you do the fast
spin up and orchestration
It's kind of like the pre-work that happened to be exactly what agents want.
Yeah.
What do agents want differently than humans?
What do agents want differently than humans?
I think they want the ability to version thing.
So it's not like actually that different.
Like there's just almost like slight deviations in terms of how it kind of materializes.
So agents want a way to be able to go in and test changes incrementally, right?
Like we have feature flags as like engineers or whatever, right?
Like is there any reason?
why they can't just use feature flags, right?
I don't think so.
Like, I think there's ways that you can just go in and do that, right?
They want version control.
Is there ways we can use Git or not Git?
I think that one is, like, realistically, completely up in the air, right?
And I do think that something ultimately outside Git will emerge in terms of how we're going to go into version a lot of these things over time.
They need observability.
You need to be able to go in and essentially query what happened at what point in time, which steps failed, traces, logs, metrics, all of those other things.
They need like network compute and storage.
They need the ability to write files, save files, iterate on files, snapshots, file system,
all of those other things, right?
And so I think a lot of stuff that we roughly needed is like very, very kind of in line
with a lot of the stuff that agents also need, right?
And so like the branching and forking stuff, like it's not different.
Like we're just moving a thousand times quicker than when we used to.
And so some of these things like look like you really need like something massively,
massively different, but it's just you need something massively better than what
currently existed, right? You need orchestration. You need something massively better than
Q. Right. You need, like, networking. You need something probably better than Envoy, right?
Like, and it just goes all the way down the stack, essentially, in terms of, well, if the workload
profile doesn't change so much as it gets like massively, massively compressed because you need
to do thousands of these things, what assumptions change, right? Like, that CD is going to melt, right?
Like, you know, you need to replace it with something, right? And then I think you can go all the way
down the stack and basically say, okay, well, that part has to change, and that part has to change,
and that part has to change. And the interesting thing about the kind of like super exponential
curve is that you have to build your systems in such a way where you can rip out those parts
at any point in time because a new bottleneck might emerge because, you know, you start getting
really, really good at like parallel agents, right? And then that's kind of where the new model
that is, right? And that breaks a different part of your system, right? So I think it's very much
like similar kind of stuff that kind of like humans have needed. You just need it a thousand
is the next scale, right?
So, like, how do you do you do code review in the age of the agents, right?
I guess this is more of a question.
You throw more agents.
You don't.
Yeah, right?
But then, like, who reviews things for, like, CVEs and, like, all of those other things.
More agents.
Yeah, more agents.
Right, okay.
And then that's how we hit the inference wall at some point, right?
And you can continually throw agents and agents and agents at that problem, right?
But, like, you know, I think there's, I think there's a limit to, like, the amount of agents
you can kind of throw out a problem.
You started, though, you already had a CLI before it was cool, I guess.
CILAs have always been cool, by the way.
How is the shape of what you're exposing change, if at all?
Yeah, so I think the CLI changes because the way that we think about this is like,
how do you give Claude or Codex or chat or like whatever,
like any of these models almost like a handhold?
And like 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, you know, whatever, right?
Like, things that were prohibitively annoying to humans are not actually prohibitively
annoying to agents.
They're really, really nice, right?
And so 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.
Like, I'm never going to use all those things in general, right?
But you hand it to an agent and you say, hey, there's 40 arguments and 600 flags.
You'd be like, oh, yeah, this is excellent.
You know, like, I have so many handles that I can go in and kind of like work on with this, right?
And so I think incidentally, if you're going to go in and try and expose things for agents over that mechanism,
you want to just basically have as many handles as possible where they can get information,
query additional dynamic information, and then see how it can close that loop, like as quickly as possible.
Most of the kind of like problems right now are actually just how do you close loop as quickly as possible.
Where does the agent get stuck and how can you go and kind of remove that?
That's why incidentally, like, telemetry is very, very important because if you can tell where the agent gets stuck from the CLI and you say, hey, listen, like 12% of people are actually getting deviated from the happy path because of this thing.
And now I go and add this arc and that drives it down to 2%.
You've massively increased the rate of the loop closing for a lot of people in general, right?
So that's kind of the way that we think about not just the CLI, but every point in the dashboard, right?
Like, it is a user journey from, I hear about railway.
I go and get something deployed.
I get my first green build, whatever, aha moment.
I see an endpoint.
I see some logs.
I see whatever.
And then I go in an iterate, right?
And then I go in an iterate loop is indefinite and infinite until the end of time.
Right.
It's basic like, user wants to deploy new thing.
User wants to deploy new Postgres instances.
User wants to change their code.
User wants to iterate all over time, right?
And so if you just focus on a lot of those iteration loops and figuring out
what's blocking that loop from closing as quickly as possible.
Like one of the things we talk about internally is you never,
ever, ever want to be waiting on compute anymore.
You always want to be waiting on intelligence, right?
And if you're waiting on compute,
there's a bottleneck that needs to be destroyed there
because at some point that bottleneck will be so, so, so large
that some other workflow will kind of emerge to go in and change a lot of that stuff.
And I think incidentally, like, you know,
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?
like push, pull, whatever kind of like loop,
I just fundamentally believe it's going to go away, right?
Like, we're going to get to a point where you make a small change in production,
that changes version across your entire kind of infrastructure,
you're working alongside, you know, copy and write versions of your database,
all of your infrastructure, and then you merge it in and instantaneously,
it's like live, right?
Because that's like the holy grail of loops, right?
But that like push pull rebuild thing, right,
is a point of friction that we're like removing entirely from our loops.
Yeah, it's incredibly fast.
So if anyone hasn't tried it, that fast feedback is great.
You know, my hot take is that, you know, Railway was kind of famous for its canvas,
which sort of visualizes your infrastructure unless you manipulate it visually.
But that was for humans.
Yeah.
And actually now for the next phase in growth, like Railway, CLI is more important than Canvas,
which is what you were famous for.
Yeah.
So I think the Canvas is funny because, like, it's actually just a mechanism to show you changes over time.
but I think you're totally right in the sense that like
we have 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 you'd make some changes
and all these other things, whatever, right?
And you see them and, you know, your agents
or your infrastructure would evolve over time, right?
Now you just have a bunch of agents that like
they have access to CLI and they can go in and make those changes
in general, right?
And so the canvas actually, instead of becoming this like input thing,
we're like, oh, cool, like how do I go in and make this happen?
It's actually just more of an output thing.
It basically says what information.
Yeah, what information does the human need at this point in time to make suitable decisions about control requests of do I approve this, do I not approve this, right?
Like, that's realistically all the canvas becomes at that point in general, right?
And also a way, and I think this is important and I think this is lost on a lot of people who are like building some of these like canvas experiences.
It has to be almost like an anchor for your context.
It has to be like a port in the storm.
It has to be like, you have to think basically about it as like layers and like a file system almost to like get to the next spot, right?
And so you have all your infrastructure and like this is why the canvas starts is like, it's just a project, right?
And then you have a drill down chart, right?
Like it's like I'm breaking down into these services or this like section that just is like a function or code or anything else like that because 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 so that they can move
as quickly, right? I think a lot of orgs, especially as they scale, they get in trouble because
all that context lives in somebody's head, basically. And it's like, oh, how does this microservice
work? It's like, I have no idea. Go ask this specific person, right? And then you have entire categories
and classes of products that are built around, like, how do you do context discovery at all
these things? And I think a lot of that stuff gets just because melted in terms of if you can have
a really, really solid hierarchy and you can infinite nest services, infinite less,
nest code, infinite less context, infinitely nest all these things all the way down.
That's what allows you to kind of build these kind of like structures up over time, you know?
And I think it's also what's going to allow us to like build.
I've written a bit about this like these like hyperstructures, like things that are way, way bigger.
And like, you know, you look at the Golden Gate Bridge and you like how, how do we build that?
Like, you know, there's that whole meme of like, oh, how do we build this?
Like, we lost the technology or whatever.
We don't know how anymore.
Right.
It's like, well, yeah, I mean, to some extent, yes.
because a lot of the coordination that we,
that built those things, like, has evolved, right?
And, like, has changed.
And there's new thing that we've lost almost, like,
some of the art of, like, building that structure
as we've just, like, jammed everything into Slack, right?
And we're just like, everything happens to Slack.
But you don't have anything in Discord.
So, yeah, yeah.
It's the same point.
It doesn't really matter.
It's just, like, message passing and interrupts,
message passing and interrupts, right?
So you're arguing that there should be something better, more structured?
Than Slack?
Yeah.
Yeah.
Okay, for sure.
I think Slack, and incidentally, I think Discord is awful too.
This is the equivalent of my mom test, right?
Like, what have you done that has your solution to this?
So internally, we built a tool called Central Station that allows us to go in and aggregate
all the context from all of our users.
So every piece of feedback, every piece of customer support, every single thing like that,
gets aggregated into what we call like clusters.
If you have an incident brewing or like anything else like that,
now we can go and determine how many users are affected, all of those other things,
etc. And then we can actually break off a discussion based on that. And I think a lot of that is actually
a lot more helpful and more correct in terms of instead of like having just these like long running
channels where you're just like which channel should I put this thing in, right? Like if you can dynamically
aggregate that information and dynamically route it to the right person based on the context,
right? We know we know internally like these four people are pretty close on networking, right? And so
if we see like, okay, we've got a networking thing, you can roughly like drill it down to like those four
people, right? And if you're saying like, oh, okay, cool, it's actually with this part,
you can just go and like look at the commits, right? And this is like no longer a manual
process internally. Like this is the whole point of why we built, if you go to like station
or help.ruly.com, there's a whole reason we built this thing, right? It's because we wanted to
figure out how we're going to go in and scale with like a massive, massive, massive amount of
leverage to go and aggregate all this feedback, you know?
This is built in-house? Yep. Okay. So, and then I remember helping out on this one with
Angelo in 2023. Yeah. Yeah.
you scale a lot with a very small team.
Yeah.
Yeah.
So we're like 10 times bigger now.
Oh my God.
You have your full developer count here?
Yeah.
Okay.
All right.
Yeah.
If you go to,
if you go to,
I can just like cron this
and then just have your life.
Well, you don't even have to cron it.
We suppose this is like a pub subable thing.
So go to railway.
So go to real time metrics for all of this stuff.
There's a way to get this as like a JSON too somewhere.
If you care or anything else like that.
We'll look it up.
Yeah.
But yeah, yeah.
We're big on like trying to build everything in public.
about a lot of stuff we're working on.
You know, like, we've had some issues or whatever in the past.
And we're like, hey, cool.
Like, here's how we're fixing these things.
Like, we've, you know, we've got both compliments as well as some flack for incident
reports and, like, always trying to, like, make them better over time just to, like,
talk with people, right?
Yeah.
Yeah.
Any, obviously, you had a big one recently.
I like that it was only scope to 3000.
You use, presumably use Central Station, like, any talk, talking through, like, what happens?
and I guess how do you address it, you know, internally as a team?
Yeah, so internally as a team, this one, like, really, really sucked.
You know, it was, like, to do with an upstream provider that didn't, they didn't do the behavior that they said they were documenting,
which is unfortunate given they, they, like, wrote the RFC on how the behavior should work.
But we rolled those things out, and then Central Station kind of caught that initially,
where we had a couple users being, like, oh, like, the caches aren't invalidating for some of this stuff.
right. And so turn it off immediately, et cetera, right? But when you go and kind of roll out to
those like that like large user base of like three million people, right? You know, like you have a
lot of different disparate behaviors that can kind of come up. Right. And so try as we will,
we tested those things in, you know, staging. We have tests for them, like all of this other stuff.
You know, and unfortunately we like hit kind of an edge case there, right? And we've incidentally
like 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.
Yeah, I always wonder how, like, the private disclosures is supposed to work.
If people find an issue, are they supposed to contact you first?
Like, when you run a platform, these things are going to happen.
Yeah.
And what channels should people pursue to, like, you know, quietly resolve it before it becomes, like, a much bigger incident?
Yeah, so I think there's, like, there's responsible disclosure.
We kind of err on the side of like, we'd rather over disclose and know that you know that something is wrong versus almost like having your provider gaslight you.
And so, yeah, you know, we've kind of we've aired on the side of like sharing those things kind of more publicly, even if they go in an impact a small subset of those users, right?
And that's kind of just a decision that we've made internally.
It's under like, we have four values.
One of them is honor.
And so like what's the honorable thing to go in and do?
It's like, well, you notify people, you know, to the widest degree in which they may have been, you know, affected or there was an issue or whatever.
And then we kind of confront that head on and be like, why did that happen?
What can we do better in the future?
All of those things kind of like that, you know?
So.
Yeah.
Not the whole user base.
No.
And that's because of like incremental rollouts and progressive rollouts and stuff like that, right?
So, yeah.
Interesting.
Yeah, yeah.
I feel like that should just be the norm at all large platforms, right?
Oh, it totally should.
And a variety.
Which you did this.
Yeah, and a variety of companies it totally is, right?
Like what, there's a whole quote of like meta runs like 10,000 versions of different versions of meta in general.
And like to our earlier point about agents, right?
Like they need the same thing.
They need to build the shadow traffic.
They need to build all these other things.
I think we've built so much ceremony around like production is sacred, all of these other things that like we need to get to a point where it's just trivially easy to test different behaviors, right, in a safe environment.
Because then you can make those mistakes in an environment that's like safe in general, right?
You mentioned somebody brought it up.
Do you see a world in which these things get automatically caught?
Not necessarily by your agent, but like your customer agent.
You know what I mean?
The cash and validation thing seems like a pretty easy thing to check if you know to look for it.
It's hard because then you almost need, well, for us to like determine it, like we need almost,
we'd have to hook in with like your observability infrastructure in general, right?
This is like why we almost have the template loop on the platform is to be able to kind of roll those things out
progressively where you say, hey, listen, you know, I can roll this out to like Johnny VibeCoder
initially, right? Or I can push a shard and you can almost like consume that at your own leisure and be like,
oh, okay, I'm going to update to this specific version, right? Or have this kind of like roll out over
a period of weeks where you're pushing a new version and then it goes to, you know, 0.1% of people,
1% of people early dot, like whatever and then rolls out all the way there, right? That's the kind of
like non-deterministic version control that we've kind of like talked about earlier. So yeah, 100%
And I do believe that that's where most things should go towards because I think ultimately most companies end up building that stage rollout system in house, right?
And it's just the same thing built again and again and again at every single one of these different companies.
So there's a massive opportunity to consolidate a lot of like developers' stack.
You should have a free tier.
Like the model providers give you free tokens if you let them use the data.
Like we'll give you free compute if you're like the number one chart that goes out and you let us plug into your observability.
Yeah.
Like incidentally we do that, right?
And that's why the, you know, we talked about, you know, the impact of that on like 3,000 people or whatever.
We start with the kind of lower impact.
Like the, you know, larger companies, et cetera, on the platform, right?
Like, they're the last, ultimately, that should receive those kind of rollouts so that they have a version of the platform that's, like, deeply, deeply stable, right?
I have three services, so I'm sure I get the first.
You can nuke.
You can nuke my thing at any time, man.
I guess my other question is, like, there's all this, like, SRE agent.
companies, there's like the observability people also want to have agents that fix your
upstream problems.
How do you kind of, you have your own agent in the canvas now that you can chat with?
How do you kind of see that play out?
It's almost like the stacking entropy thing in general, right?
Like, I think if you don't have the primitives to make iterating in production safe,
it becomes very, very difficult, right?
And so if you're an observability provider and you're like, oh, here's this fix to this,
this error, right?
like assume like 80% of those they're probably actually good like they're going to make they're
going to make sense et cetera right but then the last like 20% of that long tail of like kind of complex
issues in general ultimately rolling those changes out if you just kind of let somebody say like
oh cool this looks good and just like stamps it there's an opportunity for you to have an issue
or an incident or anything else like that and i think that's why it's really really important
to have those kind of like forked environments in general and people have staging etc but
it always ends up ends up like deviating from prod right and so you need
the primitives and the workflows and the experience like built in our in our mind on like as a first
party thing on the platform so you can fork any point at any service at any point in time so that
you can almost like you know I think I consider the canvas almost as like a little like sheet
of transparency paper and the agent is kind of like this little guy that you push up and it's like
should be able to like pop up in the canvas and then it should be like oh cool like well I need to
copy that service I need to copy that service so I can test these two things right that's my hypothesis as
like an agent or whatever um okay cool I
can go in and do that.
Looks good for all this stuff.
Ideally, I get a read-only copy of production.
Anything that's PIA, et cetera, is kind of like marked as like a transform when we automatically
clone that database or go for a copy on right version of it or read from it.
And it just makes those changes.
It says, does this actually work, right?
Like as close to production as possible, right?
Because ultimately, that's how close you have to be or you just have a massive amount
of drift where, oh, I've changed this thing and then it just kind of gets out of sort,
that the system gets a lot more unstable.
And I think that that's like what you see with a lot of these kind of almost massive systems that these companies built on top of like Docker for local and then like Cube for production and like this specific thing for whatever.
Right.
It's like all of that complexity ends up getting to a point where it slows down the developers, yes, but it just it just gets to a point where it's so unstable at scale that it becomes hard for people to go and iterate and make those changes.
Right.
And so we want to compress a lot of that stuff way down and just say like as like as close to prod as you could possibly be.
That's where we want to be.
I was texting Erica for for questions.
And she says actually you were originally not a believer in AISRE.
Oh, yeah, yeah.
I mean, I've kind of.
Have you come around on it?
Yeah.
Well, I flipped.
I'm actually still not a believer on the AIRSRE because I believe that you need you need the primitives to make those things safe.
And if you just unleash an AISRE on your production.
infrastructure and you don't have like safe
permittives for like copying volumes
making sure that this is fine,
it's going to nuke your production database.
Like 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 kind of like loop safe in general.
I think I was a pretty deep like almost,
I don't want to say AI skeptic until like 2023 and then
2024 I've kind of like,
I was like, okay,
like maybe I can make this thing roughly do it, et cetera.
2025, I was like, okay, now I can
like hold this, et cetera. And then like
over the whole Christmas break, I think you just
saw like, I guess winter break. But you just
massive, like everybody came back and like,
oh my God, it's almost impossible to hold it.
Seriously, you on the cloud docks? Yeah.
Cloud bot, well, open cloud.
But it's gotten to a point where it's almost like
it's harder to hold it wrong than it
it is to hold it right, you know?
And it's like, you know, there's that scene
in like Avengers or whatever where Vision's
like it's terribly well balanced, you know?
Like when he picks up Thor's hammer or whatever, like
you're like, damn.
Like this thing just kind of like self-balances and like works quite well from that perspective.
So yeah, I'm a deep believer at this point in terms of that will be the dominant species.
Right.
Again, you know, assembly C++ JavaScript words, right?
Yeah, it feels like a big jump.
Yeah, it feels like a big jump.
And it is too, right?
And I think like there's, it's not like you abandon like CPU-based discrete logic in general and just move straight to fuzzy logic.
You need both, right?
So your skills should call code or applications or like whatever, some sort of like static structure.
And you can use the skills to kind of distill what the almost like procedure should be or like how the code should act.
Right. I'm kind of coming to this thesis, which is you need three points essentially, which is you need a clear spec of what defines the system.
You need the code and then you need the tests, right?
And I think when you say this thesis out loud, it's like, well, if you've been in engineering for any amount of time, you're like, well, no.
Like, yeah, of course, you, like that's a RFC, like a request for comment.
That's tests and that's your code, right?
But they all matter a lot and having them all be actually together so that they can reinforce
each other and say, well, the spec and the test match, but the code doesn't.
Let me reconcile them.
Oh, okay.
Now the tests and the spec match, let me go and reconcile this other thing, right?
And you can kind of move through that period of basically saying, well, this is fuzzy,
and these two are either discreet in the case of tests or slightly fuzzy, slightly discreet.
slightly discrete in case of code, right?
And that's kind of your iteration loop.
I think that's also incidentally
where you're seeing a lot of people be like
software factories and I want to write this dock
and like how I go and reconcile
all this other stuff, which I think is a bit of
architectural astronomy if you like
don't actually go in and implement it.
But I do think generally that's kind of
that loop is kind of where
most things are going to ultimately end up.
Yeah. For listeners, we've been talking about this
on the pod for three years. The Holy Trinity
of specs and tests.
Oh, okay.
I'm R. Freeman from Cotto is
the reference for people who want to look at it.
Nice.
One thing I do want to mention just on the open claw thing is also like 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 open claw and I just tell it that it has the railway CLI, can do whatever.
And in theory, you can just whatever capabilities and new infra you need, you can just call the railway CLI, provision it and add it to itself.
And so the agent can like modify its own infra, 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.
And so you're essentially authenticated as whatever the current box is in general.
And you can make any sort of changes to it.
And then you just call railway deploy and it deploys itself.
Right.
Like 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 postgres instance now.
Right.
And this is kind of where we want to go with a lot of the, like, agentic, almost like, self-replication.
infrastructure is like that's your loop.
Like you iterate in production.
That's your loop, right?
You're going to just continue to make some sort of change and either it will work and you're
going to want to go and merge it and say, cool, that's great, like put it into our upstream
or it will not work and you can just kind of throw it away, et cetera.
How do you go and make those throw away copies like as trivial as possible to spin up, run super
cheap, et cetera?
I think the era of like I have an AWS instance and I'm going to, you know, get four VCPU
and 16 gigs of RAM.
it's going to get completely destroyed, right?
Because it's like, if you do that for agents or anything else like that,
you now need a thousand of those machines, right?
Like it's so prohibitively cost-comensive versus, like, you know,
we've spent a ton of time trying to figure out how do we go in and make these
deployes, whatever you want to call them, you know,
CloudSv got the like icelets, everybody's like called Spanbox,
like whatever.
Like that atomic unit of deploy, like only pay for what you use,
spin up instantaneously, close loop as quickly as possible.
Right.
Because if the system can self-replicate the system and it can do so safely and say, this is my environment, I'm making these changes, et cetera, it can come back with, hey, does this look good?
Like, this is a new state of infrastructure given this prompt.
I think I've solved this problem, right?
And then you can go back to the agent and say, actually, like, looks a little bit different, goes and does the loop again, and you're like, cool, excellent.
Apply.
Yeah.
I think that's retroactively obvious.
Retroactively obvious.
kind of like the most useful kind.
I don't know, any other comments on like just agent deployment on Railway?
No, I mean, it's getting better every day.
And, you know, I'm on X or Twitter or whatever you want to call it.
And like, you can always, you know, yell at me about the experience not working as well as it should
because there's plenty of things that should work way, way better.
I was going to say, I think at this, right under this stage in a juncture,
when people want, like, the massively or embarrassingly parallel compute, they usually talk serverless.
And I feel like there's a new serverless that has emerged compared to the last, the previous five years of serverless.
You're kind of like in that new bucket.
I don't know if you have like comparisons or philosophical differences that you want to call out.
No, I think it's like it's as you kind of mentioned, it's somewhere in between, right?
It's like the ability to run stateful, long running, like you want to call them workflows, you want to call them executions, you want to call them whatever.
which like Vrcel has fluid compute and then Cloudflare has some container thing.
Yeah.
Google has always had the app runner.
App runner and the new one.
Yeah.
I forget a bunch of them.
Yeah.
Yeah.
I think like that's kind of where everything roughly and this is why we've been working on it for
the last like six years.
It's like we just believe like you do need access to a computer.
Like a box that speaks Linux, right?
So that you can deploy the things that you want to go.
to deploy on it, right?
Like other things are going to, I mean, they're going to change the almost like surface area
of what you can kind of go in and build.
And for us, we're always like, no, like users need a computer and they need to be able
to deploy anything that they truly want, right?
And that's why we focused on long time, for a long time on those primitives, right, of like
network, compute and storage, right?
Because if we can give you those things and we can expose them to you and allow you to
run these things indefinitely, right?
that's of course, like, where we believe that it's going to go in general, right?
And so I think you're seeing right now where, again, the whole like Twitter has no nuance
where everybody's like, servers, right?
It's servers.
It's like, no, it's like it's always, it's always somewhere in the middle, you know?
Like, it's always some sort of convergence of, well, I want to rent for a long time,
but also I don't want to like provision this resource statically or pay for just things
that I'm not using or anything else like that.
And that's always been our thesis from like day one.
It's like, pay only for what you use, run it indefinitely.
It is just like full Linux, basically.
Yeah, yeah.
I think that's why I like them for cell naming of fluid.
It's like, it's well, it's fluid.
It's flexible.
Another milestone.
And then I wanted to ask one more technical question,
which is the Heroku official deprecation.
What did they, basically, you know, you're one of the presumptive new Heroku's.
New Heroku has been a category for like as long as I've been in developer tooling.
Yeah, right.
It's finally happening.
Yeah.
What was that like when, you know,
is there any behind the scenes of like, well, this is the moment.
Yeah, I mean, you just have, you have so many people just like,
you're just like, like you were running stuff on here?
Like you as this company, like, it's crazy that like you, whatever,
like name that you would know is running this thing.
And then you're coming to us to be like, yeah,
we kind of like want to like move a lot of the stuff off or whatever.
I'm like, oh, okay, cool.
But yeah, it's kind of just nuts.
Like, I think.
And either behind the scenes, what is, what, why does Salesforce let Heroku kind of just stagnate?
Well, I mean, I can only like, guess, I guess, right?
Like, I mean, I think it's just hard when, like, it's not your business.
Like, the business of Salesforce is to build a really, really good CRM, you know, right?
And, like, that's their focus, right?
They should be really, really, really focused on building a really, really great CRM.
And then you acquire this business as a compute business that's kind of an offshoot of your business in general, right?
And I think, like, you know, a lot of the early meta folks have talked a lot about, like, focus, right?
And like I think Boss has a whole like write up that he's done basically where he talks about in the early days of meta, we had no money and like we were forced to get focused.
Right.
And then we basically turned on the money.
This is all like, you know, me verbatim.
Refrasing.
Yeah.
We turned on the money tree and then we had no reason to like not like have focus because we just had infinite money where we could go and split all of our focus.
Right.
But that ends up diluting your product.
It ends up like making these things where you kind of have these offshoots where you're just like, is that the focus of the business, right?
and it ultimately ends up not being
if it's not the core of your business, right?
And so to me, it's like kind of no wonder
that like it languished in general, right?
Because it just wasn't the core focus of the business.
And I think that a lot of companies get in trouble
with this when they kind of like split out their focus in general
because it means that you're almost like fighting a like multi-fronted war
trying to like compete with all these things
and not just like compete with them externally,
but compete with them internally for like alignment
and like where are we going?
what are we doing? What is our purpose here?
Right? Like if you're, you know, if you're really, really, you know, like Salesforce built and you're like, hey, listen, I love Salesforce.
And I really want to like work on all those things. Like, you know, and your mission driven, which is like the aspiration for a company in general of like why do people work on things, right?
It's like they want to work on something interesting, right? Like Heroku is off to the side.
Yeah. It's like it's not the core of the business. Right. And so to get those resourcing, you know, like budget or focus or alignment or whatever.
internally, it's just pushed away, right?
So it was literally just a matter of time for it to happen in our mind, right?
Yeah, and then kudos for them to, like, actually call it out instead of just letting it be unknown or hanging in here.
Yeah, well, their whole release was a little bit odd because they like, you know, they kind of called it out.
They did the Our Incredible Journey.
Yeah.
They didn't say they were like shutting it down, but they're like, yeah.
Yeah, yeah.
And then, you know, behind the scenes, I think they issued some stuff to people being like, hey, yeah, you should like close these.
accounts down, like, we are going to go and defigate this and, like, remove it every time.
So, yeah, I mean, it's just like, and it's crazy because, like, some of my first
deployment experiences were, like, on Heroku.
I learned to, yeah, I learned to code on Heroku, man.
It's, like, a foundational thing where it's like...
I had a freaking alias in my bash for, like, Heroku deployment.
Yeah, right?
Like, you start with, like, dragging stuff into an FTP server, and then, like, you move
on to, like, trying to get a deploy working, like, how do I go in and make this happen?
And it's like, Heroku, right?
Did you know about Heroku packs and all those things?
Yeah, exactly, right?
And you learn about all this, and it was the on-ramp for us, right?
You know, but the wheel turns regardless, right?
Like, there's new stuff that's emerging.
And, like, we're very, very happy to, like, almost, like, continue to, like, you know,
carry the torch on 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, right?
Yeah.
I mean, it's a big crown to be a new Heroku.
Like, there's, like, 50 companies that fought for this.
Oh, yeah.
Everybody's kind of, like, you know, holding some portion of this being like, ah, you know.
But yeah, I think, you know, for us, we're just happy to go in and support people, companies, et cetera.
The platform works a bit differently.
So it's like, you know, it's obviously kind of almost the similar kind of like game loop.
Yeah, exactly, right.
But we've been quite dogmatic in terms of where we believe these things are going to go in terms of primitives, you know, the agents kind of fan off, all of those other things, right?
And so some things will fit.
And then some things will, you know, you have to change a few of their workloads, et cetera.
Like we don't have a, and what's that feature that people are?
really love pipelines.
Heroku?
Yeah, right?
Like, we have some approximation of it with the environment system in general, right?
But yeah, so it's been super exciting.
We've got a ton of people that were able to go in support.
And it's growing a lot.
Yeah.
Any other technical?
I have one more.
Temporal.
Okay, so, Temporal.
I have sold my shares.
You are a power user.
You're one of our earliest customers.
I met you through Temporal or something.
You're a big temporal business.
like you build on temporal, you have complaints.
I think this is the neutral, most neutral, most informed are conversation that anyone will
ever hear about temporal without someone working at the company.
Yeah, that's fair.
Yeah, yeah.
No, I think that's fair.
Yeah, so I have used temporal for almost like 10 years now, right?
Because like Cadence Uber, all of us, other things like that.
Just give people a scale of what cadence is at Uber.
Like people don't know.
Yeah, so Cadence with.
is the precursor to temporal, and it powers like all of the trip actions, the rides, the like, you know, when you, do you like rent a jump bike or scooter or like anything else like that or a car? It's like, you're running these workloads for a period of time. And you're basically saying this ride will run for an indefinite period until it like finishes, right? And you can go and attach information, whether it's like, oh, you paused it in this zone. And so, you know, you need to add this dollar charge to like the bill or anything else like that. And then when you and the trip, like your workflow is done. Right. That whole experience, uh,
behind the scenes.
I don't know about today in general,
but it was powered by,
by Cadence at that point in time.
And so it's a really, really, like...
Yeah, and I used to say,
like, it's like,
imagine if you could program
the entire user journey top down as one function.
Yeah.
Yeah, yeah.
And it's such a powerful idea,
and it's so, so important.
It's also incidentally so important
for the next phase of the agentic journey
where, like,
you want an agent to do a specific task,
and then you want it to, like,
be complete or incomplete on that task,
and then move on to the next thing, right?
Like you need a way to be able to go in and manage these workflows.
You need a way to be able to go and manage these workflows dynamically.
And I think for me, temporal was always like really, 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 it required you to like model that entire journey in your head.
And if you didn't have the entire journey in your head, you could put yourself into a spot where you would cause like issues where like replaying the state of the entire workflow like causes like a non-determinism issue.
Yeah, because it works on like deterministic workflow.
history.
Yeah, exactly, right?
And so it's very, very easy.
It's like, the way that I kind of like would describe it is like, well, it's a jet engine, right?
Like if you know how to like go in and operate, if you know how to go in and run it, all
of those other things, right?
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 kind of like state in their head, right?
So if you have a large, like we run our whole deployment pipeline on top of it, right?
And so that's like a reasonably complicated workflow, right?
like there's pre-commit hooks,
there's like signaling, there's queuing,
there's like all of this other stuff in general, right?
And we kind of ran into the same thing at Uber
where like as you tried to express this large workflow,
as you mentioned, like going all the way down,
got more and more complicated
and it got more and more states in the state machine
that you had to like map the state machine back to like the workflow.
It's a lot of if, right?
Yeah, exactly.
If this, if that.
Yeah.
And so at Uber we built a system for, you know,
doing the state machine
and like testing the state machine
and all the other stuff.
And we've started to like go and build some of those things here
because it's grown, you know, quite heavily, right?
But it's like, it's such a like, you know, I don't say love-hate relationship because that's, like, too broad in general.
Like, it's, when it works really, really well, it works like super, super well, right?
But then you run into a spot where you just like, somebody who hasn't interacted with the system
or doesn't have the full context of the system goes and put something in the system that invalidates some of the state
or causes a non-determin issue, it's nondeterminism issue, or spins off a ton of activities or anything else like that.
And then you have to kind of keep track of like almost underlying SRE knobs of like, oh, we have, you know, the amount of activity slots in this thing, right?
It's like, well, these should just scale with like memory, VCPU, all of those other things in general, right?
So it ends up becoming a bit of a bear to kind of scale out in general.
Yeah, so you need like a very capable system in running things behind the scenes for you.
Yeah, yeah.
If you were to move off, what would you do?
I think we would build our own workflow engine.
We have a few internally that we've kind of like worked on.
So, yeah, because it's like, yeah.
This is one of those things where, like, you know,
there's one of those classes of things where, like, you typically wouldn't vibe code it.
But I'm wondering if you can.
Well, I don't think you should vibe code it still.
Like, you still want to run, like, depths and tests and stuff like that, like you.
I mean, you know, like, it's not like to throw had to invent that from scratch either, right?
No.
So, like, there's libraries for those things.
Yeah.
That you can, that you can run.
And, like, on top of that, it's just a state machine and, you know, that you have to really map out.
ultimately you define those
instructions that you want
and you run into a state machine
and that's it.
Yeah.
Yeah, it's very, very doable.
So, yeah, I think the workflow
stuff is very, very interesting.
Like, there's a few really cool companies
that I think like restates
doing some neat stuff here.
So you're very tied into JavaScript.
You're like a JavaScript maxi.
Internally, we have JavaScript,
we have, or we have TypeScript,
we have Rust and we have Go.
Those are three languages, right?
We don't add any more stuff.
Actually, that's not true.
We have a little bit of C
because we write BPF code
and like,
and its hooks and stuff like that.
So, but those are, those are the, the kind of,
is this for this, like the side container things, side car stuff?
No, well, so this is for the networking stack,
as well as the volumes and stuff like that.
So, yeah, but it's like, yeah, we used, like, the TypeScript stuff a lot
because it's like what powers the dashboard,
but we're going to move a lot of the kind of workflow stuff
off of the kind of dashboard stack into actually the infrastructure stack.
we're just recently.
Yeah, don't power things on front end guys.
Even though it's free compute.
Yep.
Yeah, yeah.
Cool.
Any other technical infrastructure, cool stuff?
Rail packs?
I don't know if that's still...
Yeah, I mean, we built an engine for determining dependencies based on your source code, which is super cool.
It's called Railpack.
We built the first version called Nix packs, which is on top of Nix.
And then, yeah, we moved.
People have been trying to get me to adopt Nix and Nix OS for like four years.
Yeah.
Is it ever going to be a thing?
I don't.
I don't know.
Like, we were super excited about it in general, but it's like it has a bunch of different
kind of pain points in general.
Because if you just think of it, it's like it's a stack of version source code at,
or it's a stack of version binary at specific slices in time, right?
And so if you want version X and version Y, you end up bloating a lot of your kind of like package,
like space, right?
Which blows up the size of your images and it makes it really, really difficult.
for like really real world workloads.
I think if you...
But you know, you content address it and you cache it,
it's, you know, there's a lot of optimizations
that in theory you should be able to do.
In theory, yes, right?
And what happens ultimately is like you have a large enough user base
and you have a disparate enough set of machines
that you kind of run into the problem that there's a paper
that meta released X-F-A-S,
their like internal kind of like serverless system.
It becomes, it ends up being very, very,
difficult to go in and do that at scale unless you break out specific run times, basically,
which we did not want to go in and do, right, because we wanted to truly allow you to deploy
anything, right, which was our initial kind of thing with Nix, but we've moved towards some
interesting stuff that I think we'll be able to talk about a little bit later that we've built
for doing contest addressable file systems to be able to, like, lazy load anything from any
point, and then just page that into memory.
Amazing.
Okay.
Yeah, it's going to be fun.
The whole future is very, very bright.
It's crazy.
It's going to be nuts.
Okay, founder journey stuff.
Yeah, and your cloud usage, you tweeted you're going to spend 300K this month.
Yeah, I think we got that all.
I think we got too hard.
Coding agents.
Yeah.
Across the company?
Yeah.
You only have 35 people.
So I'm sure they're not all spending 10K on.
What's kind of the distribution?
I think I'm at about 25 in general.
And then we have some, you know, power users kind of all the way down.
I don't know.
Like, we came back and from.
from the winter break
and I was basically like
if you're writing code by hand
you are doing this wrong right
like the tools are good enough
at this point like
that you move extremely extremely
quickly and like 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 go and write it by hand like all of those
architectural patterns all those other things
like you're not just don't like you're not going to
throw them in the garbage or whatever actually they matter more now
than than any other time
but you just shouldn't spend your time
generating code that you would write.
Like, if you know how to go in and write it, just like ask the agent to go in and write it
and then reconcile it until it looks like you would have written it yourself, right?
And I think incidentally, like, people misconstrue my propensity to, like, push people
towards agents for like, hey, we're growing really, really fast and we've had some kind of
like bumps and relied.
Like, they're not necessarily related in terms of that.
But I think people should really, really understand, like, the tools are good enough for
you to be able to move extremely, extremely quickly to build things way.
way larger than you could have possibly built before, right? And so to our point about way earlier,
about like, how do 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, you can actually be like, well, 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
and read all these papers in general, right? Let me go in and work them out in general. And let me build
like massive test benches with like thousands of tests, right? Because they're free to author right now,
right, to go in and make sure that like this system can now can be built, right?
And I think that if you're not using the kind of AI systems to almost like speed run your roadmap to like go in and figure out where you need to go in and be to reconcile your existing system onto the future, then you're kind of missing a large point of what is currently happening right now, right?
Because you can just template out anything and validate it on the side for free, right?
What's the path to spend three million months?
Like, is it bound by like ideas and things that the.
customers can absorb.
I think for most companies,
it's actually bound by deployment at this point in time.
And I think that's why we've seen a lot of like a massive boon in terms of like users trying,
like not just users,
like companies like,
you know,
Fortune 50s,
like,
you know,
below,
et cetera,
like going and be like,
how do we get our developers to like go in and move quicker,
right?
I think you're probably going to hit your CFO before you hit any of these limits in
general because they're going to look at this and be like,
there's an eye-watering amount of like money being spent on these tokens.
Like I think,
I don't know,
I think it was the Uber C-Z.
It was like, we blew our token budget for the entire year or whatever, right?
And so inference costs have to come down, but they're also, you know,
there were inference constrained at this point in time, right?
And so you're going to almost get this, like, price discovery of, like,
what makes sense for an org to go and adopt?
And I think what you're going to end up with is actually,
you're going to almost, like, end up with the, like, F-1 driver concept,
which is if you have somebody who's, like, really, really adapted these things,
it makes sense to go and put them into like a $3 million car or whatever, right?
But if you're not, then like it probably doesn't actually make sense for you to go and do that.
And we're going to take a few of these people and say, you can drive the iPhone car.
We need to go in this general direction, figure out if this works and like almost go ahead and prototype it, right?
And so we've done a few of those things.
We've vastly accelerated our roadmap in terms of, oh, we thought we were going to be able to go in and ship this thing in the next like few years.
But actually, we can probably ship it in the next like a few months now, right?
because we're saying, oh, validated it out, it works,
we don't have to even build it incrementally.
We can have skip steps to go and just move towards where our vision is for a lot of the stuff.
And I think that that's kind of where we end up with a lot of it, you know?
Yeah, I think a lot of people are realizing the roadmap doesn't always have a business impact.
And so it's like, oh, it's too expensive to run these tokens.
But like, 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.
The same way you do with sales.
Yeah.
Like, you will spend a billion dollars in sales if you knew you will get $2 billion of revenue.
Exactly, right?
And I think the really naive way to go in and measure this is almost like your percentage of tokens that end up in production.
Right.
And so if you can measure that you are getting this level of impact because those tokens are ending up in production, that's awesome, right?
But I think the kind of burden of proof is now going to kind of like arise.
And you see it internally, too, on our stuff.
Like, we have a growing number of full requests that like are like haven't yet been merged.
And you're just like, okay, how do you get this into production, right?
And so it's really about like how quickly you can go and kind of build and deploy that software, right?
Which is exciting because our whole thing is.
We build and deploy software, you know, right?
So, yeah.
Yeah.
The SDLC is changing and it's something that both of us are like super interested in exploring as well.
One of my thesis, or it's not my thesis, it's the pull request is dying.
Yeah.
It's going to be the prompt request.
Yep.
And then beyond that, code review is also kind of dying because do you really need to,
if you have all the other systems in place, what else is changing about the STLC?
What else is to, well, I think the AISRE, the tools to make.
So the AISRE is like one of those things where it's like, you know, it's a pie in a sky aspirational.
What does it take to get an AISRE?
By the way, you should expose your tooling to your customers at some point.
Yeah, what's tooling?
Central Command Center.
Oh, Central Station.
So we have it for template maintainers, right?
So template maintainers can deploy and maintain templates,
and they get feedback on a lot of that stuff, right?
And so we're 100% going to go in and explode those things like incrementally.
Yeah, but like, you know, clustering around incidents.
Everyone has a version of that, but like I don't think anyone solved it.
Yeah, yeah, right?
And I don't want to say we've solved it internally,
but it's gotten so good that like now we can see those incidents forming like pretty quickly.
Yeah, real time.
Yeah, yeah, right.
Yeah.
So at some point, those will be.
things that either somebody else goes and builds or are we going 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 go in
and make it useful for users or monetize it or make sure that that loop becomes like a profit
center instead of a cost center. Like we want to go and do that at some point, right? So, but yeah,
poor press is definitely dying. Do you do first party feature flagging and incremental rollout
type stuff as well? So we have a feature flagging engine that we built internally that at some point
we will roll out. Because I don't see it as a user.
Yeah, yeah, yeah.
So like that.
That would be, that's good, right?
How come you can give us what you have?
Because we have to beta test it.
Like, we actually care a lot, a lot, a lot about the quality of the things.
There's plenty of stuff that like we've used internally and then we've got it to a point where like it doesn't make its way entirely through the journey because it fails.
It's like this holds for one service, but it doesn't hold for multiple services, right?
So we'd have to go and build these things for multiple services to go and make this work.
Right.
And we know for a fact that if we release this thing, we'd,
we'd have to go and rebuild this thing again and again and again.
And some things are worth doing to go in and do that.
But a lot of them are basically like that also, that kind of just informs a roadmap of,
okay, well, like for us to go and 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 like, oh, yeah, this works, but only for this service, right?
Unless it's like a very, very core initiative, which is like, you know, over the next like a few months,
we're going to roll out a few things that are like, okay, it works for a single service.
And then it works for multiple services.
and that works multiple services across the environment, right?
But you have to be very, very deliberate about those things.
Otherwise, you end up with a bunch of broken disparate experiences,
which ultimately end up creating 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, right?
So it's kind of the thing earlier about like you expand your company in general to get those
features and then you almost compact it, smooth out those things.
So the experience is like really, really stellar.
Like 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, like just internally we're like,
damn, this part's early sucks.
We've got to make this significantly, significantly.
No, I can attest, you know, over the last three years that I've watched you build in real way.
But yeah, no, I would call to listeners if you're not aware, like, the importance of feature flagging.
It's a very part, 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.
Yeah, 100%.
What was it called?
There's a paper about this.
There's a flagger and there's been another one.
There's a thing that, like, Facebook has gatekeeper.
Yeah.
So they're really important.
And agents are going to need this.
That's like the fundamental thing behind, you know, like just incremental rollouts.
Yep.
Opening I acquired stat sig.
Yep.
And basically GPG5 is just routing and flagging, you know, through different models.
And like, that's like.
And it's super important, right?
Because if you assume the software development lifecycle is 100% going to go in and change,
but it's going to change because we're trying to do things a thousand times faster
and a thousand times more concurrent than we were currently doing, right?
This is routing.
Yeah, right.
And so what ends up becoming important at scale, you know, before I even, you know,
start a railway, I actually built a feature flag in product.
And I tried to go in and sell it to people.
Okay.
Because I was like, oh, it's like, you know, like it's an easier version of like launch darkly or whatever, right?
And I ran into this situation, which is like anybody who's small enough to adopt your technology
doesn't care about feature flags, right?
And then anybody who's large enough to try and actually need feature flags need so much scale
that you have to like build out all the existing infrastructure.
So end up scrapping that.
But it's what is old is new again because now companies are trying to move really,
really quickly, but you can't just yolo this like vibe coded thing straight into production.
You need to basically say, hey, here's my blast radius, here's my impact, here's my like whatever.
I want to shadow it for these users, right?
Futureflex, right?
Like you're going to need those tools that ultimately those larger companies ended up having to go in and build to maintain their structures.
Everything's just going to get compressed by like 1,000 X so that everybody can go and do that.
And everybody can build those structures really, really quickly, right?
And that's like exactly where we're at right now is like you're compressing the software development life cycle.
And then we're going to expand it and add way more new things to it.
Yeah.
And then the other term that comes to mind with when this kind of discussion happens for me, for newer developers who haven't heard this term, cattle not pets.
Yeah.
Right?
Because like your prod, people treat it like a pet.
Yep.
It has a name.
You know, I have to keep it alive.
Yeah.
But when it's cattle, you can just mass farm and you can like roll out and you can like, you know, portion out parts of them and kill.
them or whatever.
Yeah, yeah, exactly.
I actually, I actually think that maybe that's the hot take, but I think that that's
actually going to change.
And I think you can move towards 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.
Yeah, yeah.
If you can snapshot every single thing at every frame, then like, it actually doesn't matter
if, you know, that thing gets obliterated because you have some sort of like snapshot of it,
right? All of the things that we have built right now are to essentially block out
any sort of
changes or alterations
or whatever from that
like hermetically sealed
DevOps like line or whatever
it's like okay well
you have to write a Docker file
because I only need these specific
instance like only this specific
cut of the file system et cetera
what have you just had the whole file system
what if you just snapshot it
and what if you lazily load
the entirety of the file system right
then you can get around this problem entirely
you don't need the ceremony of those
you know having a Docker file
or like having an answerable script
or like having all of these other things
you can just iterate on that
loop and then like snapshot it's like is this the right loop is this the right thing at this point in time
okay cool like now i'm going to go and merge it in production like go merge the file system yeah it's
gonna be really fun yeah this is like a whole other kind of worms but like i think the number of things
that are state full in the vm uh i think if you just kind of catalog them and just like develop
dedicated solutions for solving each of them you can actually kind of cut this down problem down a lot
and it's surprising that people weren't really trying until now yeah well so it's it's surprising
I mean, it's always been surprising to me because these are the things that we've worked on because they're just like, I'm like, it's so obvious.
Yeah, first principles, you need them.
Yeah, right?
Everyone, like, in theory needs them.
And then, like, the big clouds don't do them.
So you're like, it's impossible.
You know, it's something.
I don't know.
Yeah, exactly.
Right.
You're like, oh, well, they, you know, meta has all the people who write, like, you know, a EBPF code and, and they're, like, doing something with them, you know.
But, like, you need that kind of stuff to solve these problems, right?
And, and, like, talk to other.
It's like whatever is required, however deep we have to go in and get to like solve those problems, right?
Like all the way down to like the colonel's TCP stack, right?
Like we're going to go and figure that out.
Is there something that we need to go in and modify to like go in and make that work for the mental model that we have for the universe moving forward?
Like, yeah, 100% we're going to go in and do it.
We'll just keep going the way down.
It's fun.
It's super fun.
It's like it's so much fun.
Like I have to literally peel myself away from the fun, interesting problems that we're,
we have to make sure that we can scale the company in a way that works.
And there's so many different fun, interesting problems, whether it is like, how do 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 do do safe iteration or how do you get context like from the dashboard
to users or like how do you drill down all the way to the infrastructure layer?
How do you manage orchestration as like a real-time operating system versus a feedback control
system, right?
Like, it's just so fun, you know?
Yeah.
I mean, speaking of maybe you talk about the founder side, you're famously, like, you know, the YC, the SF consensus is you go to YC, you get a co-founder, you get to do all these things. You have done none of that.
No, yeah, I've like done a lot of different things in general.
In the elevator, you were like, actually co-founder kind of makes sense if like one person is the tech person, the other is the biz-deaf person.
Yep.
And but you have to contain all those multitudes yourself.
Yeah.
How do you do it?
Oh, okay.
I was going to ask, if there a question?
there.
Yeah.
The question is what the hell?
How do you?
How do you do it?
The question is how are you alive right now?
Yeah.
Well, I mean, yeah.
I mean, just try to get eight hours of sleep, you know, like.
Is there like a balance that you ideally like 50-50, 30, 30?
Like what's the mental model that you use as a solo.
There's no balance.
There's like you just, you just have to think about all these things and and be obsessed with all of these things.
Like whether it is being obsessed with like how do people think about your product from a go-to-market perspective or being obsessed from a
perspective of like, well, like, if I can make this change at the like kernel level,
then I can make it so that the user's SSAG connection never drops, right?
Like, because that's what I want.
Like, I want a universe in which I can go and like a snapshot all these things and it
looks exactly like you would just kind of iterate on a VM, right?
And I think you just have to be obsessed with all those things, like, at every layer of
the stack.
And I think that's what makes it easier for me.
I think some people, like, they're obsessed with different portions of the kind of like
journey, like the company, like whatever, right? And I think that that's when you can get really,
really good almost like cohesion by like segmenting out these things, right? And so, you know,
in the elevator I was talking about like, you know, you have a technical kind of like person,
et cetera. And then you have the customer kind of like person in general, right? And I think like if you
can segment those lines out really, really well and you can be very, very clear about what your
areas of ownership are for yourself or your, you know, company or like just where you're going
to operate, you're going to have a good time, right? If you can't be clear about those.
things, right? And this is why I was saying, like, two is the worst number of co-founders is
because you have no tiebreak, right? You basically are like, well, I disagree on this thing.
And I disagree on this thing. I was like, well, how do you resolve that? Right. Well, usually
someone's CEO, right? Right. Exactly. Right. Then you're like, okay, you have the sidebreaker.
Yeah, totally. I mean, listen, it's hard. It's hard every single way you cut it. Right. It's hard,
it's hard if you get help. It's hard if you do it yourself. It's just, it's just hard to,
like, run things, roughly speaking, right? But it's so rewarding. It's so fun, you know?
What if you found useful? Like a coach?
Any advice that has been really helpful?
I like to write a lot.
I got in trouble.
I get in trouble a lot for my Twitter.
There's a pattern.
Who do you get in trouble?
The people on Twitter.
Oh, okay.
You know, I was talking about it and I was like, hey, if you, you know, if you're working weekends,
you're kind of messing up your planning roughly, right?
And I've gone kind of back and forwards on that, right?
Because I think actually right now we're kind of at an extenuating time in general where it
actually makes sense to like work more, right?
Because the goals are pretty clear.
in my mind, right?
And so 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 and do those things.
But if you don't have the like, we're like, I think we should be going in this journal.
I'm not 100% certain.
I want to get a little bit of clarity.
I think what you need to do is you need to disconnect and you need to take your weekends
like very, very seriously.
You need to write about where are you?
What do you want to do?
Where do you want to go?
What problems are you trying to go and solve?
And like think about a lot of these things, right?
So, you know, like writing is important, sitting down.
Like, I don't like the word like meditation or whatever, but like whatever gets you into the state of like your mental clarity.
Like that's the thing that's like really, really important when you're trying to go on these journeys of saying, well, we're here and we really need to be here in general.
Or like we're here and I think we need to be roughly in this kind of like space for this to like work.
Right. So those are the things.
And then, you know, disconnect, hang out with the people that you love and then like work super, super, super hard.
when you're like, you know, like I try and work like sunup to sundown Monday to Friday,
all out in general. And then I try and disconnect on Saturday and then I come back to work on
Sunday afternoon, right? And then I do my writing plan for the week, all those other things.
And it works really, really well for me. But another hot take is like most advice is to be digested
and to be thrown out the window. And if it's helpful, it'll come back, right? If it's helpful,
you'll have kind of like learned it over time through experience or anything else like that.
But yeah, you mentioned like the kind of standard, you know, wicy advice.
all of us other things.
We have a lot, like, we've made failure as a society
to be very, very expensive, and it makes it difficult
for people to kind of trot off the paths, right?
Yeah, make sense.
Any other softbooks you want to get on?
Like, anything that you have not tweeted and got it in trouble
when that you want to preview to the world?
No, I think the agent stuff is like, it's just like,
it's crazy.
It's going to be the dominant way in which people are doing
pretty much everything, right?
It provided we can, of course, get the amount of inference required for that to go and happen.
But over the next, like, 10 years, right, you just, you see a fundamental shift in terms of how people are thinking about even just authoring the logic that's in their head, right?
Yeah.
My, you know, maybe one way we are phrasing this is if all birds can become a GPU provider, so can real way.
Yeah.
I think there's a lot of hard being 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,
It's really, really easy for you to just say yes to a bunch of different things, right?
And I think, like, it's going to be very, very interesting to watch, you know,
I think Anthropic is like an amazing company and like super, super stellar.
And they're moving into a variety of different zones, right?
They're moving into like the Figma kind of like stuff that they're after.
Today?
Yes, as a recording.
They've got, call on.
My career was on Figma's board and then they removed him like Monday and then they launched this today.
Yeah.
Yeah.
Yeah.
So, I mean, things move very, very fast right now.
But yeah, it's just going to be the way in which people are...
Okay, so your answer is focus, no GPUs for now.
Yeah, focus.
But never say never.
Yeah, yeah, right?
Like, 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.
And that's not like me leaking our roadmap because we don't have plans to go and do GPUs.
It's just a function of at some point you need flops, right?
Like at some point you want, like, if you're fully vertically integrated
and you want to make it really, really trivial for people to go and iterate and build and
deploy things, you need access to this core piece of fundamental logic, right?
So, yeah.
Yeah.
And then, like, at some point, presumably your own data center traffic is, like, a minority
of your workload right now, but is there, like, a majority or, you know, you just kind
of completely turn off?
Oh, at some point we got to 100% data center.
Like, our own data centers.
Yeah, yeah, yeah.
And it's, right now it's the vast majority of the stuff that exists on our barebendal data
centers, right?
Okay. So you're already there, like, vast majority.
Yeah, yeah, right?
I didn't know the extent of the transition.
Yeah, totally.
It was completed at some point, and then we grew so fast that we had to basically, like, go and scale back on that.
Take us back.
Yeah, sorry, Google Cloud.
Yeah, it was funny.
It was funny.
We got to, like, on the Datadadad is like, it got to 100%.
And then it, like, diveted back down into the, like, 90s or whatever, because we're like, you know.
At any capacity.
Yeah.
Yeah.
It's interesting.
You're literally building a new cloud that's independent, and people assume that that could never.
happen post, you know, the AWS.
Yeah, and it's hard, right?
Like, you know, we, we're going to, you know, figure out a bunch of different things
to make sure that, like, the platform is deeply, deeply reliable.
But you have to break ground on a lot of new things when you basically decide you're
going to build a cloud from scratch, but not copy the hyperscalers, right?
Like, we've been very, very deliberate to, like, invent our own infrastructure from
scratch based on reading a ton of papers in general, but, like, almost like, promising
to ourselves that we wouldn't copy somebody else's homework, right? Because we were saying,
hey, listen, you know, if we copy somebody else, we lose. Like, you're just going to become
them over time, right? And so you have to have a core thesis about like, why does this business
need to go and exist at this point in time? And for us, it's always been about the activation
energy to get something to go and deploy in production at any of the hyperscalers as right
now is far too high, right? And we believe that it should be instantaneous. We believe that
there should be no friction in between what your thought is and reality that kind of comes out
that you can share with your friends, right?
Right. And so that's what we're kind of like building toward it, again, at every layer of the stack. Like if we got to go down to energy, we'll go down to energy at some point, right? Like it just, it matters a lot for us from the experience of giving people access to this tooling because it's it's gated behind. Like it's not even just gated for regular kind of like these citizen developers that are now vibe coding. It's like you have multiple layers. You have a citizen developer. You have a front end developer. You have a back end developer. You have a DevOps person. You know all of these layers, right? And they all need to go in and disappear so people can just like ship like that.
Amazing. All right.
That's the future.
Thanks for coming on.
Thank you.
Thank you for having it.
It's been wonderful.
