The Changelog: Software Development, Open Source - Building the developer cloud (Interview)

Episode Date: December 12, 2024

Kurt Mackey is back for a deep dive into what it takes to build the developer cloud. Kurt joins Adam to discuss the alliance between companies and cloud, something Kurt refers to as the "Rebel Alliance," cloud complexity vs usability, Fly's future with Postgres and why they've waited, thoughts on Neon and Supabase (Kurt shares a hot take), and our CDN saga and plan to build a simple CDN on Fly called Pipely (still a Pipedream).

What's up, welcome back. This is the change law. We feature the hackers, the leaders, and those, yes, those building the public cloud. On today's show, I'm joined by Kurt Mackey, the co-founder and CEO of Fly. We discuss the business of building a cloud, the alliance between companies and cloud, something Kurt refers to as the Rebel Alliance, cloud complexity versus usability, Fly's future with Postgres and why they've waited, thoughts on Neon and Superbase, yes, Kurt shares a hot take, of course, and our plans to build a simple CDN on Fly called Pipely. But for now, it's just a pipe dream. And to muddy the waters a little bit more, yes, we're big fans of Fly, as you may know.

And Fly is the home of changelog.com. Learn more at fly.io. Okay, let's talk cloud. Well, before the show, I'm here with Jasmine Cassis from Sentry. Jasmine, I know that session replay is one of those features that just, once you use it, it becomes the way. How widely adopted is session replay for Sentry? I can't share specific numbers, but it is highly adopted in terms of if you look at the whole feature set of Sentry, replay is highly adopted. I think what's really important to us is Sentry supports over 100 languages and frameworks.

It also means mobile. So I think it's important for us to cater to all sorts of developers. We can do that by opening up replay from not just web, but going to mobile. I think that's the most important needle to move. So I know one of the things that developers waste so much time on is reproducing some sort of user interface error or some sort of user flow error. And now there is session replay.

To me, it really does seem like the killer feature for Sentry. Absolutely. That's a sentiment shared by a lot of our customers. And we've even doubled down on that workflow because today, if you just get a link to an issue alert in Sentry, an issue alert, for example, in Slack or whatever integration that you use, as soon as you open that issue alert, we've embedded the replay video at the time of the error. So then it just becomes part of the troubleshooting process. It's no longer an add-on. It's just one of the steps that you do.

Just like you would review a stack trace, our users would just also review the replay video. It's embedded right there on the issues page. Okay, Sentry is always shipping, always helping developers ship with confidence. That's what they do. Check out their launch week details in the link in the show notes.

And of course, check out Session Replay's new edition, mobile replay in the link in the show notes as well. And here's the best part. If you want to try Sentry, you can do so today with $100 off the team plan. Totally free for you to try out for you and your team. Use the code changelog. Go to Sentry.io. Again, Sentry.io. well kurt are you cool with just pretty much anything you can tell me when there's limits too like we do edit so if i'm if we're going down a road that's like two tmi just like almost all the things i'm working on now are at risk of like pitting someone off. It's actually kind of funny. It's the downside to trying to decide

who gets money and who doesn't. Okay. That's a good place to begin then. Fly is one of our tried and true sponsors as well. So let's get that out there. We love the fact that we we here at Change.ly use Fly.

We are hosted on Fly. Yeah. Our listeners are well aware of this. So having you on a full-length podcast will be welcoming, but at the same time, like, hey, they're also a sponsor. So make sure you mention that. Yeah, pay for play, you know? It's just like, I'm not interesting to talk to unless there's a check attached.

Well, thankfully, there is no check attached to this episode here, which is why I put that caveat out there. And I say that because we've gotten emails about other platforms saying, Hey, I know you're sponsored by, and you use fly and all that good stuff, but would you mind having us on your podcast? And I'm like,

of course. Right. No kidding. Like, yeah. Like we want to talk about everybody just because we chose fly. And just because we have this deeper relationship doesn't mean that we don't think there's other platforms or things to cover for developers.

I do think you should invite me on as well when they come though just to like just to i think that's the that's the just kidding that'd be kind of cool honestly though i think um i think developers would honestly appreciate not so much a debate but a non-one-sided conversation between folks like you and others like you that are building platforms like fly to enable developers to do what AWS is not innovating towards. Let's just say, right. I wonder how you could do that with a bunch of people that are like,

just going to give you the political nice answers and actually get some kind of disagreement going. Yeah. I'm down with that. I'm down with that. I'm down with that. It'd be fun to talk about, like, I think if you talk to all of us, we all think we're doing something different. And then really, like, find those differences

and what future we think we're working towards would be kind of an interesting. Like, Jake from Railway and I, I don't know what they think they're doing. I know what we think we're doing. I bet it's not even close to the same, even though it looks the same sometimes. And they've been doing great too.

Railway is an example. Render is an example. Can't think of any others that really is on the top of my list. But you can name off competitors if you'd like. I mean, if that's how you do things, whatever. I won't stop you. There's still all the old school server companies that are like, I don't even, like Vulture is not old school,

but they kind of come across more like dedicated servers than modern clouds. But like Vulture and Hetzner and OVH, and I don't know, usually they end up sounding budget because it's like their cost comparison, but a lot of them are doing really interesting stuff. So that's cool. We talked about hetsner recently with just really in passing with david hanamar hansen is that name ring a bell to you do you know who that person is

no is that uh i think his like acronym or short name is he a politician his nickname's dhh no that's a race car driver he's a race car driver. He's a race car driver. Yeah. Ugh, rich people. I think he may have been part of a framework creation. I don't know. I mean, I don't know. Yes, he also threw shade at us on Twitter one time while we were having issues, which is not anyone's favorite. Oh, man. We are at odds, and he doesn't know it.

Now he does. No, he's probably not even going to listen to this. Are you kidding? He's not going to know. He does listen to the show. I think he listens going to know. He does listen to the show. I think he listens to the show. He might listen to this show. We should talk about what he said on Twitter about us,

because I actually think his take on this stuff is fascinating. Say it. What did he say? I think we had an outage. And so the nature of our platform, and this is part of the problem with AWS, is if you're doing one simple thing and you buy, call it a laptop to run it on, it's going to actually work really reliably because no one else is messing with that laptop. There's no other people on there that can possibly ruin the experience.

It's probably overpowered for what you're doing. And there's very few moving parts. And so us and every other cloud ends up with these things that like literally every customer impacts in some way and so ours is our we have this global proxy so every request that comes to fly goes to the same cluster of basically rust uh proxies that sit on something like 100 servers we run right now no more like 200 maybe 300 wow all of my server numbers are wrong just like by the time you listen to this i'll be more wrong but I'm just wrong because I'm always like eight months behind

so we have all of these servers running a Rust proxy and every request on the platform and every TCP connection on the platform goes to this basically one project that's complicated and the two things that happen there are one, one person can find by accident usually it's not like a security

usually like the security and like the DDoS vectors we've guessed about and done a pretty good job of mitigating. But what happens is when people actually run real apps to get any kind of volume, they do things that nobody would have predicted. And so I think the whole adventure of building a cloud is building this thing, getting people to use it, seeing how it goes wrong when they use it in a way that you didn't expect, and then adjusting for that, and then doing it for the next 100,000 customers that are going to do that thing.

And so ours is our proxy, and that's the thing that has failed in the ways that we couldn't predict most and affected the most users at the same time. Because if a proxy has issues, people's apps stop serving requests. That's literally down for them. And a lot of stuff, ironically, when I ran a database hosting company and AWS had issues like this,

and then our databases went down, nobody actually complained to us because their apps already weren't working. The database is actually the last thing that people go check on when their app's not serving traffic. And so we were sort of insulated from it. But now that we're at the front

of the request cycle between them and their users, it's a lot more sensitive of a position to be in. Anyway, so DHH's thing was something like, I think he called them merchants of complexity or something, which I thought, you know, we like our strong phrases here. But the general thing he's talking about is our global proxy is really complicated because it has to be to serve the needs of a million people running apps at a given time. And when that goes wrong, it takes your apps down in a way that you don't need it to be that complicated for your own specific purpose. It's that complicated by nature of having to service a million different customers like you. And so if you put something like HAProxy

or one of the modern, I just blanked on all of these things. Anyway, if you put something like a load balancer in front of your own stuff on your owned on all of these things. Anyway, if you put something like a load balancer in front of your own stuff on your own servers, and you're the only user, you're just not going to have that scale of issues. So that's roughly what he was going after us for. My general take, like I think, I'm kind of sympathetic to the merchants of complexity thing.

I think he applied it to us sort of unfairly because there's parts of our stack where we're kind of forced into this. But the real thing that I've been, i've also been wary of is like there's a lot of reasons a lot of people would tell you very complicated infrastructure that you don't need to make a lot of money and like for a long time kubernetes sort of fell in this thing but like you know there's there's there's stuff like giant who's the best example of this you remember hortonworks no that doesn't ring a bell hortonworks was i think it was hadoop anyway they made a lot of money by selling a lot of hadoop to companies

and nobody actually needed what they were selling it was like a it was kind of a flash in the pan company i got really big really fast because they were way better at selling something and way worse at building something anyone needed if that that makes sense. And so I think that, to me, the merges of complexity should be applied to people who are kind of overselling what you need for your particular application. And I would be a little more hesitant to say it about infrastructure that, by the nature of what it's trying to do, has to be complicated, if that makes sense. Because we're not going to run, there's no feasible way for us to do the things we do with our proxy and run a bunch of HA proxy instances for people. We actually tried that. Like one of our actual big priorities when we do cloud features is to isolate what

customers are doing as far as possible and make it as close to running an isolated environment as we can possibly get. Was this recent or was this a while back? Everything over the last two years feels recent. I feel like this was like six months ago, eight months ago, something like that. Okay. I just Googled merchants of complexity and landed on a Hey World post from David. I don't see fly being mentioned in the article, but maybe it was a shadow proxy mention. I don't see fly being mentioned in the article, but maybe it was,

maybe it was a shadow proxy mentioned. I don't know. Kind of thing talking about what it means. It's a hard sell, et cetera. You know, one thing I like about David, honestly,

is that he is so passionate about his opinions that you tend to like, when you're in conversation with him, want to believe and agree with the things he's saying yep but but then when you think about it afterwards you're like you know what i don't really agree with that one fully or that one fully but what i really appreciate is that he thinks really thoroughly about his hard opinions that's what i appreciate more than his wrongness or rightness at all really is just the passion for thinking deeply about what you believe and being bold enough to share it.

That's the number one thing I think I appreciate about him, especially leading rails as it's like a new rails Renaissance happening. Now, a lot of people are kind of, you know, looping back to what was old is now new again, kind of the better way again. And, uh, we had him on the show recently and talked about that. All right. I found it. If you Google DHH Twitter merchants of a complexity, they'll pop up. It was a retweet. He didn't say those words in that tweet.

Somebody was reflecting that back to him, but it was about us. It was September 1st, so definitely not six months ago. Which actually gets me to another thing. It's funny because an individual dev's perception of when they have a problem is that our whole platform isn't available and that's almost never the case and so you start talking about outages and things and it actually gets kind of it's an interesting i've learned a lot about talking to people about complicated infrastructure and how it fails and how it impacts it because i think i think this week s3 also went out like there's just like it's just like the internet fails like everything on the internet internet is going to fail at some point.

And I think for a good solid day, S3 wasn't working the way we needed it to. And it was like a big knock. It's interesting. AWS is actually getting a pass these days because they're the old IBM. They're the new IBM. They're like, well, you know, not necessarily getting a pass from DHH other than on pricing. But in general, like AWS is the new IBM. You don't get fired for buying AWS.

And so when something goes wrong with AWS, obviously that's what's happening to everybody. When you make a bold choice to not use AWS and something goes wrong, it actually is a much bigger deal to people. I'm going to sound like I'm whining about that. It's just the way things are. It's like, clearly I wish that we got the same kind of pass as aws but in some ways we haven't earned it but otherwise it's just a really interesting look into the psychology of developers yeah because one thing about dhh's

tweet here too is like people want no downtime and they also want to spend zero dollars and so there's this actual tension between even what he's offering is like even the five dollar hetzner servers you can run your apps on are more than people want to spend a lot of the time and what people actually want is for their apps that don't matter to cost zero dollars and for their apps that do matter to cost not as like as little money as possible right and like actually trying to to solve this problem for people is just sort of inherently complicated well i think it's to some degree not so much right rightfully so but the downtrend of let's say like even digital ocean a decade ago you know blazing fast on ssds they came out with this phrase right droplets on ssds that's right and they were an early sponsor of

ours and we were early days with them you know back in the droplet days when it was a brand new noun in our lexicon essentially and they were driving down to like five dollars these you know these you know very fast blazing fast on ssd like this whole new revolution of like it was ssd was newer than a lot newer and to get to that price point on something that fast. So the state of the market almost makes the user want what you just described. My insignificant projects to be completely free and my significant projects to be mostly free. You know, I actually like, I'm hugely in favor of that though, because I think that, so like we've actually started showing people what they can run. There's free-ish, right? Like we've started showing people how much they can do for less than a dollar a month on fly because like, I want to build a lot of apps.

Developers want to build a lot of apps. I want to put these things out there. I don't want it to cost me a lot of money in 12 months when I've forgotten about this thing. And I don't want to think about it again after I've shipped it. And so like, I'm actually like pretty wildly in favor of almost like, almost like cheapiumium like scale to almost nothing we have we have started we used to have a we used to have a free tier and what we've started doing instead is telling people this costs money but not very much it's almost like you can run an app for pennies but it's going to cost you pennies it's not going to be free and i think part of the reason for that is because the implication is it'll cost more when it scales up.

It's been a really pretty good move for us to have the free stuff. If you pay any attention to Postgres options, basically Neon's value proposition is you can create a million databases for very cheap. Which is not what people who are running an app on Postgres want. It's not like the one thing we've learned about databases is people pay almost as much money as they have to make a Postgres run reliably for an app that's important to them. What they really want is to be able to create a ton of databases that are basically disposable and not spend very much money doing it. And it's really fascinating to me that this is sort of like what Neon's found as a niche. And on the flip side, you've got RDS, which has never lowered its price ever because they've never had to. That's where the compelling part of serverless Postgres becomes really cool

with Neon. And it's funny you mentioned Neon because Superbase is one of I think your partners in a way I'm not really sure but you mentioned Neon versus Superbase so at least you're not biased. Well Superbase, I feel like Supabase is doing something different. And Postgres for them is an implementation detail and a growth vector. If you're building in Firebase, it's not portable. When your app grows, you probably want to move to something like RDS anyway, because this proprietary data store is not great for them.

To me, Supabase is using Postgres because it makes sense to their customers as they evolve. But Supabase's goal has not been to get devs to use a million Postgreses directly. It's been to get devs to use a million applications. And Neon's goal is very much like scale to zero Postgres. I actually think it's very different than Supabase. It is from their marketing. So I would say you're not wrong, but you're wrong in your supposition of Supabase because we've had a conversation with Paul Copplestone on this podcast,

and I thought so too because we're fans of Neon. I'm a fan of the idea of serverless. They're one of our sponsors, so this is by no means net. I just happen to have this glimpse into this world of the compellingness of neon and in particular what they did with retool with retool building retool db on top of neon spinning to zero yep i can go on it was just it's just amazing that neon built that kind of thing for a player like retool to build on top of so that they didn't have to spend a year building the same thing

just to offer RetoolDB and instant databases. That's my long story short. So I have a hot take here if you want it, which is that if Neon was an easier company to work with, Supabase would be running on top of Neon. Oh. Because realistically, Supabase needs what Neon has, which is like Supabase needs what neon has which is like super base needs small postgres to be cheap and so because neon is not as easy to work with as i think they should be

super base just there's like there's just no world where super base builds on top of neon and this is i actually have a lot of history here because like when we were pitching fly to investors i had this whole rebel alliance idea like we're going to do compute well, somebody else is going to do database as well, somebody else is going to do X well. And the reality is no startups are actually very good at working together, both for good reasons, like they have competing customer priorities, which is why we're not really been successful in using Supabase to offer managed Postgres to our users because Supabase has entirely different user needs than we do.

It doesn't make any sense to make a good Postgres for us. But I think that companies are just, we're all still competitive in some ways. In a lot of ways, I think that, my guess is that Neon sees a future where Supabase doesn't really exist because they're going to grow to take it over. But the reality is what Neon is really good at

is what Supabase could actually take advantage of. That's why they've got the Oriel DB thing going, which is great. I love more open source Postgres alternatives. This is good for me. Yeah. You mentioned the phrase Rebel Alliance. I didn't know that was a public phrase.

It's been public and not. I've actually like, I had a landing page up and I would talk to individual companies about this. Because to me, it's obvious that I should be focused I had a landing page up and I would talk to individual companies about this. Because to me, it's obvious that I should be focused on being very good at one thing. It's like the Unix sharp tools and pipes, basically. To me, it's obvious that if there's a company that's extremely good at compute and they're easy to work with, the next hosted database company should just build on top of but in partnership with them. And the next

object storage company should build in partnership with them and be using that compute. And then our customers use their object storage, which actually worked out pretty well with Tigris. But that's the only time this paid off. Tigris and Upstash are the only two companies that this worked out well for us. And I think a lot of this, in some ways I damaged the company by waiting way too long to do our own managed Postgres because I was like principled about like, we're not going to do a better managed Postgres than anyone in the world. So we're going to wait for the right company to come along and partner with us on this. And then what I've learned is where our users don't care about is they don't really need the best managed Postgres in the world. What they

need is the best Postgres for fly apps in the world, which is not something, which is actually something we should build for them, if that makes sense. And so, yeah, Rebel Alliance has been, you know, destroyed by the empire, whatever you want to call it is maybe a good take. Oh, dang. It's not a real thing anymore. No, I don't think the world's going to shake out that way. There's like some real practical issues here. Like for example, zoom out and explain. and explain? I mean, I'm being limited in my, like behind the scenes, we've had some conversations because of our relationship.

And there's things that we've actually purposely not said on the air because they're your ideas and they're part of your strategic advantage and what you're trying to do. Oh yeah. Can you explain what you're trying to do so that the context is there for the listeners?

First of all, Rebel Alliance is something investors ate up. There's always things you can pitch that you will get a huge amount of funding for that you actually, when the rubber meets the road or whatever euphemism you want to use, don't go that way. So the general belief here was that if you take the top 50 AWS services,

AWS has like 300 services, and 50 of them are pretty good. And like 10 of them are really good. And like 10 of them are really good. And if you, so if you take the top 10 AWS services, there's probably a really big startup for each one of those. There's probably a really big RDS startup. There's probably a really big EC2 startup or Lambda or whatever you want to call it. There's probably a really, that's us, by the way. There's probably a really big, what was the other one I was thinking of? There's like storage ones. There's DynamoDBs, there's really big caching services. Anything you can provision that isn't...

If you go to Vantage, the cloud billing accounting company, they have a top what people pay the most for in AWS. If you look at the top 10, those should just be individual, standalone companies that are building the best possible version of that thing. And the best example I can give of why I think this should be is S3 was innovative in 2008. It made it so I could build new kinds of applications that I couldn't previously build, which to me is what cloud services should be offering. And then it ceased

to do anything. Ultimately, it's not doing that anymore. S3 features are not allowing me to build new applications I couldn't previously build. But then you get Tigris, who I'm 99% sure I'm supposed to say Tigris, but it could be Tigris. I'm going to check after this, but I'm going to keep going with Tigris. I think it's Tigris. I've always called it Tigris personally. All right. Well, we'll go with Tigris then, and I'm going to blame you, because I think it sounds better. It's like a little tail, right, on the team. You know what's funny is I have hot takes about how It's like a little tail, right? On the team. Yeah.

You know what's funny is I have hot takes about how people should pronounce their company names. And then I hear how they say it. I was like, no, that's not correct. And the last example of this was Minio. It's called Minio. That's how they say it. And I was like, no, it's Minio. Like, it should be Minio.

I'm sorry you say it that way. I'm wrong, obviously. How should CentOS be called? Oh, my God. CentOS. CentOS. How do they. How should CentOS be called? Oh, my God. CentOS. How do they say it? CentOS. CentOS sounds like a cereal, like something you put milk in.

Anyway. Well, CentOS makes it sound like a currency and low value. Like eight people that are going to see this know what CentOS is, by the way, because that's just 2008 level Linux knowledge. You'd be surprised. You'd be surprised. Oh be surprised oh boy wait where was i got off on a way big tangent there you were talking about tigris tigris and correcting yourself tigris is basically like the promise of object storage but it allows you to actually build a cdn like you can basically run a you can write some javascript use tigris and you have a cdn

baked into your application. You couldn't build anything like that before. You could try and do this with S3, but it's so complicated to manage multiple regions of data that it's impossible. And so my general, it's like Supabase for Postgres is like this. Supabase is a Postgres that lets you build new kinds of apps or build apps faster, like really gives developers power. And so the rebel Alliance idea was like, if the future is developers are picking cloud platforms, the best possible cloud platform for developers is 10 companies that have built a very special version of infrastructure that makes developers more powerful by itself. And then obviously developers would just use those 10 to 50 things together. Like why would they use my object storage when I could use Tigris?

Why would they use my Postgres when they could use Supabase? Why would they use my like GPUs when they could use Replicate, for example? And I think it's like, I don't know. It's one of those things that like, I could still rationalize it. It seems like a thing I'd really enjoy,

but there's actually like huge structural problems with it, which is what people tend to want when they launch an app is actually a really consistent UX that solves a higher order problem than, than they can solve by themselves. So like a pass like Heroku, like Postgres isn't a product. It's actually part of the product. It's a feature of the pass. And so you can do cool things like do PR reviews with your existing Postgres data, for example. And so it's, so there's like a UX issue here where you can't actually solve problems as well with 10 to 50

different companies as you could, if you were just doing it all yourself. And there's like weird compliance issues. Like one of the things about getting a HIPAA BAA, so you can do a healthcare app is you actually end up having to sign one of those with each of those 10 companies. You can't just do one HIPAA with us, which I think is a real, like a real burden for developers. I don't think they want to do, even if you can unify billing, I don't think they want to do multiple contracts with companies. You know, it's just like, it just creates more and more friction. So like there are actual practical issues with like a rebel alliance cloud, but also I think that a lot of it is just politics. Like There's just very few companies who have a low enough ego to give up a big chunk of potential revenue like that.

Like us saying we're not going to take the Postgres revenue is pretty big because EC2, I mean, AWS, most of AWS's profits come from RDS. That's like a huge market that we just said, hey, we're not going to have this, you can have this. And that's not a thing most companies would be saying. In some ways, we needed a company to come back and be like, fine, then we're going to give up the compute revenue, you know? And that was actually relatively rare to find people who were that communist. I don't know. Anyway, that was very rambly, but I'm very

fascinated by how this all went because it still seems like it should be the ideal state, but it's, I don't, I don't believe that's going to happen anymore. What's up, friends? I'm here with Cal Carberry, co-founder and CTO at Coder.com. So Coder.com is a cloud development environment, a CDE, and you run all the clouds, AWS, Azure, GCP, you run on-prem, and you're no stranger to competition, right? The competition out there is well known, but what shocks you? What surprises you about the state of cloud development environments and how developers are leveraging them?

You know, it actually shocked me. The majority of our largest provision customers do not use containers with their development environments. They actually use VMs on like GCP, AWS or some kind of mixture of them. One of the largest auto manufacturers, they have like a little bit over a thousand devs that use Coder every day and they use a mixture of Azure, AWS

and GCP. So I've used Docker, I've used VMs, but take me into the technical details. What is it that's different between a VM and running something in Docker? Kind of like all existing solutions, like kind of our competitors in the market, all really have a container-based approach where you build like a Docker container and developers work inside of that. And it faces a couple of limitations because, you know, Adam, like if, you know,

on your machine right now, 100% you're not working inside of a Docker container doing this discussion, right? It's just very different. So there's a lot of software expectations that actually don't really work inside of a container. An example is a customer of ours is Square, and they do stuff with a payment terminal. And so they need essentially like hardware accelerated Android. That is just really finicky to get working in a container. You totally can pass DevKVM into a container and get hardware accelerated virtualization, but it's a little trickier and a little more janky. And so they'd rather just be like, no, the simple thing is give everyone a VM.

There's no point to change the way that we work in entirety to do some weird virtualization jank. It just makes more sense to give them a VM that we know works. Well, it might be time to consider a cloud development environment. And open source is awesome. And Coder is fully open source.

You can go to Coder.com, get a demo, or try it right now, or even start a 30-day trial of Coder Enterprise. Once again, Coder.com. That's C-O-D-E-R.com. Coder.com. so you're you are pro rebel alliance you thought this would be the future of how fly would grow because you would say well i don't want to do postgres because there's neon or super base or somebody else that can do that. Someone's going to do a very good Postgres,

and I want to give the very good Postgres to our customers. I don't want to give them another Postgres. And now you don't agree with that. So are you planning to build out these other pieces? Well, I've changed it a little bit. So Tigris worked really well. Upstash worked really well. Upstash is doing our Redis, and they have a unique take on. So like Tigris worked really well. Upstash worked really well. Upstash is doing our Redis

and they have a unique take on Redis that I think is really good. Tigris has a unique take on object storage I think is really good. Both of those companies are kind of like egoless in the sense that they're very comfortable working with us on these things. Like Tigris isn't out trying to find new servers

to run their kind of like compute on because they're comfortable kind of like sharing the benefits of this with us. They're comfortable doing their thing and us doing our thing and leaving both of us. Well, it'll go well for both of us. Both of those, Tigris in particular, like one of the big problems with Postgres

is like we have to run it on our own hardware or it's not very good. And so all of these people who've built clouds like Crunchy, Crunchy is a good example of this, but even Supabase, people who've built on top of AWS aren't necessarily incentivized to make it work on our infrastructure too. And so we can't just use them as is. They actually have to do a lot of work to make this happen. I just want another tangent. So your question here was like, do you think this is now how, oh, right, we're going to build some things ourselves. And actually, when I've talked to companies about this, there's a couple of things that I want for our users that I have gone to companies now.

And I've said, we're going to build this. I'd rather give them what you're doing should we work on this together. And so it's become, if I reroute them for years, that's what I do with Postgres. I'd say, we're building managed Postgres. I like what you're doing. I think it'd be a better thing to offer to our customers. Should we, should we like, can we work on this while we build managed Postgres, you know, along the side and then make a decision when we see kind of which one's better for users. So we have a thing we're building that I would like another company to just do on top of us

and we'll see how it goes. And you're not saying what that company's name is. Or the thing. We are building managed Postgres, though. So that's coming. What do you think you can add to that, then? If Postgres will run on your servers and to share a slight marketing part of your story, globally distributed, so when you launch on Fly, you can be anywhere.

Basically, you've solved that problem with your networking and your machines around the world. How will you solve that better or differently? Well, so the reality is, and this has taken me, we have a lot of devs signing up each day to launch their applications. And so the problem we're trying to solve, so here's my pitch on Fly lately, not pitch.

Here's what I think about what we're doing. When people come in and launch an app, that's a business that we should do well for them. It's sort of like a long-term funnel. And so we're shipping managed Postgres because it will make those people more successful. It will keep them on the platform longer, and it will help them get kind of down deeper sometimes into what we're able to do for them. To me, the thing that we do the best is we get compute running anywhere in the world for whatever you need it for. That's it

and the past like the platform as a service stuff takes advantage of that but it's not like we're trying to out compete heroku necessarily like we already have a ton of users coming wanting this we don't have to like justify this to anyone we just need to you we need to like do well for the people who are already there which actually took me a bit it's really hard to look at something and be like we need to do really well for these people and let go of, we also need to convince them this is the best choice for them because it's just not important. We really have no pitch to do for the people that are coming to the platform right now. All we really have to do is check boxes for them and they

stick around and grow and we're all very happy. It's almost like relief in some ways. We're going to ship really good deploy tools for people we're going to we're going to end up shipping um i think we might have already had but it's going to get better like pr review apps right like at first it's like heroku pipelines is really good we shouldn't even do anything if we can't do better than pipelines and now it's like our users actually need very specific things for pr review apps we'll just do that and literally ignore what everyone else is doing because it's irrelevant. And so we're not even really pitching. Stuff like running close to users is a thing that makes our app perform better. Their app perform better when they launch it. And people legitimately notice that.

But we're not really putting it in their face. It's like when you run your app, and we've still got tweets. People are like, wow, I launched my app in Tokyo, my dumb little Rails app. And it was really fast and I've never experienced that before because all my previous Rails apps have been in Virginia or Amsterdam or whatever. And so there's still huge benefits that I think keep people around, but it's not like a pitch, if that makes sense, which has been a big mind shift for me. And now truly the big pitch is we have compute that's safe like really good sandbox compute. And like one of our biggest use cases right now is people running LLM generated code on machines because it's, it's in fact, like I think something like 60% of our revenue is people are using machines

as sandboxes for some reason or another, they've sort of built their own platform. That's either LLM generated code running in a sandbox or people taking a traditional full stack app and letting people run kind of untrusted JavaScript or whatever as part of it, if that makes sense. Yeah. Well, I do want to talk about the cloud, so to speak, the developer cloud, so to speak. But I also want to talk about the I suppose the business side of things to some degree as well.

Like, what does it actually take to place these bets to stand up your own hardware I mean that's what you alluded to this slightly with Tigris they built on top of Fly and they had no ego as you've said and they're they're maybe it would be challenging to go and rebuild on a different cloud if fly failed or began to fail in ways that was not suitable for them because they're betting on your hardware right they're betting on the bets you're you're betting on which is you want to put your own hardware out there control your own hardware across the globe you want to build your own stack on top of that you're not building on top of AWS you've built your own machines and they're on those machines and they scale when you enable them to scale if they need to be on

RAM or on very fast disks they're waiting for you to create the new colo stack in the various places so they can add this new feature set to Tigris for example they're not doing that themselves they're not building their own servers. They're leveraging your servers. That's how the cloud works. But they're uniquely positioned in the fact that their foundation is you. Yeah, and there's a couple of things there. One is we still have to do better than they could do themselves. And I think that's a funny problem

because we are, but it's sometimes hard to convince people of that. I think we're all very prone to be like, oh, I can stand this up in 10 minutes. And then you take the problem on. And it actually feels better sometimes. It's nice to have everything in your power. It's nice to own all the things because you know where to go to fix stuff. It's really hard. That's what DHH's tweet was about.

It's really hard to wait for someone you don't have a good relationship with to go fix things and so what we're actually doing what they're taking advantage of us for right now is not only so like we run our own hardware and networking for for basically economic purposes we need to have a good business we need to make good margins this is a this is a good way to control costs and also make sure things like are kind of optimal for what we need so like we can buy the best mix of cpus and memory and disks for a given piece of hardware because we kind of know what we need the most and we can avoid when there's like supply constraints on things we can work around that for example and this is what we did with gpus like we couldn't get a100 so we got these l40s and that worked

just fine for us because we knew it would. We weren't kind of at the mercy of paying four times as much because we didn't have this level of control. So what Tigris is getting from us is they're getting all of our run global compute, including a load balancer bit, at scale that they don't have to build. And even if you go to someplace like AWS, you end up just building the same thing on top of another cloud and then they also get the economic advantage so like they we make a little money when they buy hardware but in general they're paying close to what it would cost them to buy similar hardware for themselves and then we make a little money

when they no we don't make any money we they we don't we don't make money when they push bandwidth anymore like we're kind of of giving that to them at cost because a big part of their pitch is free egress because this is a big deal to everyone but AWS. Only AWS can get away with charging insane amounts of money to move a gig of data out of S3. And so they're kind of benefiting economically. They can do these things.

They can sort of punch above their weight because we've already done a lot of this work. And then they can technically punch above their weight because we've already done a lot of this work and then they can technically punch above their weight because we've already got a lot of this infrastructure in place but it still has to stay pretty good for them it has to stay pretty close to better to what it than if they were just doing things themselves and so that's the that's the over time i'm i'm actually like i'm in some control of this but i'm actually i'm actually really curious to see how this plays out with them and us and which things that we can continue doing better for them and which things to say scale, it makes sense for them to take on themselves.

Really good example of this is they probably need cheap, slow discs at some point. And a lot of them, and we have absolutely no reason to ever buy cheap, slow discs for anything we're doing. It's just not an important part of the product. And's not a thing we... And so I would expect that when it comes time for them to do cheap slow disks, that's obviously going to be a thing where there's a pretty good chance they won't use us for that. And that's fine. It makes total sense to make those decisions for things like that. Probably for cold storage, right? They're going to have some active storage and to make the storage cheaper over time. Yes, exactly. And I think for what they're doing,

we have an article about Tigris we're going to post, but it's not out yet. But one of the things we talked about in there is like, S3, all of the engineering work in S3 right now is going towards storing more data more densely for cheaper. That's like their entire goal in life is basically to optimize cost underneath. And Tigris is going to have to do that too because they're in this stage where they want to acquire customers and storing a lot

of data on our nvmes is not cheap enough for what those particular customers need and it's because of things like cold storage but even even more like granularly it's like almost nobody needs all their data available on nvme at any time. And we did this because we want to run transactional databases. But for cramming stuff into object storage, you have a lot more power to be very precisely optimized on the cost of storing an individual four megabytes, for example. So there's definitely going to be stuff they do outside of us because it makes total sense for their business to do that. And what I'm actually most curious about is how much that Venn diagram continues to overlap. How much of what we're doing makes total sense for their business and how much they diverge from us over time. Yeah, that is interesting. I think the promise of

and I think there, I want to harp on this for one more second, not so much to promote Tigris necessarily, but I think this is an interesting take where you've got not just an application that somebody can build on top of Fly, but a full-on company slash service that without Fly, otherwise they would have had to build it on a cloud they're trying to compete with, which is challenging, right? Or the other option would be to do what you've done, which is build the servers, define the CPU, the RAM, the storage, stand to themselves, and build these things globally

to even be able to offer the basic promise of what Tigress is trying to offer. They would have had to do so much extra to even get there. And they're a unique kind of developer to come to fly and build something of substance within a year and be respectable, and respectably competitive even they're also they're an interesting case too because they're very important to our customers like everyone who runs an app needs a place to put user uploaded images or whatever like object

storage is a critical piece of almost any application people ship these days and like previous to tigris we were like here's how you go get your s3 bucket which is 47 steps and here's how you hook it up to your fly app which is one steps. And here's how you hook it up to your Fly app, which is one step. And now it's just one step. We got to get rid of 47 steps, which is great. That's an exaggeration by the way. I don't know if it's actually 47, but it's definitely double T6. 75, actually. I counted. And not everything is like that. That's true for Redis. It's true for Postgres. It's true for object storage. But there's not a lot of other things that every app, every full-stack

app on the planet couldn't take advantage of in the same way. And then the other unique thing about object storage is it's actually kind of hard to build object storage and get traction from developers because you're not really there at the right time to get picked, if that makes sense. If I'm building and launching an app and I need to go find object storage, I'm probably just going to go get it from S3. I'm probably not going to like spend any time looking for someone else to sign up directly with because it's just really irritating.

And so one of the big things and one of the big values for Tigris, I think, is like they sort of get access to our signup flow. All of the thousands of developers a day who are creating accounts on fly can get Tigris through that signup. And if they do deploy an app, they can add Tigris to that app they're deploying.

And I think it's a relatively unique kind of like pipeline for an object storage company that is hard to replicate otherwise. Upstash did the same. It's because like they did both us and they're like a Vercel add-on. It's like you can't use Redis without the application. So like go where the app developers are going.

Hence the alliance, right? I mean, you could charge somebody the value of being accessible to the developer during the problem set versus like a command away built into the fly cli for example i mean like wow you've really given them such a nice red carpet and they're walking on it yeah we've gotten even better like right now if you launch an app on fly we'll take a guess of if you need object storage or not and just offer it to you so it's a we can actually like see kind of what apps need when at launch time and just just bundle that stuff in again you can see the draw of the rebel alliance but i think i think what tigris is doing with us is unique and it works because of basically all the things we've just talked about and upstash in a similar way and i don't actually think there's many other

companies like part of the reason both these companies worked well with us is because we were bigger than them when they got started and it's uh i do think startups i mean you can't afford to have an ego when you're launching for the first time. And so like, that's the right time to like, you know, give up on some future and go faster with a company like us. So that it's, it's like, I think, you know, we've managed to bypass a lot of the friction to these types of things with those two companies. And maybe those were the only two that ever happened. We'll see. So you believe in the Alliance.

Now you don't really believe in the alliance as the future. I'm assuming that's probably a byproduct of some version of failure or a failed relationship or the fruition didn't really come to full fruition, for example. Can you give me some examples of where it just didn't pan out as you expected or wanted to? Yeah, I'd probably phrase that as I hope for the alliance. I'll be happy if it happens. And I'm not betting investment. I'm not betting our future on it or company money on it anymore.

And Postgres is the best example of where that happened, where if we rewound to 2020 and just shipped managed Postgres, we'd probably be five times bigger than we are right now. You would be. You know why? We talked about that. Remember that? Yeah. That was like one of the things we really wanted to come to fly for was we didn't want to manage servers yeah obviously we didn't want to specifically

manage our postgres we wanted to have our fly and eat it too which is a terrible analogy or phrase like i don't eat flies but you know i'm gonna uh i asked uh render in 2020 if they would do postgres for us so like this was not and this was not a fast thing it was like i spent four years basically being find a really good postgres for our users and it went everywhere from like companies just wouldn't like um i think that there's a bit of like actually one of the big problems database providers have is that they are kind of whale driven they have their huge customers that pay them a hundred thousand dollars a month for a database which is not what we're doing we're not bringing them a hundred thousand dollar a month customers and they don't necessarily know how to contextualize this bottoms up get a bunch of developers on the platform thing

there's very few that do so like super base we made a really good effort with and i think both paul and i would tell you that we both needed to do different things that made it so like we couldn't spend the time solving each other's problem. Like if that makes sense, like Supabase doesn't need to do the things on Postgres that would make them work on fly otherwise. And so it doesn't make any sense for them to work on that stuff. And then we don't need to be like shipping something like EBS, which is something that can make Supabase's databases work really well. Like really resilient single volume storage is just not that important to us. And so that was like, we like tried really hard and I think both of us would still wish it had worked. And it just, it was like, it became clear this was just going to take forever.

It wasn't even like a big blow up. It was like, this is really ponderous. Why don't we just not focus so much on it? And then there were a couple of people that were just like really prickly to work with. I think that there were just some that were, like there were some difficult Postgres providers out there that I think I could have gotten to play ball, but they weren't really buying the vision. They were just trying to make a lot of money off of us, if that makes sense. Right. They were less alliance and more leech.

Yeah, I don't know if leech. They wanted us as a customer and not a partner, if that makes sense. The distinction is always very small. But they didn't really want to be peers with us. They didn't really want to bet on a future where we're both doing well. They really just wanted to sell to us and other people. I think that was all of it. The other thing truly is that,

if you're running app servers on fly and not using a database, we're not actually very sticky. If you get pissed off with us one day, and this is where I've thought a lot about this because we have, we have kind of operational incidents just like every other cloud. And so like maybe something goes wrong one day and we, we break a hundred, hundred, you know, people's apps and those hundred people move off. Or more commonly, someone's just not having a good experience on the platform because it doesn't do what they need, even though it's working the way we intended it to, and they move off.

And I think the biggest problem we have is that if you're not storing data on the platform you're using to host your app, it's really easy to leave. If you are actually storing your Postgres data on top of Fly and also running your app on Fly, you're much more committed, I think, to the platform. And the reason I said five times bigger is I know exactly how many customers, how much retention has been an issue for customers without databases. And you can sort of go into a spreadsheet and actually do the math on what we sort of turned down.

And it's not because we waited on the Rebel Alliance. It's because we could not give customers a reliable Postgres in time. And that's because I was very stubborn about waiting on the Rebel Alliance. And I still think it's the ideal outcome. But we're just not going to make – it's just like, well, this is – got smacked with reality or whatever. And so instead what we're doing is, um, we're actually working with Percona and doing our own managed Postgres with basically with Percona's backing because I've done managed databases before and it's not fun and it's hard and it's hard in a way that I don't think people expect, which is actually hard to be DBAs for thousand developers. What's up, friends? I love my eight sleep. Check them out. Eight sleep dot com.

I've never slept better. And, you know, I love biohacking. I love sleep science. And this is all about sleep science mixed with AI to keep you at your best while you sleep. This technology is pushing the boundaries of what's possible in our bedrooms. Let me tell you about 8sleep and their cutting edge Pod 4 Ultra. So what exactly is the Pod? Imagine a high-tech mattress cover that you can easily add to any bed but this isn't just any cover it's packed with sensors heating and cooling elements and it's all controlled by sophisticated ai algorithms it's like having a sleep lab a smart

thermostat and a personal sleep coach all rolled into one single device. And the pod uses a network of sensors to track a wide array of biometrics while you sleep. It tracks sleep stages, heart rate variability, respiratory rate, temperature, and more. And the really cool part is this. It does all this without you having to wear any devices. The accuracy of this thing rivals what you would get in a professional sleep lab. Now, let me tell you about my personal favorite thing. Autopilot recap.

Every day, My 8 Sleep tells me what my autopilot did for me to help me sleep better at night. Here's what it said last night. Last night, autopilot made adjustments to boost your REM sleep by 62%. Wow, 62%. That means that it updated and changed my temperature

to cool, to warm, and helped me fine tune exactly where I wanted to be with precision temperature control to get to that maximum REM sleep. And sleep is the most important function we do every single day. As you can probably tell, I'm a massive fan of My 8 Sleep,

and I think you should get one. So go to 8sleep.com slash changelog, We'll see you bundle it. Again, the code to use is changelog, and that's from November 11th through December 14th. Once again, that's 8sleep.com slash changelog. I know you'll love it. I sleep on this thing every night, and I absolutely love it. It's a game changer, and it's going to change your game. Once again, 8sleep.com slash changelog.

And also by our friends over at Wix, I've got just 30 seconds to tell you about Wix Studio, the web platform for freelancers, agencies, and enterprises. So here are a few things you can do in 30 seconds or less on Studio. Number one, integrate, extend, and write custom scripts in a VS Code-based IDE. Two, leverage zero setup dev, test, and production environments. Three, ship faster with an AI code assistant. And four, work with Wix headless APIs on any tech stack.

Wix Studio is for devs who build websites, sell apps, go headless, or manage clients. Well, my time is up, but the list keeps going on. Step into Wix Studio and see for yourself. Go to wix.com slash studio. Once again, wix.com slash studio. So if you thought that RDS and you knew RDS was such a boon for AWS in terms of revenue, this is four years ago you knew this. We had conversations because I think it's been about three-ish years, I want to say, maybe four years. Ten years ago I knew this because we even had a whole startup basically offering a managed database. Remind me the name of that? Mongo something it was called mongo hq at first we renamed it to compose and then it got absorbed by ibm and then uh people

didn't get fired for buying anymore so you've been in this game for a while long enough to know what you should do right knowing the value of a managed database, the difficulty of doing it even, but in particular to Fly, knowing how valuable it could be to your future, but yet you bet on the alliance and you punted. Why? Well, so there's the startup tension. Sometimes if you know too much about a problem,

you talk yourself out of doing it. Like running managed databases is a giant pain in the ass. In the same way running global hardware infrastructure is a giant pain in the ass. But the difference between managed databases and global hardware infrastructure is I'd done one of those things before and realized how much of a pain in the ass it was. And I wasn't gung-ho, naively jumping into a problem without realizing the downsides. And I think one of the problems with like, it's always interesting to me that people start startups, I don't know if this is true, and it's probably not, but

I'm really aware of people who start startups, they have no real credentials for, not credentials, but they don't have the right experience to build this startup. And in some ways that's an asset because they're so naive that they don't even notice what they can't do. And so a lot of times they end up finding stuff that seems impossible to people who know better. And so like for me, like managing databases is a really known complicated problem. And there were two things at play here for us in particular. One is I'm like hyper-focused on like doing something novel, which you might've noticed when I was talking about people that come and sign up and just want to run their apps.

I've had to really let go of like, I'm not trying to do something novel for them. I'm trying to just give them a good experience based on what they already want. But I'm hyper-focused on doing something novel. And I'm very skeptical of doing something everyone else is doing that's really complicated and hard. And so databases fell in that for me. It's like, I know how it is to run databases. I also want to do something.

I want to like put all of our energy into doing something that's really meaningfully different than what already exists out there and so i skewed way hard to let's do the meaningfully different than that exists out there which in some ways wasn't wrong because we got this machines api three years before people needed to realize they needed to run like llm generated code in a safe environment like we didn't know llms would even be writing code at that point, but it was a thing that we kind of saw the need for vaguely and needed for ourselves and managed to ship. But I think that like I over fix it on how hard managed databases were.

And then a component of that is like, and so I know what it takes to run a managed database. And it's really just a lot of people who know how to operate that database and a lot of tooling that lets them know when to go look at a customer's problem and do something about it. And so like, that's kind of why we opted for Percona because they're really good at running people's Postgres. And so we know that like within 15 minutes of us noticing an issue with the customer database, we can get a hold of Percona if we want and have them looking at it with us, which is the key, I think, to a managed database service from day one is just fixing problems so people don't have to.

And it's almost like a human element. It's almost like a human and support problem or less of a product problem in some ways. Did Percona build their own hardware across the globe? What's their stack? No, we are a customer of Percona and we're actually using all of their kubernetes percona operators and tooling so like what we actually ended up doing is shoring up our like

we shipped fly kubernetes service fks someone on twitter the other day was like you should name it something other than fks because that sounds like someone's like no that's that's that's on purpose is fks for that reason so we will keep. Are you a Silicon Valley fan by any chance? Oh my God. Yes. Then you know where I'm going with that, right? This guy. Vaguely.

Wait, you got to say it. You got to tell me, cause I'm going to laugh again. Jeez. I'm, I'm blanking on the person's name. He's the VC. Gosh, what is his name? Oh, uh, the, the, the doors that go like this and not like this. Yes.

That guy. It says this guy f**ks a lot. That's right. That's right. Yes. Uh, that's not why we named it that but it's not it was not an accident that is fks anyway we shipped this um kubernetes runs really well on top of fly machines and we hadn't quite we didn't have all the features in it we needed for like bog standard

kubernetes operators to work properly and so like the first actually the what we did was we decided we're gonna just we're gonna run out of the box operators from Percona to start. We're not going to fork any of this. We're not going to solve problems from scratch. What we're going to do is make our Kubernetes work well enough to use Percona, which is a, was a, it's a little counterintuitive, but it made sense for us. So like Percona has a bunch of products for basically launching, managing,

upgrading, doing backups for all of the things you'd need to do with databases on top of Kubernetes. And we're kind of building around that. And part of the reason for this is we know we can go beyond that at some point. But we don't want to start with something like Postgres major version upgrades, for example, are like a nightmare to build. And there's zero reason for us to build this. It already exists. It's like that's obviously something we shouldn't spend time on.

And so Percona is a bit, it's like a basically, it's like a build or buy vendor that we've decided to buy from, if that makes sense for our particular users. And I think that one of the neat things about what we're doing, because I'm in some ways,

let go of the novelty of it, is we just want, we don't need anything novel for Postgres. We need really reliable Postgres for our users because that's all they're asking us for and so i don't have to like come up with a vc pitch for how our managed postgres is going to be you know world beating because it's just not the purpose of this thing it will be world beating but it's only because it's not it's doing what people are asking for instead of what i'm pitching to vcs if that makes sense very interesting well i'm excited for you that you've, you know,

four years later, you've come back to where you began and where we began. I mean, we really came, that's not the only reason, but one of the many. I had an advisor slash investor basically shit themselves and I told them we were going to do our own Postgres service because they're actually looking at what PlanetScale and Neon are doing.

And these are what I'd call like exotic database services. They're actually like being, they're actually building like serious, serious engineering to like change how Postgres does storage or make Vitesse, which is that infinitely scalable version of MySQL, like develop the actual database engine themselves. And I think that the neat, the neat thing about like watching Amazon on this is like,

we don't need those things. We really just need RDS, which is the vanilla version of this database. It just works well. And we can charge whatever we need to charge to make that happen. So it was kind of funny to actually start looking at what investors see as the Postgres market and compare it to what we actually need to do and how very different it happened to be. I think your use case is different, obviously. It doesn't have to be full-on Neon because you're not trying to attract someone who would manage fleets necessarily. Maybe, I suppose, on top of you.

Maybe I actually get back to the same problems to some degree. You still have serverless, right? It would still be managed. It would still be serverless. What I need is something that works well for people who spend 25 to 2500 a month on their database and that's that's basically like that's it doesn't need to be less than that and it doesn't need to be cheaper than that so but yeah maybe get back to that i think that you could run neon on fly i think this is the cool thing is that like you can actually build the exotic stuff on top of us someday for your own customers that's just not what our customers need. What's stopping somebody from tiger-sing the neon, so to speak, on fly?

If you can build a neon on fly... Well, that would be neon doing it, and they're just not... It's not something that's going to work out. It's like that's not how their company needs to go. I think one of the things that happens with companies is they launch with like neon raised so much money they launched with huge expectations and we don't like you don't your ego is necessarily big if your expectations are big does that make sense like you look far forward and be like i'm not going to give up that part of the market

even though it may not be relevant at that time it's like no we have big expectations with money we're going to do big things and so uh it's neon not building neon on fly made sense but that would be the company that did it there's not like a there's not really another one yeah there's been a couple of small ones have you heard the conversations of us talking about uh our cdn saga have you paid attention though no i'm gonna do my best because I'm less in the details. Gerhard and Jared are deep in these CDN saga issues. And I'm going to try my best to not be negative. But we've not had the best experience with our CDN. It's been challenging. We've had some challenges and they seem insurmountable.

And so we essentially came back to, well, we really, we need a simpler version. It's almost like what you just said with, we don't need, you know, speaking for you, we don't need to be a PlanetScale or a Neon. We just need this RDS, this sort of like simpler sliver of Postgres, whereas the same for us. People go to CDNs as a media company to have infinite needs right and we don't have those infinite needs we have very simplistic needs but we still need the kind of crux of what a cdn is for our little you know indie media company and we have uh this thing called pipe dream we'll talk about it next Friday. Actually, this Friday. Sorry,

this Friday officially, and then it'll release the following Friday on our podcast. So, it's December 4th, listeners. Kurt, it's December 4th. You know this. So, not Friday the 7th, the 6th. Yeah, 6th. It's like Friday whatever next week. I'm not in front of a calendar. I'm trying to do math in my brain. 13th. We'll go with 13th. Friday, the 13th. Oh, gosh.

Well, it actually is, too. Good luck with that. Okay. Could be a reason for that. Who knows? So, our idea is let's build a really simple CDN for us on top of Fly. And so, that's what we're currently doing. I'm not sure if it will be the future yeah but for a while it's been an experiment a toy let's let's see if we can actually do it

doesn't make sense can we solve our own problems can we build this little thing on fly and the reason i bring that up is because i said well could you tigresson on fly? And well, maybe we don't need to be a Neon on fly. Maybe we just need to be our own version of our own CDN on fly. And it's our own. We never had to go and build at least servers you build. We never had to go and, you know, globally distribute CPU and compute like you've done.

We could just leverage the fact you've done it on our own. And maybe potentially it could be something that's usable by other people because it's just really simple. It's everything Cloudflare is, everything Fastly is, and others that are like them, but just the simplistic version of it. The varnish layer, the simplistic varnish layer, not the complex crazy crap. That's actually really exciting to me because this entire company exists because I was

annoyed that there was no cloud I could build a CDN on top of, if that makes sense. As an individual developer, I could not ship a CDN because Fly didn't exist effectively. And so actually, I was really excited when we launched Tigris because to me, that was the last bit of the puzzle I would have needed to build a CDN. And so I'm fascinated you all are doing this. I love that you say simplest because CDNs do lot of like really interesting stuff that you may not need, but like really at the core of it, you just put a file somewhere and they make sure it's fast for other people in other places, which is all like cramming something in Tigris does now. It's just like, it's just there. You don't have to. And even Fastly at the time i remember when fastly got big because

you were talking about digital ocean with ssds and fastly took off because they were a cdn with instant purge it was like that simple it was like they went to all the media companies and said when you ship a typo that's really embarrassing you can purge it and nobody else will ever see it like within seconds it's not going to be there for another few hours, which is what was happening with Akamai and others at the time. And so it's kind of funny because the infrastructure will now support Instant Purge. You don't need a CDN to build a bunch of shit for you to do that anymore. You just need to use Tigris effectively and then have a button that deletes an object from Tigris and you're done.

Yeah. Or just uploads a new one. Anyway, that's really cool. I'd love to hear more. What stack are you building this with? Is this Elixir? So I'm not building the application. Gerhard is building it for the most part. I think Jared's chiming in on different details. It's being built on Varnish. Oh, nice. So we're not using Tigris at all.

Oh, that's interesting. You should have them look at Tigris and see if that changes how they build it because I feel like Varnish is even harder than I think it needs to be. kind of thing because we've been uh this is in the weeds a tiny little bit but we've been bottlenecked by our inability to move to the next thing when it comes to cdn and much love to fat to fast they've been amazing to work with over the years but there's challenges with there's a lot of challenges i think in particular like they're the vcl inside of fastly just to be very specific is not versioned right so you know, you know, Gerhard and Jared, two developers on our team, I would chime in too,

but I would just like, just, that would just ruin it. It would be the worst. They have to coordinate like humans would coordinate like, hey, I'm working on the VCL right now. Don't touch it. Or this is the version of it

and export it by copy and paste into our own Git repository. So it's shadowed by version. it and export it by copy and paste into our own git repository so it's shadowed by version it's like even something that simple like that's innovation at the fantasy layer that we would absolutely love yeah but it's just not there or api is changing and things break for us like why is our our fees not updating why are these things happening oh yeah the api changed and we were not made aware of this api change like i think it's kind of prudent to tell a developer when your api changes yes i mean and maybe they did and maybe they did i don't know right that's actually

a hard problem is communicating this stuff to people is actually incredibly difficult even if you decide to do it so i'm not trying to say they're bad i'm just saying we've had some hurdles over years you know over years with this and they're aware of it and i'm and they may even be listening right now so i'm really sorry we had to bring this up but it's just oh somebody there knows some yeah i mean they pay attention to any time we talk about fastly for some reason shape or form like it's it happens Cloudflare are fascinating to me because in some ways they're doing things on hard mode because they got big and then had the money to do things

in a way that wouldn't make any sense to people like us. We originally started four iterations ago. This was pre-2020. We shipped a multi-tenant JavaScript engine for just running JavaScript at the edge, which is just like Cloudflare Workers. And then that didn't do what we wanted.

I got big companies were happy to come buy this and build stuff on top of it, but I wanted individual devs to just ship apps. And individual devs were not interested in writing JavaScript for some unknown platform. And I was always grateful that we didn't have the captive customer audience that Cloudflare does, because Cloudflare has so many customers,

they ship multi-tenant JavaScript, they get enough traction from it, they think it's successful. And the reality is those customers were just willing to use more of Cloudflare features. It wasn't attracting new customers at the rate that we needed to as a startup, for example. And Fastly is really similar because they did this instant purchasing. It was all based on Varnish. And when you start with this black box, like how you evolve there from there is really kind of hard.

And we got really lucky because at some point, and this, I don't want to say this is like, because I'm smart. It's because it wasn't working. My brain from flipped from like, I want to build a CDN that devs can take advantage of, which is where you'd get scripting CDNs and customizable VCL and all of

these things into why are we building like, like proprietary stuff for the CDNs and customizable VCL and all of these things into why are we building like proprietary stuff for the CDN when in theory you could just have a cloud that lets you run a CDN on it pretty easily. And like, I'm really happy we flipped for that reason, because I think that there's probably people within both those companies that understand how constrained their path has been. And it's all because they were successful. I'm not going to say at the wrong time. It's because they were wildly successful and locked them into this decision that doesn't make any sense if you're starting from scratch anymore. And I think VCL is the version of that. And then they also, when Fastly did the Wasm stuff, it was the same way. I was like, wow, this looks like a project a company does when it has too much money to spend

and isn't being forced to be pragmatic about how people use the thing. So so anyway it's just really interesting you're all experiencing this because i've watched specifically those two companies for like eight years at this point and i've watched them kind of be at the mercy of their previous choices in a way that like um cloud provider infrastructure hasn't been and it's quite the same way let's time box this when i'm about to share to five minutes or less that's a good code for talk less kurt be more efficient i love no no no not at all i just i want i have bigger things i want to talk to you about but i'm really

i just put this is all open source so i just shared a url with you here in riverside so go to that url and just peruse briefly the code base because it's very small. Just give me a glimpse and an initial reaction. This is, I wrote, one of my favorite things I wrote for our blog was called the five-hour CDN. This inspired it. Yeah, okay. Yeah, I love it. Yeah, we actually, so Jared, it's quoted here.

And on a podcast, we do these shows called Kaizen, which, do you know the word Kaizen? No. It's Japanese for continuous improvement or always be improving. And so we've, of many pillars, give them what they came for, keep the main thing the main thing, slow down and check yourself when you're going too fast, and Kaizen. Like these are the four pillars of our psyche when it comes to our business. Yep. And so Jared, on a podcast, on a kaizen podcast where we're

introspecting what we're doing and i've shared with you our challenges and now with the rest of the podcast world that's listening jared said i like the idea of having this like 20 line varnish config that we deploy around the world and it's like look at our cdn guys and that's it like and so that's what he said in the podcast and so so Gerhard Lazu, our resident SRE and friend for many, many years now here at ChangeLog, prior host of Ship It, the podcast, et cetera, he's still involved in all the things we do. He planted that seed in his brain and went away and over time brought up this idea, this pipe dream. Jared called it a pipe dream.

Could we actually do this? Could we build our own CDN on fly? And your blog post was fodder for the possibility and enablement, so to speak. And so we said, well, is that even possible? Should we even do it? And I was like, no, because I want to work with a partner that does it. I don't want to manage more code. I don't want to be responsible for our CDN. So here's me thinking as a businessman around this EDM media company, no, we should partner and get them to pay us because that's how it should work. We should choose a major winner,

enable a symbiotic relationship, and share our story with the world through how that works out. That may not be how this ends up working out. So this is still a pipe dream. That's why we call it pipe dream because we're not sure if it will work out, but this is it. A single purpose multi-tendency DN for just us that runs Varnish Cache. It's open source. It runs on fly. And that's what we're

at so far. Oh, that's really cool. You've got me thinking I should go spend the weekend and just do this from scratch and see what I'd come up with. Because like, since I wrote that blog post tigers exists, which is, I think I might do it different now, but maybe I'm wrong. Yeah. I apparently need my, I, uh, I cope with burnout by spending a week writing a little demo. So my last one was called B fast it's bash functions as a service. And it was. And it hooked up to the ChatGPT API, and I said, write me some Bash, and then it would run it in a machine. And I was actually using it to see if I could hack our own machines.

And ChatGPT is really good at writing exploits, so that was kind of fun. So this may be my next one. Interesting. So, I mean, in light of this and having one and a half minutes left on this brief part of the conversation is we've considered, well, if this does make sense for us, who else needs a really simple CDN? Yeah. That's not so much anti-FASD or anti-cloudflare, but just, it's just bloated. We don't need all those features. We just really need something simple. Maybe we could flesh out what is pipe dream

into a tigris and be part of this alliance so we've all seen how my predictions go with rebel alliance but i have this little bit of a hot take that like in the future like cdn features will probably just be part of your app not necessarily a whole separate service which is a my take on that is i think that now like you get to CDN, it's actually expansive because it's everything from like DDoS protection to bot abuse protection to like optimizing video streams as they flow through and all kinds of stuff like that. But for actually just storing kind of chunks of files and getting them back to users pretty fast, I feel like that's just the thing apps will do.

It won't be like an entirely separate service anymore. And so I'm very curious what your exploration finds for this. And I actually would love to ask them, I'd love to talk to them and be like, I'm curious what the benefit of a separate service is from your existing Phoenix app for something like this. Why does it make sense to have a CDN as a bolt-on and not have the Phoenix app just be doing this work? We should do a podcast about that. We should. We should invite you on a Kaizen and talk in depth about the possibility.

I've been meaning to do a Twitch stream of building something, and I actually wonder if the dumbest CDN ever on a Twitch stream would be a fun thing to build. My version, Kurt's version, like Taylor's version of the Taylor Swift songs. Sure, sure, sure. I really love this, though. Actually, this is the exact type of thing that I love seeing on fly.

It is like, you can't do this on AWS or DigitalOcean or Heroku or anywhere else. It only works here. It's very cool. Well, that does bring me to not exactly where we should go, but at least a version of it. You're building a cloud for developers who ship.

That's your current on your homepage tagline. And I love that because it used to be, you know, apps close to users. And that's great too, but that was not, and like, why does that, I mean, to some developers that makes a ton of sense. I think the cloud for developers that ship to me is if you want to be a productive developer,

that's been my rationale for why fly continues to make sense for us because that's who we are dovetailing that completely off of technical conversations and more so and maybe slightly technical but you've had to build this company you're still an individual human being you've built companies before like how how are you doing personally as part of this journey? Not CEO of Fly, but that too, of course. But how is your life as a result of building what you have to build to build Fly? Oh, yeah.

Today, it's good. I think that, boy, if you go over the whole journey. Okay, this is like dark-ish, dramatic right we'll go dramatic the most interesting thing i've learned from this company about my personal life is how much my work has been a thing that keeps me like energized and not depressed and like a happy human being and it wasn't until literally i didn't start therapy until a year and a half ago and i should have, I know everyone like I, 10 years ago I'd be like, yeah, I should probably do therapy. But like,

you just don't get around to it. And the reason I started therapy is come is work got hard and I also was married and had kids and all that was also hard. And it was like, my therapist finally told me, he's like, you have three things in your life and there's work, there's family,

there's relationship. And it sounds like work has been giving you all of your emotional energy for like your whole adult life. And you're not necessarily getting it from the other parts of your life. And I thought that was actually really fascinating because I've always noticed that people who get to basically the stages of company we were at, for some reason, they get divorced at a pretty good rate. Like I've noticed there's a lot of founders post-series B.

Again, not data, but like an observation uh and i'm kind of wondering if that's that's why i wonder if we're all like self-medicating for some kind of depression that exists in our other lives by trying to build a company and make it successful because like the the successful moments certainly keep me going yeah when they happen for an inordinate amount of time and so what happened when like a year and a half ago, I started therapy is like the company become real work and it was fewer of the like bill head rush endorphin moments and a lot more of the God, I got to get up and not commute because I work from home,

which is almost harder sometimes, but I got to get up and do this today and there's stuff I don't want to do today. It absolutely has to happen and there's things I haven't figured out. I don't know where this is going to go and I wish I could just be the type of person that had a real job and enjoyed a salary and also liked going fishing over the weekend or something. But that's just not ever what I've done. I would say that the company itself revealed a lot of...

It went far enough. And my previous companies haven't. I don't remember feeling that way. Even the last company we sold, it took me far enough to actually go actually work on this particular part of my brain. And the good news, like the really, what I'm actually exceptionally happy about is like, I'm actually getting emotional energy from all three areas now, like kids, relationship and work at different times. It seems much more balanced in my head. So like, we talk about things like outages and DHH's tweet on September 1st. And I guarantee I did something else that week with either a relationship or kids that was like made me feel good that week. And I wasn't like I had to.

It helped me get through the DHH during a shade thing for us, if that makes sense. Yeah. And so that's been the biggest thing is I'm great now. But it did definitely. It was a pretty good forcing functions for a lot of the stuff that I probably needed to take care of. So it sounds like you've gotten divorced. Yes. Okay. And I know you moved from one place to another. I think you live closer to me now. I live in Texas. I'm in New Orleans, New Orleans. So you're not, you're about six ish, maybe seven hours away. Yeah.

A good drive. We basically moved as the marriage was ending. It was like a little bit of a last gasp. And I think, I don't know if everyone's marriage is like this. I've actually talked to a lot of people, and nobody really talks about getting divorced because it's shameful and makes us feel like failures as grown-ass human men. But my marriage, I think, was like so many others

where it was long gone. That's the time when it ended. But I can tell you many many years ago when it actually ended if that makes sense and the rest of us the rest of it was like realistically one of the things like that did come up in therapy was like i was convinced that marriage is ending were bad for the children like i just believe that to my soul and that's not actually the case like there's actual studies about this and it's it's in a lot of cases it's far better for kids when a bad relationship ends and they'm just sitting in the toxicity for their whole childlike lives yeah there's a lot of i'm sure there's a lot of uh evidence either pro or against that sentiment but i don't disagree like it's i think it's like

anything where it's far it's really just more nuanced it's not absolutely true either way it's very situational but there are both kinds of marriages it's like it can go both ways and it's not absolutely wrong for kids to like end a parent's romantic relationship effectively you're good though right you're good now things are better you're on a good path therapy wise even yeah I think that the thing about an actual divorce is it's almost like a relief when it finally happens. Like all the bad crap was before that. And since then it's been like, Oh, okay, cool. Now it's, now it's, now I know what I'm supposed to be doing and it's winding this up. It's like learning. One of the weird things is like we had a baby and got married in college and I never spent any time alone before. And so I spent a good chunk of the weird things is like we had a baby and got married in college and i never spent any time alone before and so i spent a good chunk of the year like learning to actually be content for a

week at a time when i didn't have my kids uh by myself and not just go drink and you know get get plastered because i'm hiding from it but like actually be happy the thing i the stupid thing i never used to watch tv shows by myself and then i learned if i build a lego set while i watch tv i can actually get through them and it feels really good and i have a good time so i will do lego tv date nights with myself now nice do you uh do you watch lego cooking by any chance no oh my god that seems like a thing i should watch it's on youtube search it okay and the rabbit hole goes deep yeah that sounds like a rabbit hole go deep it's so good my kids love it it's cool it's so cool it's so well produced

that's hilarious i i don't want to share any more because i don't i mean no that's that's exactly everything i need to know and definitely don't share anymore yeah i don't want to share anymore you'll love it and there's tons of folks on YouTube who are doing cool stuff with Lego, obviously. So maybe you can build Lego while they build Lego. I don't know. But anyways, that's cool. What kind of shows are you watching? I will do – well, so I watch a ton of movies now.

So I've been watching – I loved Ted Lasso, so that variant of show where it's like a comedy that makes you sad sometimes. Oh, yeah. It's a fun one i've been meaning to watch the good place because everyone loves it and i never actually watch it neither i had a i've had an easy time getting into that one obviously i watched all of fallout on hbo that was really okay i haven't watched that i do like the they have to be they're not like high class stuff i can i can barely watch like something that's serious and not entertaining for 10 episodes but i can watch like anything that's good that's both funny and sad or like fun adventure is is

excellent do you listen to books or read books i mean i say listen because i listen to a lot of books more than read i read books and in fact actually one of the things that as i was going through my fun, emotional, self-healing journey or whatever you want to call it, I actually stopped reading when things got really bad. And one of the things I realized is I was actually reading, using books as an, sort of an escape. Like I only read escapism books. So I'm back to reading now and that's excellent.

I did just leave my Kindle in an Uber. So we're all very sad today. But generally I like to read and I can't, I actually discovered I can't listen to audiobooks unless I've already read them. And then I actually really enjoy listening to the audiobook if I've read it. Really? Yeah. Okay. What about an audiobook that's only an audiobook?

I'd have a hard time. I tried this in the car because we drove like four hours on the way to Thanksgiving last week. And my mind wanders away from what I'm listening to. And I realize i've missed 25 minutes of something like pretty so i probably couldn't unless i was doing legos i used to be the same way yeah you might be need to be preoccupied where you can be semi-focused dishes lego something like that try try that i'm going to recommend a book because of the book as well as the reader. Okay. Okay.

So, on Audible, there is a very well-known narrator. His name is Ray Porter. And for me, I can listen to a lot of books because he is the narrator. He's the voice actor, so to speak. He does tons of different voices. He's not overly dramatic, and he is amazing. And my favorite author, or one of my favorite authors is dennis e taylor and he wrote a book series called baba verse baba verse yes sir i've read them okay so am i am i like listening to them so you'll love listening to them then so if you're a

fan of the baba verse ray does an amazing job narrating now so baba verse book they came out originally on audible and not in print so now they're in print oh i didn't know that yeah so they i mean this is like i think 2017 might have been when he first launched uh the original book but i'm a big fan of babaverse series they're amazing as audiobooks and if you like audiobooks then i think you'd really like those books yes no kidding wait do you want another book suggestion? Sure. So the Babaverse books are not the same as, but actually remind me a lot of, have you read Children of Time by Adrian Tchaikovsky? I have not. Probably a good audiobook. It's an excellent, like sci-fi. I'm very nerdy,

so I call things speculative fiction when they're not like The Martian where it's like heavy science-based sci-fi. It's sci-fi. It just doesn't need to be all the physics behind it. Let me give you a new name for that then. What's that? Plausible science fiction. Yeah, that's exactly what it is.

It's amazingly good. It's possible. It's probably not going to happen, but it's possible. Yeah. Like, Boba versus a stretch. I can imagine at some point in humanity that's a possibility right exactly it's not here yet today but there's a lot of things that align with that being somewhat possible or plausible to be true yep children of time has it's similar

to baba verse because it has a um there's like a huge amount of time that passes so you can see things happening externally that you wouldn't necessarily get to watch as a human being which i thought was really cool that was my favorite thing about bob versa it's like you can play with time scales and you can have like whole novas happen and see the effect on the universe around you when you don't have to care about time anymore which isn't the yeah they would travel for light years and that was like whatever just go to sleep who cares i wondered if he realized i wonder if that was intentional or he sort of just discovered that as he was writing these because i thought that was a really neat thing to explore yeah i think it's cool how he talks in uh milliseconds you know versus like for a second and like i paused for you know a brief millisecond or a millisecond or whatever

it might have been that's uh that's kind of cool in my opinion just immersing in that world anyways i love i love uh i love audible books in particular with like ray porter you know you'd look up him as a narrator voice actor and you'll find a lot of great books and that's how i uh that's how i discovered other great books as well but interesting so you're doing good so doing great yeah in terms of the future for fly how how has it been what not exactly asking a funding question necessarily but like how solid is the future of fly so i have a weird take on startups we can basically keep operating fly as long as we want to it's that i'm kind of like at some scale, if that makes sense. Like we have a pretty good established business. We have a lot of ways we could tweak it to make it like

profitable right now, for example. But I think the future is still huge. And so like we're spending, we're burning money to try and get big still, because I think there's like a huge opportunity for our particular company to be like, the thing I tell people is I want it to be enduring and have an impact. Like I built a company, we sold to IBM, basically gone now. Uh, I have a nice car. That was cool. But there's like, just no, no, nothing I can just keep thinking about for the rest of my life. And I'm like, kind of, I really want to keep working on this forever. And I think it would have to be, that's to keep growing.

Or I kind of get antsy, I think. And maybe that's not true as new self-healed single person but it's probably true and so like we're pretty healthy uh but i think the future is still like you know it's a kind of a toss-up if we're going to get where i want to go or not if that makes sense it's like uh there's a lot of threats to a company like ours there's a lot of we're basically competing with monopolies and in particular we're competing with monopolies in a in a time in the u.s where like people like monopolies there's not a lot of work going into limiting kind of the power of giant companies like there was 40 years ago or whatever and so there's there's huge risks to what we're doing

the thing i mentioned about earning the reputation that lets you have outages and people people are just like oh i guess we you know just got to deal with this like everyone else. That's sort of an existential threat. There's a world where we can't be perceived as being good enough for companies to want to spend money on us. But I do think this, I keep talking about the LLM on machines thing. I do think the thing, I think we have an incredibly good business of people coming and wanting to run their apps on us. And I think it goes very deep because there's a lot of really valuable, good workloads where we can like, I think the trick

for a company like ours is people need to be able to theoretically spend a million dollars a month on the exact same product we're selling and you can get big. And so like, I think a lot about Heroku who, who you couldn't necessarily spend a million dollars a month on Heroku. It's just, it doesn't go that deep. And I think we're in a really good spot there because we've got kind of the depth of the platform there and we've got a really good business we can build down to that if that makes sense we're not raising money anytime soon and part of that is because we don't need to it doesn't make sense i'm not there's not it doesn't make we can't necessarily spend money faster right now to grow faster i don't think we're to that stage.

And also, why would you raise money right now? Oh my God, it's terrible out there. So we're just batting down the hatches and not for another two years and hope the world changes. Is that a helpful answer? That is a helpful answer. You know, I'm the most skeptical person on the planet. So anytime anyone asks me that, I'm like, I got to tell you all of the things I'm worried about when, in fact, I'm actually like drinking my own Kool-Aid, like people are still coming to work here and people are not leaving.

And it's like, like, this is, this is incredibly like, I just have no reason to want it to end. It's actually, it's amazing. It's, it's like all the hardships worth it because it's, it's so good when it's going good. That's all I got. That's all I got. That's all I came here for. I think there's probably more we can uncover, but I think it would just go way, way deep.

And we've got limited time for you to exit stage left on, on time for your next thing. So I know onto my next call and go see why a cat is yelling. That's a new one. So I'm going to go check on this cat. Yeah. All right. Well,

thanks Kurt. Yeah, no problem. I will talk to you later. Have a good weekend holidays. If I don't talk to you again before next Well, thanks, Kurt. Yeah, no problem. I will talk to you later. Have a good weekend holidays. If I don't talk to you again before next year. You as well. Okay. Big fans of fly around here. They're sponsors, they're partners,

they're friends. I've known Kurt for many years. We've known Kurt for many years. We're long on fly. It's the home of change law. I can't help that. That's how it works. But this conversation with Kurt was necessary, needed by me. I'm a big fan of Kurt. I wanted to know what was going on with fly and I really hope you enjoyed the journey of this conversation. So the end of the year is coming soon. We've announced a new era of the ChangeLog podcast universe. We've teased the bright future we have planned. There's still a budding future called CPU.fm. What I ask of everyone in this moment is patience.

Give Jared and I time to percolate these ideas, to get things into motion, and to continue to serve you with amazing developer podcasts, whether it's our podcast or us supporting other podcasts through CPU.FM. We have a big plan. We have a big vision. Just be patient. That's it. Okay. CPU.FM. Enter your email address if you want to be notified when it launches officially or the easiest way honestly is probably to just join the community go to changelog.com slash community we have an amazing a very thriving Zulip and you are invited come join us and as we speak there are many many people

going to changelog.fm slash s-o-t-L. And what they're doing is sharing a message, an audio message, that we'll include on the episode of the final episode of the year, State of the Log. You'll get your very own Breakmaster Cylinder remix of your voicemail, so don't delay, changelog.fm slash S-O-T-L. That stands for State of the Log. Get them in. Also, don't delay, changelog.fm slash S-O-T-L. That stands for State of the Log. Get them in. Get them in.

Yes, a big thank you to our friends over at Century, Jasmine Cassis, joining me to discuss their future with session replay and what they're doing with mobile replay, Sentry.io. Use our code CHANGELOG. Get $100. One, zero, zero, buckaroonies off the team plan for free. Just go try it out. It's yours. Sentry.io.

And to our friends over at Coder, Coder.com. Love them. Love what they're doing. So cool. It's open source. And my sleep has never been better. Eight Sleep dot com. Their awesome pod for ultra is so cool. I sleep on it every single night. I love it. You should get one. Use our code changelog. Go to eight sleep dot com

slash changelog. Sleep good. Sleep well. Sleep amazing. And to our friends, Changing the Game at Wix Studio. Check them out, wix.com slash studio. And yes, the VM's coming in, the voicemail's coming in. We'll get a special Breakmaster Cylinder remix. And of course, we love Breakmaster Cylinder.

They're awesome. The beats are banging. So good. Okay, we're done. That's it. We'll see you on Friday. Bye.