Railway: The Agent-Native Cloud — Jake Cooper

21:10you just have to kind of like 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 VC is wrong. Yeah, well, I think most people are like, okay, how to raise as much money as possible from like whoever is like probably the best 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 and 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.

21:43And 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. So, lucky. Yeah, right. Like, you know, great. I've never started a company. Raised from Lucky. He's got good advice. I can text him all the time. He's really fast, et cetera. Like, awesome, right? Then you kind of like move on and you kind of like, you know, worked with, you know, John and Jordan at Unusual, right? And they were like, yeah you roughly know what you're doing building a product like we're just going to mostly 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 right and like feeding into there right so every step of the way we've kind of moved towards It's like, who can we partner at this specific time who's going to help us unlock that next section of the journey?

22:41Because guess what? I don't know enterprise sales. I can roughly 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 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. And we can spend our time basically saying, how do we win this versus bickering about strategy, right? No, I just had to pull up some beautiful data center charts.

23:06Yeah. I feel like you've done others. I just couldn't find them. Well, these are good. I mean, they all kind of look the same. Like, there's servers in a rack. Look at our box. Yeah, exactly. This is our box, right? Such a gorgeous box. Yeah, it's like, do you want to see more racks? It's like, oh, yeah. It's like, you know. I want the Jay Cooper signature edition. Yeah, we actually have plans internally. Yeah, so it'll be fun. We've got a few different promos that we're going to do and, 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.

23:35Yes. Why no data centers in space, man? Why you hate so much? 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, 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 there.

24:05Pardon? Astrophage. I don't know what that is. The Martian thing. Okay, you're very locked in. Yeah, yeah, that's fair. But yeah, I don't know. 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?

24:29Yeah, yeah, Astrophage. Oh, okay, right. Right. It's like, how are we going to do that? It's like, well, we'll figure it out. We have soaps however long to go in and figure that out, you know? Yeah. Making a bet on like human invention is weird because you just have to blind trust that it can be solved. But 100 percent. Right. 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 the travel time here or 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 basically not possible and is a grift versus is possible but sounds completely insane?

25:09And you're like, oh, cool. We're going to put data centers in space. It's like, okay. Coin flip as to whether that's one or the other. You just don't know, I guess. And I guess you'll know in like 10 years. Cool. That's a fun cycle. Okay. Moving back to agents. 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. What do agents want differently than humans? What do agents want differently than humans? I think they want the ability to version things. So it's not actually that different. There's just almost slight deviations in terms of how it kind of materializes.

25:51So agents want a way to be able to go in and test changes incrementally. We have feature flags as 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 uh 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 uh traces logs, metrics, all of those other things.

26:28They need like network compute and storage. They need the ability to write files, save files, iterate on files, snapshots, file systems, all of those other things, right? And so I think a lot of the 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 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?

26:58You 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, at 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.

27:29And 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 bottleneck is, right? And that breaks a different part of your system, right? So I think it's very much similar kind of stuff that humans have needed. You just need it at 1 ,000x scale, right? So how do you do code review in the age of the agents? I guess it's more of a question.

28:00You throw more agents at it. You don't. Yeah, right? But then who reviews things for CVEs and 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 a limit to like the amount of agents you can kind of throw out a problem.

28:24Jake Cooper:You started though, you already had a CLI before it was cool, I guess. CLIs have always been cool, by the way. How has the shape of like what you're exposing changed, 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.

29:02They'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. It's 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.

29:41most 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 arg and that drives it down to 2%, you've massively increased the like 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?

30:14Like, 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 and iterate, right? And then I go in and iterate loop is indefinite and infinite until the end of time, right? It's basically like, user wants to deploy a new thing, user wants to deploy a new Postgres instance, 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.

30:53You always want to be waiting on intelligence. 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 it's, 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.

31:25You'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, like, yeah, 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.

31:57But 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'd see them and, you know, your agents or your infrastructure would evolve over time, right?

32:31Now 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 where you'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 does the human need at this point in time to make suitable decisions about, like, 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.

33:05It 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?

33:44I think a lot of orgs, especially as they scale, they get in trouble because all that context lives in somebody's head basically. And then 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 just gets melted in terms of if you can have a really, really solid hierarchy and you can infinitely nest services, infinitely less nest code, infinitely less context, infinitely nest all these things all the way down.

34:14That'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 build, I've written a bit about this, these hyperstructures, things that are way, way bigger. And you look at the Golden Gate Bridge and you're like, how did we build that? There's that whole meme of how do we build this? We lost the technology. We don't know how. 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 built those things has evolved, right? And has changed. and there's new things 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?

34:50And we're just like, everything happens through Slack. But you do have everything in Discord, so it's the same point. It doesn't really matter. It's just like message passing and interrupts, 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, for sure. I think Slack, and incidentally, I think Discord's awful too. This is the equivalent of my mom test, right? 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.

35:21So every piece of feedback, every piece of customer support, every single thing like that gets aggregated into what we call clusters. If you have an incident brewing or anything else like that, now we can go and determine how many users are affected, all of those other things, et cetera. 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.

35:56We 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, 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.railway.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?

36:27This is built in-house? Yep. Okay, so, and then I remember helping out on this one with Angelo in 2023. Yeah, you scale a lot with a very small team. Yeah, yeah, yeah. So we're like 10 times bigger now. Oh my God, you have your full developer account here? Yeah. Okay, all right. Yeah, well, if you go to a real... 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.com slash stats. Oh, there you go. Yeah, that's your board. And so it's like all 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.

37:01We'll look it up. Yeah, but yeah, yeah, yeah. We're big on trying to build everything in public, talk about a lot of the stuff we're working on. We've had some issues or whatever in the past, and we're like, hey, cool, here's how we're fixing these things. We've got both compliments as well as some flack for incident reports and always trying to make them better over time just to talk with people, right? Yeah, yeah. Obviously, you had a big one recently. I like that it was only scope to 3 ,000. You presumably use Central Station. Any talking through what happens and I guess how do you address it internally as a team?

37:38Yeah, so internally as a team, this one really, really sucked. It was to do with an upstream provider that they didn't do the behavior that they said they were documenting, which is unfortunate given they 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 of users being like, oh, like, 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 that large user base of like 3 million people, right? You know, like, you have a lot of different disparate behaviors that can kind of come up, right?

38:18And so try as we will, we test those things in, you know, staging. We have tests for them, like all of this other stuff. You know, and unfortunately, we hit kind of an edge case there, right? And we've incidentally 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 the private disclosures are supposed to work. If people find an issue, are they supposed to contact you first? When you run a platform, these things are going to happen. Yeah. And what channels should people pursue to quietly resolve it before it becomes a much bigger incident?

38:59Yeah, so I think there's responsible disclosure. We kind of err on the side of 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, we've erred on the side of sharing those things more publicly even if they go and impact a small subset of those users. 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 to the widest degree at which they may have been 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 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.

39:54Yeah, yeah. I feel like that should just be the norm at all large platforms, right? Oh, it totally should. And a variety of companies, it totally is, right? 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 be able to shadow traffic. They need to be able to 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.

40:25Because then you can make those mistakes in an environment that's safe in general, right?

40:30Jake Cooper:You mentioned somebody brought it up. Do you see a world in which these things get automatically caught? Not necessarily by your agent, but 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 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 Vibe Coder initially, right?

41:04Or 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 0.1 % of people, 1 % of people, whatever, and then rolls out all the way there. That's the kind of non-deterministic version control that we've 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.

41:37And 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 developers' stack.

41:45Jake Cooper:You should have a free tier, like the model providers give you free tokens if you let them use the data. We'll give you free compute if you're the number one shard that goes out and you let us plug into your observability. Incidentally, we do that. We talked about the impact of that on 3 ,000 people or whatever. We start with the lower impact. Larger companies, etc. on the platform, they're the last ultimately that should receive those kind of rollouts so that they have a version of the platform that's deeply stable. I have three services, so I'm sure I get the first rollout. You can nuke my thing at any time, man.

42:23Jake Cooper:I guess my other question is, there's all these SRE agent companies, there's the observability people also want to have agents that fix your upstream problems. You have your own agent in the canvas now that you can chat with. How do you see that play out? It's almost like the stacking entropy thing in general. I think if you don't have the primitives to make iterating and production safe, it becomes very, very difficult. And so if you're an observability provider and you're like, oh, here's this fix to this error. Assume 80 % of those, they're probably actually good. They're going to make sense, et cetera.

43:00But then the last 20 % of that long tail of complex issues in general, ultimately rolling those changes out, if you just let somebody say, oh, cool, this looks good, and just 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, et cetera. But it always ends up like deviating from prod, right? And so you need the primitives and the workflows and the experience like built in our mind on like as a first party thing on the platform so that 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 sheet of transparency paper and the agent is kind of like this little guy that you push up and it's like, it should be able to like pop up in the canvas and it should be like, oh, cool.

43:48Like, 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. 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 PII, et cetera, is kind of like marked as like a transform when we automatically clone that database or go for a copy-on-write 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, right?

44:24The 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 Q 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 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. And so we want to compress a lot of that stuff way down and just say like as close to prod as you could possibly be, that's where we want to be.

45:00I was texting Erica 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 AISRE because I believe that 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 safe primitives for copying volumes, making sure that this is fine, it's going to nuke your production database. It's not a matter of if, it's a matter of when it's going to nuke that database, right? I'm a big believer in making those kind of like loop safe in general.

45:37I 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, 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, like, oh my God, it's almost impossible to hold this. Seriously, you're on the cloud docs. 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 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 camera or whatever 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 C++ JavaScript words right Yeah, it feels like a big jump.

46:36Yeah, 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?

47:13And 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, that's a RFC, like a request for a 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 tests match, but the code doesn't, let me reconcile that. 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.

47:42And these two are either discrete in the case of tests or slightly fuzzy, slightly discrete in the 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 doc and like have it 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.

48:10The holy trinity of specs and tests. Oh, okay. Itamar Friedman from Kodo is the reference for people want to look it up. One thing I do want to mention on just on the OpenClaw thing is also like the idea that you can self-modify. Yeah. Which is kind of interesting. I don't know how exactly Railway would support it, but I do have my OpenClaw. and I just tell it that it has the Railway CLI and you 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 modify its own infra.

48:45Yeah, 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. 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? Like, and this is kind of where we want to go with a lot of the, like, agentic, almost, like, self-replicating, like, infrastructure is, like, that's your loop.

49:19Like, 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, etc. How do you go and make those throwaway copies as trivial as possible to spin up, run super cheap, etc.? I think the era of like, I have an AWS instance and I'm going to get four vCPU and 16 gigs of RAM, it's going to get completely destroyed. Because if you do that for agents or anything else like that, you now need a thousand of those machines.

49:53right like it's so prohibitively cost expensive versus like you know we've spent a ton of time trying to figure out how do we go in and make these deploys whatever you want to call them you know Clouds got the like isolates everybody's like call the spam box like whatever like that atomic unit of deploy like only pay for what you use spin up instantaneously close loop as quickly as possible 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 etc it can come back with, hey, does this look good? This is a new state of infrastructure, given this prompt, I think I've solved this problem.

50:31And then you can go back to the agent and say, actually, it 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, yeah. Kind of like the most useful kind. I don't know, any other comments on just the agent deployment on Railway? No, I mean, it's getting better every day. And I'm on X or Twitter or whatever you want to call it. And you can always yell at me about the experience not working as well as it should because there's plenty of things that should work way, way better. I was going to say, I think at this stage in the juncture when people want the massively or embarrassingly parallel compute, they usually talk serverless.

51:13And I feel like there's a new serverless that has emerged compared to the previous five years of serverless, you're kind of in that new bucket. I don't know if you have comparisons or philosophical differences that you want to call out. No, I think it's like, as you kind of mentioned, it's somewhere in between. It's like the ability to run stateful, long-running, you want to call them workflows, you want to call them executions, you want to call them whatever. Which like Vercel has fluid compute and then Cloudflare has some container thing. Google has always had the app runner. App runner and the new one.

51:53Yeah, I forget that. There's like a bunch of them. 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 in and 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.

52:26Right. And that's why we focused on a 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. And so I think you're seeing right now where, again, the whole Twitter has no nuance, where it's like, servers, right? Servers is like, no, it's always somewhere in the middle. It's always some sort of convergence of, well, I want to run it for a long time, but also I don't want to provision this resource statically or pay for just things that I'm not using or anything else like that.

53:03And that's always been our thesis from day one. It's like, pay only for what you use, run it indefinitely. it is just like full Linux basically. I think that's why I like the first naming of Fluid. It's like, 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 or what do they basically, you know, you're one of the presumptive new Herokus. New Heroku has been a category for like as long as I've been in developer tooling. It's finally happening. What was that like when, you know, is there any behind the scenes of like, well, this is the moment.

53:42Yeah, I mean, you have so many people just like, you're just 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 and be like, yeah, we kind of like want to like move a lot of this stuff off or whatever and like, oh, okay, cool. But yeah, it's kind of just nuts. Like I think - Any like behind the scenes on what is, why does Salesforce let Heroku kind of just stagnate? Well, I mean, I can only, I can only like guess, I guess, right? Like, I mean, I think it's just hard when like, it's not your business.

54:13Like 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 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 Boz 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?

54:41And then we basically turned on the money. This is all like, you know, me verbatim. Yeah, rephrasing or whatever. 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 kind of no wonder that it languished in general, because it just wasn't the core focus of the business.

55:12And I think that a lot of companies get in trouble with this when they kind of split out their focus in general, because it means that you're almost fighting a multi-fronted war trying to compete with all these things. And not just compete with them externally, but compete with them internally for alignment and 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 you're mission driven, which is like the aspiration for a company in general of like, why do people work on things, right?

55:46It's like they want to work on something interesting, right? Like Heroku is off to the side. 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 pushed away, right? So it was literally just a matter of time for it to happen in our mind, right? Yeah, and kudos for them to actually call it out instead of just letting it be unknown or hanging in there. Their whole release was a little bit odd because they kind of called it out but they did it. They did our incredible journey. They didn't say they were shutting it down but they're like, yeah.

56:24And then behind the scenes I think they issued some stuff to people being like hey, yeah, you should close these accounts down. Like, we are going to go in and defecate 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 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 deployments. 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.

56:52You're like, how do I go in and make this happen? And then 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? But the wheel turns regardless, right? There's new stuff that's emerging, and we're very, very happy to almost continue to 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? It's a big crown to be a new Heroku.

57:22There's like 50 companies that fought for this. Oh, yeah, everybody's kind of 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, etc. 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 the workloads, etc.

57:55We don't have, and what's that feature that people really love? Pipelines? Heroku? Yeah, right. We have some approximation of it with the environment system in general. But yeah, so it's been super exciting. We've got a ton of people that we're able to go and 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. You build a temporal. You have complaints. I think this is the neutral, most neutral, most informed conversation that anyone will ever hear about temporal without someone working at the company.

58:40Yeah, that's fair. Because it's the two of us. Yeah, 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 those other things like that. Just give people a scale of what Cadence is at Uber. But I think people don't know. Yeah, so Cadence was the precursor to Temporal. And it powers like all of the trip actions, the rides, the like, you know, when you like rent a jump bike or scooter or like anything else like that or a car. It's like you're running these work clothes for a period of time. And you're basically saying this ride will run for an indefinite period until it like finishes.

59:15Right. 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 the trip, your workflow is done. That whole experience behind the scenes, I don't know about today in general, but it was powered by cadence at that point in time. And so it's a really, really... And I used to say, imagine if you could program the entire user journey top-down as one function. 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 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?

59:57Like 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 in a spot where you would cause like issues where replaying the state of the entire workflow causes a non-determinism issue.

1:00:26Because it works on deterministic workflow history. Yeah, exactly. And so it's very, very easy. The way that I would describe it is, well, it's a jet engine. If you know how to go in and operate it, if you know how to go in and run it, all of those other things. But you can't hand it to people who are trying to build things that end up being complicated, but don't have that whole state in their head. 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?

1:01:02And 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 ifs, 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 that other stuff. And we've started to like go and build some of those things here because like it's grown, you know, quite heavily.

1:01:26Right. 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 puts something in the system that invalidates some of the state or causes a non-determinism 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?

1:02:02And it's like, well, they 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 sysadmin running things behind the scenes for you. 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 worked on. So, yeah. Because it's like, yeah. This is one of those things where you typically wouldn't vibe code it. Well, I don't think you should vibe code it still. You still want to run depths and tests and stuff like that to make sure that you...

1:02:39I mean, you know, like, it's not like Turbo had to invent that from scratch either, right? No. So, like, there's libraries for those things that you can run. And, like, on top of that, it's just a state machine, you know, that you have to really map out. But ultimately, you define those abstractions that you want, and you run into a state machine, and that's it? Yep. 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, Restate's 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 it's 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 But so, yeah, but it's like, yeah, we used like the TypeScript stuff a lot because it's like what powers the dashboard.

1:03:46We're going to move a lot of the kind of Workplace 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.

1:03:58Jake Cooper:Even though it's free compute. Yep. Yeah. Cool. Any other technical infrastructure, cool stuff, rail packs? I don't know if that's still. Yeah. 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 NixPacks, which is on top of Nix. And then we moved. People have been trying to get me to adopt Nix and NixOS for four years. Is it ever going to be a thing? I don't know. We were super excited about it in general, but it has a bunch of different pain points in general. Because if you just think of it, it's a stack of version source code, or it's a stack of version binary.

1:04:37specific 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 makes it really, really difficult for, like, really real-world workloads. I think if you... But, you know, you content address it, 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 XFAS their like internal kind of like serverless system it becomes and 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 lazy load anything from any point and then just page that into memory.

1:05:48Amazing. It's going to be fun. The whole future is very, very bright. It's crazy.

1:05:52Jake Cooper: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 two. I think we got two. Coding agents? Across the company? Yeah. You only have 35 people. So I'm sure they're not all spending 10K a month. What's kind of the distribution? I think I'm at about 25 in general. And then we have some power users kind of all the way down. I don't know. Like we came back 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 that you move extremely, extremely quickly.

1:06:29And 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 in and write it by hand. Like all of those architectural patterns, all of 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 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?

1:06:57And I think incidentally, people misconstrue my propensity to push people towards agents for like, hey, we're growing really, really fast and we've had some kind of bumps in real life. They're not necessarily related in terms of that. But I think people should really, really understand 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 way earlier about 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?

1:07:34How would I go in and do these things? I have ideas because I've got history. I've 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.

1:08:07Jake Cooper:Because you can just template out anything and validate it on the side for free. What's the path to spend three million a month? 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, etc. Like going and being 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 money being spent on these tokens.

1:08:46I think it was the Uber season. It 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, we're inference constrained at this point in time, right? And so you're going to almost get this price discovery of what makes sense for an org to go in and adopt. And I think what you're going to end up with is actually, you're going to almost end up with the F1 driver concept, which is if you have somebody who's really, really adept at these things, it makes sense to go and put them into a$3 million car or whatever. But if you're not, then it probably doesn't actually make sense for you to go in and do that.

1:09:23And we're going to take a few of these people and say, you can drive the F1 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. Like 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 few months now, right? Because we're saying, oh, validated it out, it works. We don't have to even like build it incrementally. We can now skip steps to like go in and just move towards where our vision is for a lot of this stuff.

1:09:55And I think that that's kind of where we end up with a lot of it, you know?

1:09:58Jake Cooper: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 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. You would spend a billion dollars in sales if you knew you would get two billion dollars 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.

1:10:34But I think the kind of burden of proof is now going to kind of arise. And you see it internally, too, on our stuff. We have a growing number of pull requests that haven't yet been merged. And you're just like, okay, how do you get this into production? And so it's really about how quickly you can go and kind of build and deploy that software. Which is exciting because we build and deploy software. you know, right? So, yeah. The SDLC is changing and it's something that both of us are super interested in exploring as well. One of my thesis, or it's not my thesis, it's the pull request is dying.

1:11:08It's going to be the prompt request. And then beyond that, code review is also kind of dying because you really need to, if you have all the other systems in place. What else is changing about the SDLC? What else is changing? Well, I think the... AISRE. 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 the sky aspirational. What does it take to get an AISRE? And by the way, you should expose your tooling to your customers at some point. Yeah. Well, which tooling? Central Command Center. Oh, Central Station? Central Station. So we have it for template maintainers, right?

1:11:42So template maintainers can like deploy and maintain templates and they get feedback on a lot of that stuff, right? And so we're 100 % like going to go in and expose those things like incrementally. Yeah, but like, you know, clustering around incidents, like everyone has a version of that, but I don't think anyone solved it. Yeah, right. And I don't want to say we've solved it internally, but it's gotten so good that now we can see those incidents forming pretty quickly. Yeah, real-time and AI clusters. Yeah. So at some point, those will be things that either somebody else goes and builds or we go in and build, but we've always built stuff that was purpose-built for us and if it made sense and there was a way to 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?

1:12:27So, but yeah, WordPress 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 didn't 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 it doesn't make its way entirely through the journey because it fails.

1:12:59It's like this holds for one service, but it doesn't hold for multiple services. So we'd have to go and build these things for multiple services to go and make this work. And we know for a fact that if we release this thing, 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 our roadmap of, okay, well, 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?

1:13:30Unless it's like a very, very core initiative, which is like, you know, over the next like 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 then it works for 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 like 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 really sucks and we got to make this significantly significantly better I can attest you know over the last three years that I've watched you build in real way but yeah I would call to listeners if you're not aware like the importance of feature flagging it's a very big part of uber culture so much so that they have too many feature flags and then they have another thing to remove feature flags.

1:14:28Yep, 100%. There's a paper about this. There's a flagger and there's been another one. There's a thing that like looks like dead feature flags. Facebook has Gatekeeper. Yeah, so they're really important. And agents are going to need this. That's like the fundamental thing behind just incremental rollouts. Yep. OpenAI acquired stat sig. Yep. and basically GPT-5 is just routing and flagging through different models and it's super important 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 This is routing and so what ends up becoming important at scale, before I even started Railway, I actually built a feature flagging product.

1:15:16I tried to go in and sell it to people, right? Because I was like, oh, it's like a, you know, it's an easier version of like LaunchDarkly 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 needs so much scale that you have to like build out all the existing infrastructure to 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 things 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?

1:15:53Future Flex, 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 a thousand 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 lifecycle and then we're going to expand it and add way more new things to it, you know? 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.

1:16:23Yeah. Right. Because like your prod, people treat it like a pet. Like it has a name, you know, I have to keep it alive. 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 that thing gets obliterated because you have some sort of like snapshot of it, right?

1:17:00All 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 lying 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, right? What if 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 Ansible script or like having all of these other things.

1:17:35You can just iterate on that loop and then like snapshot it. 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, why not? It's going to be really fun. Yeah, this is like a whole other kind of worms, but like, I think the number of things that are stateful in a VM, 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 problem down a lot. And it's surprising that people weren't really trying until now.

1:18:04Yeah, well, so 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 in theory needs them. And then the big clouds don't do them, so you're like, it's impossible. I don't know. Yeah, exactly, right? You're like, oh, well, Meta has all the people who write eBPF code, and they're doing something with them. But you need that kind of stuff to solve these problems, right? And talked about it earlier, it's like, whatever is required, however deep we have to go in and get to solve those problems, all the way down to the kernel's TCP IP step.

1:18:40right 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 that'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 have to make sure that we can scale the company in a way that like 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?

1:19:14Or it's like, how do you do safe iteration or how do you get context from the dashboard to users or how do you drill down all the way to the infrastructure layer? How do you manage orchestration as a real-time operating system versus a feedback control system? It's just so fun. 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 do all these things. You've done none of that. Yeah, I've done a lot of different things in general. In the elevator, you were like, actually, co-founder, it kind of makes sense if one person is the tech person, the other is the biz dev person.

1:19:53But you have to contain all those multitudes yourself. Yeah. How do you do it? Oh, okay, I was going to ask, is there a question in there? Yeah. The question is, what the hell? 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-30? Like what's the mental model that you use as a solo phone? There's no balance. There's like, you just have to think about all these things 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?

1:20:28Or 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 SSH connection never drops. Because that's what I want. I want a universe in which I can go and snapshot all these things and it looks exactly like you would just kind of iterate on a VM. And I think you just have to be obsessed with all those things at every layer of the stack. And I think that's what makes it easier for me. I think some people, they're obsessed with different portions of the journey, the company, whatever. And I think that that's when you can get really, really good almost like cohesion by like segmenting out these things, right?

1:21:06And 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 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.

1:21:33Right. You, you basically are like, well, I disagree on this thing and I disagree on this thing. Right. 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 to side breaker. 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, 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 have you found useful? Like a coach, um, any advice that has been really helpful?

1:22:00I like to write a lot. I got in trouble. I get in trouble a lot for my Twitter. I think that there's a pattern. Who do you get in trouble with? The people on Twitter. Oh, okay, okay. You know, I was talking about it and I was like, hey, if you're working weekends, you're kind of messing up your planning roughly, 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.

1:22:35But if you don't have the like, I think we should be going 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 like 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?

1:23:18So those are the things. And then, you know, disconnect, hang out with the people that you love and then like work super, super hard when 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.

1:23:50But yeah, you mentioned like the kind of standard, you know, YC advice. solve as other things. We have a lot, like, we've made failure as a society very, very expensive and it makes it difficult for people to kind of trot off the paths, right? So. Yeah, makes sense.

1:24:04Jake Cooper:Any other softbooks you want to get on? Like, anything that you have not tweeted and gotten in trouble with 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? Provided we can, of course, get the amount of inference required for that to go and happen. But over the next 10 years, you see a fundamental shift in terms of how people are thinking about even just authoring the logic that's in their head. Maybe one way of phrasing this is, if all birds can become a GPU provider, so can Railway.

1:24:44Yeah. 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 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. Yes, as a recording. They've got Claude.

1:25:12They've got all this. Mike Kruger 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, but never say never. Yeah, right. 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.

1:25:44If 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. So, yeah. Yeah, and then at some point presumably your own data center traffic is a minority of your workload right now, but is there a majority or you just kind of completely turn off? Oh, at some point we got to 100 % data center. Your own data centers. And right now it's the vast majority of the stuff that exists on our bare-bentled data centers. Okay. So you're already there, the vast majority.

1:26:23Yeah, 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 go and scale back on that. Take us back.

1:26:34Jake Cooper:Yeah, basically. Sorry, Google Cloud. Yeah, it was funny. It was funny. We got to, on the Datadog dashboard, it got to 100%, and then it divoted back down into the 90s or whatever because we were like, you know. You're adding 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 the AWS. Yeah, and it's hard, right? We're going to figure out a bunch of different things to make sure that the platform is deeply, deeply reliable. You have to break ground on a lot of new things when you basically decide you're going to build a cloud from scratch but not copy the hyperscalers.

1:27:10We've been very, very deliberate to 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 we just, 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 it in production at any of the hyperscalers as right now is far too high, right?

1:27:42And 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? And so that's what we're kind of like building toward, 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 gated behind, like, it's not even just gated for regular kind of like these citizen developers that are now vibe coding.

1:28:10it's like you have multiple layers. You have the citizen developer, you have the front-end developer, you have the back-end developer, you have a DevOps person, 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 out. Thank you. Thank you for having me. It's been wonderful.