Supper Club × Flightcontrol with Brandon Bayer

Welcome to Syntax, a podcast with the tastiest web development treats out there. Today, we have Brandon Bayer on, and he's gonna talk to us about, his company flight control. We talked about flight control On the episode where we compared a lot of the different, like, platform as a service hosting providers, Netlify, Vercel, Railway, render, all those things. And we added flight control on there because it was it's relatively new, but I think it's really interesting where It answers one of the questions of, like, why can't you get a Vercel like experience Mhmm. But use your own AWS account? And I'll let him explain a little bit more, but that's kinda what we're gonna get into today and and and whatever else we pop into. So welcome, Brandon. Thanks for coming on. Thanks for having me. Hey. You're welcome. So, give us a quick rundown of, who you are, what you do, all that good stuff.

Sure. So, Brandon, as you said, I am the creator of Blitz JS, which people might have heard about.

Could launch that back in 2020.

Sort of like my idea was to create a Ruby on rails style experience for react in JavaScript, kind of based around Next. Js.

And we didn't really, wasn't really able to pull that off, but did kinda create a nice little Sort of toolkit slash starter kit for Next. Js, for building full stack web apps. And like, one of the big parts of that was RPC, Which is now being built into seemingly every web framework, which is kind of cool.

Yeah.

So, yeah, so, so did that, but, was working towards creating my own company, ended up doing that. We'll talk about that.

And outside of work, I am a airplane and helicopter pilot. So that, that's where the, the flight plan Flight control.

Yes.

A flight control. Yes. Flight control aesthetic. It's, yeah, I love the little, like, take off the airplane, take off and stuff on scroll. It's all very, very sad.

I I have a story about that, and I don't often show my stuff show my wife stuff that happens on Twitter, but I I went and showed her immediately when I saw that you went to a conference and you literally flew there. Is that true?

That is correct. The past couple conferences I've been to, I flew myself.

Oh, what a baller move. So you How long have you been flying planes for?

I had I really started my pilot training when I was 15.

Got my license as soon as soon as I turned 17, which is the minimum age, and basically been flying ever since, although there was an 8 year break in there where I didn't have time or money. Yeah. Yeah. I can imagine that's that's not a cheap hobby to have, but that's so cool to be able to just

fly to a conference. What are the logistics like for Flying in for a conference. Like, how do you even do do you have to let them know, here's my flight plan, here's when I'm arriving? Like, what what do you even do for that? I just get in my plane and go.

Oh my gosh.

Wow. Basically, I mean, I I, so I do a little bit of flight planning. I check, like, where's the closest smaller Or to where I wanna go. And then, check who are the, what's called the fixed base operators, the FBOs on the field, which is basically like which businesses there And see, like, check, do they have parking, and how much does it cost? Make sure they have fuel, and then check the weather. And I have to keep an eye on the weather because, small planes are are not as good in weather, and I don't have my instrument rating yet, so I can't fly in in bad weather.

But as long as all those things are good, then I just get in and go. Wow.

It's incredible.

That's sweet. Do do you ever just, like, go for dinner In a different city? So I have done that for lunch, in the past. I haven't I've just been too busy.

Yeah.

But I just bought this plane 3 months ago.

Okay. And so I I've been busy, like, working on it and flying to conferences. It's been a busy summer, so I haven't got us Done everything I wanted to do yet.

Yeah. That's a good excuse that you're working on a plane.

I've been able to fly.

What a what a write off, man. You can a little business expense. Just a a casual plane. That's pretty cool.

Yeah. I met your, I met your cofounder at a conference a couple weeks ago. I didn't realize he was Canadian as well. What's his name? Mina. Mina Abadeer. You probably met him at, Tailwind? Yeah. Yeah. At the Tailwind, he's he's from the area, which I thought was kinda interesting because I joked that We should get a helicopter. The the tailwind event was in Cambridge, which is 45 minutes away from me, about an hour, hour and a half away from Toronto. So, like like, it's it's a decent decent place. And I was like, I wonder how much it costs to rent a helicopter. You get couple guys in the helicopter, but You literally you literally probably could have picked us up if you wanted. Yeah.

Cost $300 to an hour to run a helicopter. 3 to $500 an hour

Depending on the helicopter. Yep. Okay. And that's for a 2 seater. Oh, okay. Okay. So you can split that with 9 guys. Like, I we Like a couple of times in my we've rented a limo with a bunch of my friends, and we would take a limo. We'd all have $15, and we take a limo to the city and go clubbing, you know, it it worked out, but certainly have not done that with the helicopter yet. UberX. Yeah. UberX for helicopters.

Alright. Well, let's talk about what flight control is.

Give us a rundown of what that is, please. Sure. So, you know, most I think most people Probably listeners are probably familiar with traditional platforms as a service like Heroku, Brasil, Rinder, Railway.

And all of these platforms are, you know, really abstractions over AWS or Google Cloud, something like that.

With the whole idea to make it easier to use because, Like, if anyone's used AWS directly, like, we know how how kinda complex it is, how low level it is. It's kinda really what it the big the thing is it's just very low level, And you have to kinda build whatever you need from scratch.

And so all these platforms like have been really amazing, providing a really great experience.

But what every almost every large company has found out that has started on Heroku, for example, Instacart started on Heroku, But eventually, they reach a point of scale where Heroku is no longer viable because they don't have the control over the low level infrastructure that they need. They don't have as good security, and these platforms as a service are more prone to have reliability issues since, Like, not only do you have the underlying AWS thing, but then you have a layer of custom software on top of that that you're dependent on, and That is a shared infrastructure that all users are going through.

And so, you know, my cofounder and I both have, You know, I kinda experienced this. We're using the platforms as a service. Like, we really want that good developer experience, but we just got too frustrated with the limitations.

And I was like, I really wanna use native AWS services. Like, think about SQS and DynamoDB and some of these things that are, like, Really incredible services, but I don't want like, how do you use them? It's, like, too hard. And I was like, why can't I have this good developer experience On my own AWS account. Like, theoretically, like, this should be possible. Mhmm. And so that's that's really the whole premise here is that I think the future is bring your own cloud platforms.

You get you connect your own AWS or Google Cloud account, And so you retain all the ownership of it and the control, and it and then that platform is sort of like a could be more flexible,

Providing more or less automation as your needs change. Yeah. And that makes a lot of sense because, I mean, the the cost, I mean, all of those things in the platform, whether it is, you know, one of these platforms that's built on top of AWS, the cost then gets, you know, shoved into the user where the users have having to pay for that platform on top of AWS.

They're having to pay for The infrastructure as well as, you know, the development into that that platform when in reality, you know, the things that they really wanna use are just the underlying tools. The underlying tools have such a a bad experience to work with. It really seems like this is such a a push in The right direction there in terms of being able to give you the best of both worlds there. Yes. That's that's definitely the what we're trying to go for is the best of both. Nice. So FlightControl is a

paid service that you sign up for, and you connect your GitHub account to get your Access your source code and you connect your own Amazon account. You go through the whole developer process and getting keys and whatnot.

And then basically, it's just like a remote control that makes things a lot easier.

So, like, again, it's still running on my Amazon account is using my billings, using my credit card for that type of thing. But flight control itself is something that I pay for That makes that sort of makes all of that easy. Right? Exactly. Because and maybe you can answer this question because we've asked a couple people this. It's like, why doesn't Amazon make this easier. Like, why doesn't why don't they have that? And everybody's always like, oh, Amplify does that, but, like, why is nobody u using that then? Cause amplify

is, pardon my language, trash.

You know, amplify has the same problem That traditional platforms of the service do. Amplified, completely abstracts it away, and you don't retain the underlying control.

So it's it's sort of like a a whole new thing. It's like a black box that you haven't, like, if it supports something, you get it. If it doesn't, too bad.

Like out of luck.

But why I, I think, I think, you know, it's just really hard for companies to do many things And you really kinda only do one thing really well, and Amazon does low level primitives really, really well, Arguably better than anyone, and that's what they're good at. And so they keep trying to, you know, create these new abstractions.

There's app runner, there's amplify, but ultimately they're they they're not worth much at the end because That's not what Amazon is good at.

You know, it's kind of like the Linux philosophy of do one thing and do it well. And so let AWS do the low level primitives and then Other, tools and platforms like TerraForm or flight control can fill in the gaps.

Awesome. So let's go. We've had this show on our list of shows to do, which is called straight up Raw AWS.

It's named something a little different, but I'm not sure I can I can say that on the internal? Yeah.

But I would like to kinda go through the different pieces of building an application, and maybe you can tell us What parts you might choose out of the AWS stack? Because honestly, that's sometimes the most overwhelming part of AWS is just simply being like They literally offer everything. Like, I was using their transcription service the other day, and I just went into their their library and their whole NPM repo, and it's Massive.

They're on such a massive scale. So many developers work in there.

So let's start with the first one, which is often What I want to do when I sign up for AWS, they tell you to upload a zip file to deploy a serverless function. It's just like That's, like, the worst first experience I've ever had where you have to upload a zip file with the node modules in the zip file. And I was like, no. I wanna Check my my GitHub account. So, like, how do you get build pipeline, continuous integrate integration? I wanna get Push and have the whole thing build and deploy like it does on Vercel.

Well, I mean, that's very complex.

It's exactly, like, why why we built flight control.

You know, but you essentially have these, like, you know, the very first step is build your code.

And so what a lot of people with AWS do Is they end up using CI somewhere, whether it's GitHub actions or CircleCI or AWS has a native version called code build, And that can build your code.

And then, you know, typically that is gonna be packaged into an image.

So there's a bit more containers, but sometimes serverless functions. So you're either gonna take the raw files or an image, and then you have to get those files, like to, a serverless function or a container.

So, you know, you might end up uploading that to s three as an intermediate step or to an image registry. Okay. And then what do you do?

I think I'm a little bit more interested in, like, how does flight control piece all of these things together, you know, because, like, that's what's so nice about it is there's literally a 1,000 different services, and I'm able to use A bunch of them to do the the full stack there.

Sure. So flight control makes us a lot easier.

We give you sort of an easy mode and, like, a more advanced mode. The easy mode works exactly like Vercel or Heroku where We automate the build for you. Under the hood, it's currently using AWS code build, which is actually kind of trash also.

But it gets the job done now. We're gonna be replacing that later this year with a blazing fast build system, that should rival Vercel's build speed. Mhmm. Right now, it's a bit, you know, a bit slower. But So that'll be great. So that's the easy mode.

Just bring us your source code, we'll build it for you. We'll take care of the image creation and everything.

The more advanced mode, which traditional platforms don't support is, you give us an image that's already built. So more sophisticated teams like to build their own image and upload it to an image registry. And so you can connect that image registry to flight control, and then we'll take it from there.

So that that's the 1st stage is building your code.

Either you do it or we do it for you automatically.

The next stage is Creating the infrastructure.

This is like the most complex part because you probably want a CDN in front of it, And then behind the CDN, you're gonna need a load balancer. So this is talking about containers. And then you need to run the container, somewhere, and then manage auto scaling and all of that.

So flight control just handles that seamlessly by setting up the CloudFront CDN for you. So you get everything StaticAssets and stuff very fast. You get the load balancer. And behind that you get Fargate and ECS.

So that's elastic container registry or sorry, elastic container service.

And that is like, like people have probably heard of Kubernetes sort of a different version of Kubernetes.

Okay.

And so, yep, that's just all automated

for you. Maybe just give us a quick rundown of of what Kubernetes does. I I always As someone who's never used it, I assume that is some sort of application that will auto scale up and down images for me. Right? Like like, Docker might handle 1 image, but Kubernetes is this monster that's saying, oh, give me 7 more images of this thing. People are loving it. Yes. So Kubernetes is a sis container orchestration system.

So it, you know, it will spin up containers, make sure they're Healthy, set the CPU and memory for them, you know, increase more for auto scaling or or or reduce that.

And so it's it's, an open source container orchestration engine where ECS is a proprietary Amazon one, which is simpler Mhmm. But just as just as effective and just as powerful. So I think, like, for example, Figma. I think if I if I remember correctly Figma runs all of their servers on AWS Spark eight.

Yeah. It's interesting because you know you always hear, people who work in Kubernetes just talking about the type of complexity it can add to your your stack. So it's good to hear that this is more simple. I haven't worked with it myself before, but with with something like CodePipeline, I know with with CI stuff to take a step back, like, there can be issues Like user error stuff, or with AWS or or with any CICD system. Do you find that users using your system sometimes, get confused about like, let's say there's an error in their pipeline somewhere or maybe perhaps it's like an edge case on on code pipeline or something. Do you do you find people, like, Using your system maybe possibly would think there might be an issue with your system when really it's it's a code pipeline issue or something like that. Is that is that a common,

occurrence? In in the early days, whenever the system was more buggy, then, yeah, We we had this tendency of, like, anything goes wrong, even a runtime, users are blaming us. Like, hey. Something's wrong.

But as as we got to be much more stable, now it's people usually are are blaming themselves even if potentially it's our problem.

Yeah. Is that like a user interface kind of thing that you you're able to understand how to how to surface those things better to users? Or is it just a a maturity thing? I mean, To some extent, there's always gonna be the

the CI issues that, like, there's there's this long tail that you just you're gonna have to deal with.

But yeah, there's, there's things like we wanna add AI stuff into our build system so that, you know, we can potentially surface more intelligible, like, Hey, this like Help you find exactly what the error is or how you might fix it, and you kinda write there in in your face instead of you having to go Google it yourself or chat GPT yourself.

So, yeah, there there's stuff that we can do around that also. Nice. Okay. So we have our our container. We have our,

container management. We have our, What else we we had our CDN and pipeline. Yep. Build pipeline.

Yeah. What else do we need to spin up to get something going? So then you have ongoing deployment. So we had the build, Creating infrastructure and then ongoing deployments. How do you, like, when you commit the code, how does it get in, you know, updated in production? So we We support get push deployments just like the traditional platforms, where like, you can have a branch that's automatically deployed, Or you can have it be manually deployed, so user has to go in and manually trigger it. Or you can use deploy hooks, webhooks that will trigger that. And then we also support preview environments Oh, yeah. Which is a whole another beast if you're doing it from scratch.

Oh, yeah.

Yeah. That the preview deployments is is something that I almost take for granted on a lot of these things. It's just like, Oh, I sent a pull request. I can literally build the entire website in a different URL and have it running and be able to check it out before it goes. Like, That used to not be a thing. You just have to, like, pull it locally or just merge it. Looks good. Hopefully, not there was a problem. The subdomain with Yeah. And so those appointments, do you like, what languages? So is it serverless? Is server full? Just JavaScript, PHP. Can I what can I do there? Yeah. So just kind of level set everyone on what flight control supports today. We support deploying any language,

any framework, anything, Everything under the sun.

Currently we only support containers, not serverless functions.

Serverless functions should be coming later this year. So we have servers, background servers that don't expose the public, HTTP port.

Database, which is RDS, Amazon's, relational database service, static sites, and Redis.

And so those are like The 5, like, most common services that you're gonna need to really deploy an application, and so we support those as traditional Your your normal production deployments, but also for preview environments.

So instead of just getting your front end As a preview environment, you can also get your entire back end database, background workers, and Redis

all deployed as a temporary environment for end to end testing. That's awesome. And here here's a problem I had once. I left the pull request open for 2 months, and I realized I got charged for 2 months' worth of, running 1 server, but still, it was it was kind of expensive. That was the nice thing about Heroku is that it would The word we always use was spin down. You know, like, it would stop if we weren't using it. Does Amazon have anything like that? Amazon does not, but that is something that that we want to add On our side. Oh, yeah. Because you could you could detect that it was not

have been running. Send an notification and be like, hey. Do you still want this or not? Like, You know, like Mhmm. Have a warning and be like, after 5 days, is he gonna sleep? And and that can be even user configured. You can have turn on like intelligent sleeping, for for the preview environments.

We can even have schedules to be, like, you know, sleeping at night. That's actually that's a good idea. Put your website to to sleep at night. Sometimes websites used to have that where, like, this website is not available from 2 AM to 4 AM because they're Doing some sort of migration literally every single night. So it would be nice to put your website to sleep. Open hours for a website. You guys remember when When TV channels used to go offline

Yes.

They would they have, like, a time. It would be, like, 11 o'clock or something, and then it would just Go to Fuzz for the rest of the night. I'm like, okay.

This just seemed normal, and now I, like, can't imagine that ever happening again. You know? I was talking Talking to some friends the other day over beer, we're talking about,

like, Ontario only TV programming. And we have this channel called YTV, And they had, like, reboot and a bunch of their own like, it kinda like kids' TV. Right? And Mhmm. I remember if you got up too early or Just randomly, they would play these, like, 3 d generated.

It just it's like a fever dream to me thinking about it now where it was just like these, like, robots that would go up the stairs infinitely. And then Oh, wow. Like m I think it's MC Escher where, like, the stairs turn into something else. It's Escher. And I just think about that now, and I was just like that. I was like, what? That was so trippy. And I'm old enough to realize, oh, they didn't have any money to to, like, stream a TV show at at, like, 4 in the morning, so they just played these, like, fever dream, renders over and over again.

Wow. I'm gonna see if I can find some of those on YouTube this time. Yeah.

Nice. Let's see. We we've covered a lot of these things, but what about, like, something like,

Events or like chron. So that is actually, something we're getting ready to work on.

So one one thing that, Heroku has that, is the ability to run one off commands in production.

I think render supports this, some platforms do, some don't On on a way to kinda run a run a command in production.

So we're gonna be adding this soon. And then from there, it's just 1 step away from adding scheduling To run a certain command on a schedule.

So Heroku for Heroku users, they have a thing called Task Scheduler, which is an add on that is you know, people will use commonly.

Mhmm. And so it's easy just to run a run a script from your code base, in production. So that that's something we're going to be,

adding for simple cron jobs. What's the AWS service behind the scenes for that? So that is

we I think for this implementation, we'll be actually shelling into one of your running applications. Oh, cool. Okay. Another another way to implement it, and maybe we'll do this for con jobs, I'm not sure, is to spin up a Spot instance.

So Spot instances are, if I remember correctly, they're basically a an instance that like may or may not be there, like there's some more a ephemeral sort of like cheaper, Like, maybe you can't count on them, something, but from our orchestration side, we can basically makes the cost cheaper.

So we can make sure the job gets done, but but more more effective and and sort of quickly.

Yeah. So for more Sophisticated crown jobs and background processes, you should run a background worker, though the worker type. And so this is using something like bull. Js Or some sort of queuing scheduling system,

even temporal. Mhmm. How we use temporal, actually implement our entire back end. What's temporal? I don't know. That that's not just the JavaScript API, is it?

No. Temporal dot I o, Wes. Temporal is a workflow orchestration engine.

It was created at Uber to manage, like, all of their, like, rides and all these things.

And so it's it's it's extremely powerful, and robust.

It's sort of like an abstraction over queues and cron jobs.

Mhmm. And so if you if you just have queues and cron jobs And you have complex processes.

You're sort of like stringing everything together, like jQuery, and it's very imperative. And like, And then, like, it's it's more tricky to understand the state of the system, to have retries.

And so temporal kinda brings, simplify that like async await did for JavaScript promises.

And so you can literally just wait in your code for 30 days and then, like, Send an email or, like, something like this. And so it's it's it's quite powerful. We've we've we've mentioned this on the show Show before. Temporal. I'm just looking at,

I'm not sure if it was this one, but I remember seeing another example where you could literally await 30 days And we come back and hit you. I think it was this one. We did a whole show on queuing systems, so we did a bit of a deep dive into all the different services.

You build you build your setup, and you you get all connected with all of your AWS stuff.

But let's say, you've hired a team of now a ton of engineers who are all AWS experts who just wanna work on the on the bare bare metal. Is it easy enough to, and I I say this word intentionally eject out of this into just straight up AWS,

or are you is there any kind of, like, lock in? So the first thing is you probably shouldn't have hired a A team just to play with AWS? You you got a tool.

That's gonna be much much cheaper, for sure on the long run.

But if you do, we don't have a concept of eject. So, you know, if you're gonna roll your own AWS infrastructure, You're gonna wanna use infrastructure as code, which we we actually have an infrastructure as code feature, but it's a higher level Abstraction, then something like Terraform. But for do completely doing it from scratch, you would use something like Terraform, and you would want to manage all of your own, resources whether it be Kubernetes or Fargate or ECS.

And so eject is not like something you would actually want in that case. You basically wanna kinda create it from scratch.

And it it's we all know how easy it is to just like change the DNS records and redirect traffic to another server. So there's not really lock in, in that case because you have your code, your image, whatever, you can easily deploy it to something else, whether it's a different platform or something you you know that you've constructed from scratch in AWS.

Nice. You know right now it's We are very we're much more closer to the traditional platforms as far as like the level of, Control and things that we have.

Even though we do offer a lot more control and and access than than traditional platforms, But we're moving to open up open up even more and make the system more composable and pluggable.

So that, for example, DevOps teams That wanna manage their own infrastructure, they can actually do that right through on Terraform and stuff, and then plug that into platform, into flight control. And so the DevOps at that point will have the control that they want, and the developers will get a good platform and user experience on the other side.

Nice. And you won't have to pay for that.

You know, pay a massive amount for that experience. Nice. Cool. Platform engineering is the is the term for this. Let's talk about, Nix Packs. Are you able to give us an idea of What a Nix packs is and ideally a little bit of history on the Heroku build pack to sort of give context? Sure. So,

Heroku build pack, I don't know if Heroku Created this. I'm assuming they did.

And this was a way to define the native dependencies that your application needed, Which is typically like a language runtime, like Ruby or Python or JavaScript.

And so Heroku build packs, I think was probably the first to do this. And you would have to sort of declare the things that your application needed. So you would have to add like, if you let's say you have a Ruby on Rails with JavaScript application. You would have to add a Ruby build pack and a Node. Js build pack.

And then, you know, that would have the native dependencies that you needed to build your But it's it's a bit more brittle. It's a bit more manual.

And so Railway, which is another platform of service.

We're building their their platform and they created this project called Nix Pex, Which is created as a more modern successor to this buildpack concept, and it's it's really good in a Couple of ways. One is that it, generates the Dockerfile for you.

So anyone Really that is working with Dockerfiles can use this.

Next packs is just a just a open standalone thing. And so if you're managing your own Docker stuff And you wanna not manage your own Dockerfile, you can use Nix Packs. Nix Packs will automatically detect in most cases, the languages that you need, And the native dependencies.

So if you're using, some kind of like, image processing thing.

Like if you're using ImageMagick, re Ruby dependency, it'll automatically detect and add the native dependencies that you need for that. Oh, yeah. Or Node Canvas is another one that is is Yes. It's

requires a

native build because it's built in c plus plus, Something like that. So yeah. So Next Packs will automatically do that, and then it lets you you have full control to add or change those sort of native dependencies.

But what's really great about it is that most of the times, next packs will produce a faster build And a smaller image size than handcrafting a Docker file from scratch. Why why is that? Do you know? Yeah. How come? Because Docker caching is really, really hard to do well.

Like, I think most people know the core concept of like, you know, like if this line, if a certain line changes, everything after that will be recomputed, but above it is cashed.

But it it's a lot more sophisticated around that because There's things like PNPM cache, so you can actually, like, share a PNPM cache that's like outside of your normal, like, Dockerfile line by line execution, and setting all those up is quite difficult, and Nixfax just handles that for you.

That's awesome.

I always love when companies, like, obviously, Railway, which is probably considered one of your competitors, not directly, but, like, Trying to host an app somewhere, that Railway is certainly an option.

I like when they open source stack like this because I remember Heroku opened up buildpacks And there was other like, lots of other services that said, oh, we just support a Roku build back. Right? I'm pretty sure render is one of them. Right? You can deploy a, something to render, and, it just works. So it's pretty cool of them to do that.

I don't think supports hurricane build packs unless there's something we have to I was also doubting you on that, but I didn't You know what? It was was it DigitalOcean?

That might be. Uh-huh.

Yes. Yep. It was their app platform.

Yep. That's what I've learned. Yeah.

Interesting. I didn't know that. Which is because I remember, like, looking at my build logs or something, and it says it literally says Heroku in my DigitalOcean Logs. I was like, what? What's going on here? You know? And I was like, oh, I Looked into it, I realized, okay. They're they're just using a set of standard build packs to move it from

Roku to digital ocean app platform. Yeah. I I think it's, one thing we get to talk about briefly is like, okay, well, what are the trade offs of something like flight control versus, a traditional platform as a service? And, one is that it just takes longer to get set up. So it it takes up probably about 15 minutes to create the initial infrastructure because, you know, something like Vercel has infrastructure already provisioned kind of behind the scenes Or like something like a railway, and they can just, like, put your code on an existing server.

But since you own the the the your own servers, your own account, Like, you probably don't have a server, just empty server in there running. Right? And so we have to create that, and that takes a little bit of time to provision.

And so there is more friction To get set up. And then secondly is build times, can be like right now, it's a bit it's a bit slower on flight control because of code build.

But like I said, we're going to be building a custom build service later this year that is going to because caching is hard. That's why this this build stuff, right? And the best where where's the fastest build that you ever have? Typically it's locally on your computer because like most of the stuff is cashed. Right. Mhmm. And so we're gonna be building a build service that uses a long running server, that can be can be slept and and optimized, But all your code is gonna stay on the on the on the server.

And so in that case, everything is sort of cached by default, especially speaking of Docker.

Like, all the Docker cache is just there, and you don't have to waste minutes uploading and downloading Docker cache from a CI.

So that that's gonna be really for that. Does turbo repo or NX play into any of that at all? So that is another way to cash, to have like a a shared cash all the way from your developer locally and in production, based on like a third party.

So some people do use that.

It's it can be a little bit risky. Like there's we've had people, Deploy, like, a staging environment to production because they ran the build locally with different environment variables.

Yeah. And then, like, It's the production uses that. You know?