4.2 • 653 Ratings
🗓️ 22 July 2025
⏱️ 43 minutes
🧾️ Download transcript
Click on a timestamp to play from that location
0:00.0 | Railway is a software company that provides a popular platform for deploying and managing applications in the cloud. |
0:06.5 | It automates tasks such as infrastructure provisioning, scaling, and deployment, and is particularly known for having a developer-friendly interface. |
0:15.3 | Jake Cooper is the founder and CEO at Railway. |
0:18.9 | He joins the show to talk about the company and its platform. This episode |
0:23.1 | is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him. |
0:41.9 | Jake, welcome the show. |
0:43.0 | Great to be here. |
0:44.8 | I'm super excited to chat a bunch of stuff. |
0:46.5 | I know we've got a couple of things on the docket. |
0:48.1 | Yeah, absolutely. |
0:50.6 | We were chatting before we hit the chord here, |
2:34.2 | but you and I both graduated from the University of Victoria in British Columbia and Canada. So what ended up sort of pulling you south to the Bay Area? Yeah, I think there's almost like this brain drain kind of pull that I think we're both talking about it right before. And I think like half of maybe my graduating class was just kind of like, yeah, I want to generally kind of move down there in general. So I think I kind of always knew that I wanted to be in the U.S. I think I always knew that I wanted to start a company at some point. So it was more of a matter of like when, not if, if that makes sense. And so I ended up moving to a few different places before I ended up working out a bit out of like Amsterdam and Italy in between grad and then moved on to New York and then moved to San Francisco. But yeah, I think it's a pretty no-brainer in my mind because you pay the same amount of tax dollars and you get, you know, twice X the ambition plus twice X the Sun, you know, so there's a pretty strong payoff on doing that, you know? Yeah, as much as I love Canada, I think if you're in tech, there is such a strong pole to the Bay Area, especially when I moved here now, like 15 years ago. I think we'll get into it today, but you're running a fully remote company. So I think there's somewhat less constraints on companies and the opportunities people have in tech today all over the world. But that wasn't always the case. But back to what you're doing now around Railway, what was sort of the driving factor behind the creation of it as a platform focused on streamlining, deployment, and management of infrastructure and dependencies? Yeah. So, I mean, I grew up, like, hacking on random stuff. I started actually writing, like, my first computer science stuff was writing kind of aimbots and bots and cheats for like video games. And so it was always like a very kind of exploratory, creative kind of thing like that. And so I ended up writing like small programs or anything else like that. And then every single time I kind of like moved to like deploy something, it was just like you're switching from this world of oh cool, this joy, you know, it's this like beautiful, |
3:26.4 | happy kind of like thing where you're hacking around. It's nice. And you're like, how do I, like, move this thing, right? And obviously there were like tools like Heroku at the time. And so, like, finding those tools was like awesome and magical. But there's a whole like class of problems that exist actually outside of like actually getting something deployed that we call like deployment lifecycle, right? And so it's how do you make changes? How do you like go and get them reviewed? How do you go and add a database in an other environment? And then how do you make sure that you're going to actually have that database when you like go in and merge, right? This whole kind of split universe phenomenon of staging, et cetera, right? And so when you get into things like that, you end up having to wrangle a lot of stuff, right? And so it goes kind of back to this bit of trough of sorrow having to go and figure out all of these things, right? And in reality, a lot of the workflows that people end up having are very, very similar, right? And so if you end up building a lot of those workflows, then most people they want to split into a parallel environment, they want to test their stuff, they want to merge it and they want to take into like automatically roll out. Right. So they just simply don't want to handle that. |
3:24.7 | So it ends up being that like this class of problems ends up being both interesting from like a system's perspective. So you know, we're working some really, really cool like networking, storage, et cetera, all of those other things. We've got our own bare metal servers now, but also just like very, very applicable to the wide swath of people, right? And I also think that like the compute market is one of those things that will just continue to grow, right? |
3:28.5 | It's just like very, very applicable to the wide swath of people, right? And I also think that like the compute market is one of those things that will just continue to grow, right? It's just like, we will need more computers, right? And so anything that we can do to kind of streamline people's like productivity in there, it's like it's one of the highest leverage things that we have in general. Right. And we talk a lot about like leverage. Like how do you build leverage? How do you build efficiency, right? How do you make it so that a user's action has an outsized return on what they're putting in? Right? Because that's for us, that's the definition of magic. It's like you do a little, you get a lot. Do you think the public cloud has increased that pain in terms of, you know, we have this joy of like building something and you get sort of that aha moment of, you know, building something on maybe on your local machine and running it. And then you got to get to a place where like, now I have to deploy it. Does all the sort of like boxes that you have available in the cloud make that even more of a challenge? I think you're trading pain, if that makes sense, right? And so like, it's obviously very, very painful to like go and procure servers, get them up, making sure that they don't fall out of the wall and that, you know, somebody doesn't bump the power cable and all that like class of problems of solving those, right? And then you kind of trade those for like, okay, how do I like manage these machines, right? And then you kind of have to play with the |
4:47.8 | abstractions that the cloud providers give you, right? And there's benefits and curses to that, right? In the prior kind of like bare metal world, it's like you want to spin up a server, you want to spend up something. Well, it's like you're measuring your time on the order of weeks or maybe even months, right, to like get this thing like up and running, right? Versus you go to the cloud and it's like, boop, hit a button, |
4:45.1 | and it's kind of just like up and running, right? |
4:46.6 | But you do have to kind of like banish the primitives that the cloud providers give you and kind of like work within those walls in general, right? And those primitives can be, I think, made faster in and of themselves, right? So from making deployment instant, right, moving your builds like immediately beside your compute, moving your storage, keeping all of these things together, right? That's kind of the whole end goal of like a lot of the stuff that we're building is like all of these things have almost been verticalized, right? If you look at the AWS kind of dashboard, it's like every service, you know, famously Jeff Bezos is kind of like everybody's going to interact with these things over an API. So everything is kind of like vertically sliced, right? So there's no mechanism to kind of like share these things together unless you really want to go and start composing. And then you have to again, you start bumping into the abstractions there in general. So I think it's like you're trading kind of like pain over time. Okay. And you know, there's been a number of companies that have tried to simplify this process. You mentioned Heroku. There's other companies in the space, like, you know, render, your Netlify, these various past platforms. Like, what is Railway's sort of a unique approach to this that distinguishes it from some of the other players? Yeah. So I'd say there's a couple of things. We talk about wrangling complexity a lot in general. So we've built a really intuitive UI that is kind of like layered. It's a canvas. You essentially just go to it and you kind of just spew out, hey, give me Postgres. Hey, give me, you know, Redis, give me a deployment of GitHub, right? And I think we've gone above and beyond on a lot of different things. We've built a system for kind of like automatically generating Docker images, right? So essentially it gives your code. We will go and statically analyze it. We will go and figure it out and stuff like that. So you don't have to actually like write anything to get started in general. Additionally, we've built our own kind of like storage system. So you can host literally anything on railway, right? So you can build a click house database beside your Python instance, beside your whatever, right? Like for us, it doesn't really matter. And we've like built those primitives in such a way where they feel very, very quick. And they're really, really easy for you to kind of compose together. Right. And so I would say that what separates railway or versus like something like a fly or render or anything else like that on the surface is |
7:00.9 | they may kind of like look very very similar but over time as you kind of like compose these things |
7:05.6 | together we've tried to almost like linearize the complexity of each of these things versus |
7:10.2 | allowing that kind of complexity to spawn out until oh you have so many of these microservices and |
7:14.3 | no tools to manage them and stuff like that so you mentioned Docker there and being able to extract a way the challenge of putting together Docker image. What is that challenge that people typically run into? Yeah. So I would say that there's a couple of challenges. Oh, and sorry, another thing to mention is like railway is only, you only pay for what you're using because we've built their own orchestration engine. So we'll go in place workloads. So normally if you're on a Cloud Friday, you know, you pay for a 4 gig box. |
... |
Transcript will be available on the free plan in 3 days. Upgrade to see the full transcript now.
Disclaimer: The podcast and artwork embedded on this page are from Software Engineering Daily, and are the property of its owner and not affiliated with or endorsed by Tapesearch.
Generated transcripts are the property of Software Engineering Daily and are distributed freely under the Fair Use doctrine. Transcripts generated by Tapesearch are not guaranteed to be accurate.
Copyright © Tapesearch 2025.