Where Should You Host Your App? Hosting Providers Compared

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talinski and Wes Bos.

Welcome to Syntax, the most hosted website in the world. I don't even know what that means, but today, we've got A show for you where we are going to compare all of the hosting providers for where can you put your website. We're gonna talk about Serverless edge and server full CICD, CDNs, cron jobs, auto scaling versus not, CPU time, wall time, all of that good stuff.

We've put some time into researching. And quite honestly, I have used I think I've used almost all of of these today. Every time I do a new project, I try to always do a new stack and a new hosting provider so that You, the listener, can benefit from my misery.

Yeah.

Yeah. I'm surprised at how many I tried as well.

There's a there's a lot of variety here too in terms of process, UI features,

a lot of interesting stuff. We're gonna first explain What a couple of things are. We just need to get some concepts down first before we get into each of the different Hosting providers that are on there. By the way, the hosting providers we're gonna talk about today are FlightControl, Render, Vercel, Begin, Heroku, DigitalOcean, Linode, Netlify, Fly. Io, Railway, Cloudflare, and Deno Deploy.

And inside of all of those, there's kind of a couple main ideas. 1st of all, we have what type of servers are they running? Are they running serverless functions, which, by the way, serverless functions are The idea that your code lives inside of a function. And when that code needs to run, it goes from its dormant state to running very quickly.

And if that code needs to run a lot of times, then many instances of that function will run. So I always give the example of, Like, if you go to one of the pages on syntax, a serverless function will spin up, render that page. And if we get a 1000000 people try to visit that Single page at once.

It will spin up as many as it needs to handle all that all of that. But if we have a show from 8 years ago that Nobody touches that serverless function will never run. Or if I have like a PDF generation where once once once a month, People need to go download a PDF of their bill from their cell phone provider for 29 days a month.

That serverless function might To dormant and you're not paying for it. But as soon as it's needed, it's not going to be slow. It's not going to have to take up space on a rack. It will just spin up. It uses the idea that Amazon and all these big providers have lots of space, and you're sort of just renting provider time from them. So that's serverless. Then we have server full, which is the opposite idea where Like when you run a node process on your computer, you type node index.js and you run a server. That thing runs until you kill it. So that is we call those like virtual machines, although serverless can also be a virtual machine. But the idea is that you have a long running server. You start it. It runs. It handles all the requests that are coming in. And then a lot of these providers will also allow you to deploy multiples Of those servers to different areas around the world or as you need it. Like, for example, my boss monster, sometimes it runs 1, Sometimes it runs 6. Depends on how many people are trying to visit the thing all at once. So if I send a big email out, The thing is going to get a spike in traffic, but I could just spin up more server full environments as well.

We'll talk about the downsides to that as well. And then finally, we have Edge, which Edge is very similar to serverless, except that it runs The the function closer to where the user is running. So if I run it, it might run-in Toronto. If Scott runs it, it might run-in Denver. If you, The Australians run it. It's going to run-in like a Yeah, Melbourne.

And That's really cool. They also Edge functions have a limited API. They don't have a full Node. Js API, and they are often used as just in between functions as well. Or you can intercept some data and do something, send somebody on their way. So those are sort of the 3 big different places. Yeah. And then Other topics, we we started getting in the

the c's here, CDN, CICD, CPU.

But CDN, content delivery network, basically is a way to store static assets and serve them up from an area like The edge closer to the user. Right? So you're having you're distributing your, assets across all these servers. So that way when somebody loads them up, The information they can get, whether that be media or anything like that, has less distance to travel. You can put a CDN in front of your entire application, as well. There's a lot of different providers that do both CDNs and hosting, like Cloudflare, AWS with CloudFront.

And so there's there's options there. It typically, like with these things, it's it's It's something at this day and age. The CDN feels like it's something you gotta have if you are running a a normal style, just a a straight up server based website or any type of static assets or anything like that. In addition, there's also CI, continuous integration, or CD continuous deployment tools back in the day. You know, if we were deploying a website, you're having to SSH into that server. You're having to do your Git commands or, worse, you're dragging and dropping via FTP, but you were having to manually Deploy things. And nowadays, a lot of these hosting providers provide at least ways that you can automatically trigger Deploys from a specific Git repo, whether that be GitLab or GitHub or any of that stuff, you connect your hosting provider To the repo, and, you either write your own CICD stuff with GitHub actions or you just hey. Hey. Whenever I push to the main branch, automatically deploy to this.

And and there's a lot that can go in there as well, but a lot of these Systems that, you know, Netlify was probably one of the first. So I know Heroku did a lot of stuff like this. Mhmm. But Netlify was one of the big ones that Really made it simple. And then a lot of folks took that same style and said, oh, wait, you want automatic deployments whenever you commit to the main? Awesome. Sounds good. Yeah. We also have Cron Jobs.

Cron Jobs are jobs that will run every so often. So, For example, you might have every morning at 4 a. M, you might run a database backup or every 10 seconds you might want to pull an API and Check for new instances of something so you can it's funny, not all of these services support this type of thing where you need to run some specific code every couple x minutes, hours, days, whatever.

So crown jobs are good. Scaling, I talked about that earlier.

What happens when you get lots of traffic? Does it auto scale? Can it auto scale? Do you need to do that yourself? Do you have to decide that? Mhmm.

Yep.

And and sometimes it's simple. Sometimes it's automatic, and sometimes A simple way to spend a lot of money if you just say, here's my credit card and scale up till infinity.

One more I didn't talk about was, like, multiple environments. So it's very common now to have every time you put in a pull request, to build an instance of that so you can actually see the output Of deploy click on the website. Deploy previews. So most of these services now do that as well.

Let's talk about pricing. How do people charge? We will go through it on each one. But generally, it's either by what's called wall time. I didn't even know this, but basically, If you run a serverless function, you're only paying for the amount of time that that serverless function is running. So it spins up.

You are Fetching a database. You get some data back. You're rendering it to HTML.

Maybe you're saving some stuff stuff to a database, and then you send the response back.

You're only paying for the time that you're using and then it will spin down. It does stay warm, meaning that the function stays Loaded and ready for the next request. Prepped. Yeah. But you you only pay for wall time. It was just clock time.

Some others Use what's called CPU time. This is pretty interesting.

Is you only pay for the amount of time that the computer is doing work And not time that you are waiting. So specifically, Cloudflare Workers and Deno Deploy do this. So if you Let's say you have a a worker that I have 1. I have a recipe worker. Someone hits it with a URL for a chicken. So I take in The URL. I parsed the word chicken out of the URL, and then I send a fetch request to the all recipes API.

And while I'm sitting there waiting for the all recipes API to come back, to me, I'm not paying for that time. So if the recipes API takes 6 seconds to to do my process, I'm not paying for that. But as soon as it comes back, I'm Jason Parsing.

I am looping. I'm mapping. That's CPU. I'm actually using it. So you only pay for The actual CPU that you use and for some crazy way they can make that work.

And then the third way is you pay by By by the box like you would shop for a computer. I want a computer with I want a server with this many CPUs in it. I need this much memory.

And then you also will generally pay for bandwidth input output.

You're serving up a CSS file or something like that.

You will you'll pay for that. Yeah. Sick. Well, let's get into the actual providers here, and we're gonna start off with, some of the the big boys, 1st and foremost. We're not gonna be talking about a lot of these in-depth because, you know, a lot of these providers, These are the ones where you're you're honestly having to do a lot of stuff yourself. Now there's some caveats to that.

But, again, these these tools are going to be a little bit more of tools that you can use.

If you wanna save costs and do more things yourself. They're not going to be necessarily more boutique options, which honestly, the boutique options are built on top of these. Yeah, I think. Yeah. I think

every single one we're talking about today, except no. Maybe not all of them. Not not digital. Not Linode. Most of these providers are running on some of the big boys, and the big boys are Amazon, AWS, Azure, Google Cloud Platform. And then there's a bunch of littler ones, not littler ones. They're major, but IBM, Alibaba, Oracle, Salesforce, Rackspace and Vultr.

Those are, like, the big 10, big service providers with AWS, Azure, and Google taking up a majority of that pie.

Mhmm. Yeah. And and many times too When you're maybe you're provisioning a a server or something like that. Sometimes you can even choose where exactly this is hosted. Right? Sometimes they'll give you the app. Yeah. An AWS server verse and, Google Cloud server or an Azure server or something like that.

Let's Get into, like, the first of these boutique options.

I don't know. I guess I don't wanna call the boutique options because that that kinda insinuates that they're they're small. But, flight control@flightcontrol.dev, created from Brandon Bayer of Blitz.js fame.

You know what? I I'm gonna be real honest with you as I had not heard of this one until we'd made these show notes. And, I gotta say their website's Pretty cool, but I don't know a ton about it compared to many of these other ones. Yeah. This this one popped up in my feed because

When we did the show on SST, which is a framework for deploying to AWS That makes it easier.

Everybody was like, use amplify. Use amplify.

And, Brandon came out and said, hey. Like, I'm working on a startup called FlightControl right now. And it's pretty interesting in that It's not a hosting provider itself.

It is a set of tools. It is a service that you Log in with your AWS. So right before the show, I signed up. I logged in and then I Clicked over to Amazon and created a what's called a AWS Fargate.

And then I gave it access to my GitHub Repo with the syntax repo on it, and it deployed the syntax website. And It was really interesting because the Syntax website is running on my AWS account. It's not their AWS account. It's not running on their servers. It's running on mine.

But I like to think of them as like a remote control for AWS, meaning that they have sort of built a This is probably not fair to Vercel because they're a lot more than this, but they've built a Vercel like experience.

But you get the whole you get the deploy logs, you can have multiple Applications, you can redeploy it when you have a git commit. It will trigger a rebuild and deploy it for you so You get that whole experience, but on your own AWS.

So it's pretty cool. It's using this thing called Nixpacks, Which is funny because Nixpacks is a open standard to deploy any type of language to AWS or others.

And it's built by another one on this list, which is Railway. Io.

Yeah. So it's it's an open center. It's pretty cool. Now I never heard of that before. It's interesting that it's open sourced. So Heroku has build packs, which is, Okay. I have a Rails app, and I want to deploy it to Heroku.

They came up with this sort of, like, open standard called build packs. And then DigitalOcean and many other Providers say, okay, we're also going to to do build packs as well. So it's kind of funny because they use another hosting provider's own sauce to deploy it. But That's why they're open source, right? Yeah, the beauty of open source.

So this one, it creates a cloud formation, which is CloudFormation is a description of all of the pieces of AWS. So, of course, you want, like, hosting, but you probably also want CloudFront, which is their CDN that sits in front of it. You may be also want a database.

You might also want a bunch of different of these, like Route 53 bucket. Test 3 bucket, you know.

So it does that all of that for you. And the pricing is based on your I first I was I looked at it and it says Based on how much you spend on AWS.

And I was like, what? That's that's a lot. But then I read closer, and that's not It's based on how much you use on AMS, which is the Amazon managed service.

I don't really know a whole lot about this. This is why we want to have the AWS. But as far as I can see,

AMS

what this is, It's basically tooling used to orchestrate the different AWS solutions, and FlightControl uses AMS To make a versatile, like, experience that sits on top of us, at least as far as what I can see it. So it's really hilarious that Amazon has a tool to manage its own services, and then it will bill you based on how much you use that tool. So the pricing for flight control is They have different stacks. So if you spend $50 or $100 on AMS, then you pay a percentage of that Towards flight control to build, which is kind of cool because you're not paying flight control for hosting, you're using it yourself. You're still paying All the bandwidth costs yourself for AWS. You're just using this as a nice way to interface with

and link all your GitHub and everything together. Yeah. Okay. Well, let's get into the next one, which is where I host level up tutorial. So I've I've, I have quite a bit experience, which is render at render dot Com render was an interesting one for me because the initial branding of render, especially for, like, an app at the time for me was just a node app, Was that oh, you can host straight up node apps here because Vercel, back when it was, Zite, Used to be able to host straight up node apps. Right? Yep.

But they they've really changed things around and and no longer is that the case. So render There was, like, a good option for, hey. You have a node app. You wanna get it up and running, and you wanna get it up and running cheap somewhere quickly and easily With all of the the CI niceties that you would have. And in in addition to that, you can host a lot of things from, like Like we did, earlier on, cron jobs.

Static sites are free there. You can have workers.

You can host Postgres databases and private services in general there, but I hosted our Redis instance there, and it was super easy. A private Redis instance just Spun went up really nice and quickly, connected to it. No problem. And overall, it was, it has been a a good host for me. The pricing has been fairly reasonable even though they did upgrade their their pricing recently.

But for the most part, this thing can do anything you need For apps, I choose to use render as an option when I have a straight up node app that I wanna host somewhere as a modern solution there instead of going to something like Heroku.

Yeah. So it's a long running server full application. They have VMs, you can increase the number of CPUs, the amount of memory. So I also host My app on render as well, and I've been fairly happy with it. I did have a little bit of a kerfuffle the other day, which is always a little bit stressful. Mhmm. And it was I think it was mostly my fault.

What had happened I'm gonna say it is your fault Because this is not a problem that I had.

So I'm just gonna say it to you. So let well, let me explain. I haven't even told you what happened yet. So I know what the problem is. Okay. So I have my app running on Node 18, And it was it was running on render fine for 3 weeks. I hadn't done a single commit to it in 3 weeks.

And then I got an email From the message, hey, we need to move your app because we're doing something with those services, which is fine, Because what happens is they put you on a VM. It's sitting on a server somewhere. They need to power that server down.

So So they put you on another one. And the way that it works is that they rebuild your application or or they know they take the built version of it and they just cut it over to another one. And then they just switch the domain name and that that's zero downtime for your application. It works great.

So I got an email from them and said, hey, we need to move it, but your build is failing.

So, like, you got to fix that before we move you over because we can't build the new version of it.

So I was like, Okay, I'll deal with that.

I'll deal with that in like a minute or something like that. But then I also like 3 minutes after that email. Again, I hadn't touched this thing in 3 weeks.

3 minutes after that email, I get I get a another email from a runner said your build, Your server crashed and I rarely get those emails, but that means that my long running process Fell over somehow, right? So I was like, oh, shoot, like, what's going on here? And so I jumped in and I was like, what? It says it's out of memory. I was looking at the logs and it was just basically, like, taking 3 minutes. It spiked the memory all the way to what I was paying for, And then it ran out of memory and fell over, and it restarted itself. And it ran out of memory and fell over. And it kept doing that every 3 minutes.

So I'm sitting there Just finishing dinner, trying to get the kids in in in in the bath. So the worst time I know. To have anything stressful happen. If anybody has has kids, y'all know that bath time

is maybe one of the most stressful times in the household. Absolute chaos. So What had happened

is I went into my package. JSON And package. Json has this thing called engines, which is you declare which version of node you want it to run on. And I had node greater Or equal to 18 point whatever point whatever. Right. And I said, like, that's a minimum I want it to run on Node 18. But the day before, Node 20 had been released.

So it was trying to rebuild it on Node 20 and failing because, like, I hadn't tested it. I hadn't upgraded anything like it's not no 20s fault. It's just that You should test things on new versions of software before you deploy. But because I had greater or equal to and not either a range or pinning, which means Run on this exact version of node. Yeah.

It was failing. So I fixed that. But that doesn't explain Why my app was all of a sudden was failing.

And what I did figure out, what I think happened was They were trying to move me.

They took my built image and off of the node 18, copy pasted, slapped it into a node 20 environment, and started again. They didn't rebuild it Because it was failing, but they just moved it copy pasted onto node 20.

And because of that, it was It was spiking and falling over and over and over again. So I think they had moved it, but they didn't Do the exact environment because my package, Jason, said it's okay. It can run on anything bigger than 18. So I would say mostly my fault, But also don't do that. Like, if you're going to move me, maybe copy all the specs exactly how it was running.

So it was an easy fix. I just took the I just pinned the version to note 18, redeployed it, and it fixed All of the all of the issues for me. I take back my judgment of you, Wes. I think you're fine. Okay. Good. But I was it's It's so stressful when that type of thing happens, especially with, like, memory things because you're like, what? Yeah. It's not just like, oh, there's a syntax error Or like, this is what happened. You can look at the logs. It's just like you're out of memory. Boom. It fell over. But the the saving grace was I actually didn't have any downtime because I was at the time, my whole instances was scaled up to 2 instances, and they were So you just have one that's working. Yeah. Oh, they were Toggling back and forth. They were just both failing every 2 minutes, but they were not failing at the same time, and my restart time is, like, 3 seconds. So

as somebody who's who's had that exact thing going on before with this server is just dying for some reason while you are trying to figure it out, It's definitely a, a pro to have multiple instances running in that case when you're, when you accidentally have a, a bug make it to production in that regard. Exactly.

So, yeah, big fan of render still, though. But, yeah, especially, like I said, for node apps, that's, like, usually the 1st place I'm I'm reaching only because it's Quick and easy to get it up and running there. I got stuff there already.

Next step is is, JavaScript sweetheart, Vercel.

Vercel is the, It's the hosting provider that really started out as, like, the Next JS hosting provider, and Next JS Really became kind of React in a big way. React is really, really popular.

So Vercel, kind of rode that wave and and became a really highly used option here. Now the cool thing about Vercel in my experience in terms of, like, Somebody who looks at these things from a user friendliness perspective, you know, I I don't wanna spend a lot of time with my hosting. I've always found Vercel's Entire workflow when you're working with apps that are meant to be used with Vercel, I. E, SvelteKit, or Next. Js or any of these options that have an option to deploy to Vercel. I have found the experience overall to be really super nice.

The continuous integration stuff is good. The preview URLs are good.

It's fast. I found the pricing to be fine for me.

But for the most part, it's one of those services that continually sees improvement. And and as we record this right now so this Could be come out of date in some way. There's like a Vercell event going on at this very 2nd where they're announcing who knows how many things or something going on. So, Yeah. There could there could be more here that we're even missing by the time you're listening to this.

The actual tech behind Vercel, they do serverless, which Is, AWS Lambda functions. They do edge functions, which are just Cloudflare workers, not just, but like If you deploy middleware in Next. Js, they're deploying those things to Cloudflare Workers, which have a different API than than Node. Js. They do continuous integration. They do all your builds, all your previews.

They have a CDN as well. So if you have, they got some special sauce You put a website on Vercel, and it's fast. And that's because they have lots of sauce in How they build things.

They obviously have Turbo Pack, which will build it quickly. They have CDNs which will deliver To your user, they have edge functions that put it all over the world.

They have good analytics on the back end if you want to look at when a function or how many times a function was Was run like really good insight into, like, what's going on.

You pay based on Per seat, which is $20 per person, which is kind of frustrating, but that's how literally every render does this. They switch to that.

Netlify does it. Pretty much every hosting provider now says, Okay, you pay for usage or like your base plan gives you however much. And Vercel actually gives you A 1,000 gigabyte hours of execution, which is it's a lot for for what you get on the base plan. For $20, you get you get a lot for that.

But then you got 16 members you wanna add in that can get it gets pretty pricey pretty quickly, but I think they've Sort of nailed that because if you do have 6 team members, you probably have budget for that type of thing. I think that's why a lot of these companies are doing it.

Yeah. Totally.

Next one, begin. We've had Brian Larew on the show. Begin was a CI tool for deploying to AWS.

They've sort of pivoted now to More serverless. Specifically, wasn't it? Yeah. Yeah. It was it was entirely serverless.

They've pivoted more to full stack apps, So they are both a way to deploy it, but they're sort of pushing full stack apps with web components Behind it, which is pretty interesting. And it's all based on an open standard called Arc.

So I really like Arc. It's if I need like a quick I just want to run this function and I need a URL to hit it.

Arc is Arc or Cloudflare Workers are usually the 2 Super quick ones. I like ARC because it has routing bait built right in as well.

Next step is Heroku, which Heroku man, who bought Heroku? Salesforce.

Salesforce. Okay. So Heroku used to be Oh, you you have it in here in the notes. That's fun.

Heroku used to be like I remember when Heroku first came out, their website was Dark. It was cool. It was purple and, like, just really cool everything about it. And then you get into the actual service, which was like, oh, you could do these quick add ons. Deploying is as easy as connecting your GitHub repo and adding the Heroku deploy or whatever it was.

And for a long time, I personally hosted level up tutorials on Heroku because before Meteor had their own hosting service. That was like a really good place to host a meteor app. So I I had a lot of stuff on Heroku.

They got a lot of people roped in with their free dinos, they called them at the time, or their dinos. I I I still think they would still probably call them dinos, but Yeah. They're free servers, essentially, that you could quickly deploy an app on. I remember going to meetups, and it was, like, the first time you're learning Node. Js. Get something up on Heroku in no time. That's like the whole whole premise of everything that we did. Yeah. But Heroku Has not changed in however long, at least has not changed in any possible ways. They have changed. They've gotten really crappy.

They've gotten really crap. You're right. Yeah. Has not changed positively.

You can't like the, the The free ones, is there even free download anymore? Are are totally gone. They got rid of that. They've had major downtime. People were running that for all kinds of they had, like, a git integration,

and it was down for, like, a month, like, because they had a security incident.

And it it seems like it's just like a skeleton crew sort of running it right now. It's funny that sometimes companies get bought And then,

like like, did you not just spend 1,000,000,000 of how much did Heroku get bought for? Yeah. Seriously. And and you're just gonna let not only, like, dust cover it, but you're gonna let the the rust $212,000,000.

Yeah.

Is that, like, if I bought something for $212,000,000, I'm gonna be polishing it every day. I'm gonna be washing it. You know, I'm gonna I'm gonna be taking care of it. I'm not gonna let it fall into disrepair like, this has. And so, Heroku is probably only sustained by the customers that they had in the past. I I I don't know who's launching on Heroku today. If if not there, I recommend it. Heroku fan number 1, I guess, reach out to us. But, I would love to know if anybody is launching on Heroku today when there's all these other better outlets out there. Heroku was the first

company to have on demand servers, meaning that if you had a service that was not being used, It would spin down. It would turn off and you would the free dinos pretty aggressively did that as well, where If you hit a URL, sometimes the 1st time you hit the URL, it would take 5, 10 seconds. That's because the server was starting up again. It was put to sleep. It wasn't Actually being used. The VM was turned off and they needed to turn that VM back on. But that's also good if you have things that don't necessarily need to be Doing it. That's one of my gripes with Demos. Render right now. Little, utilities. Every single pull request I have on render Spins up the exact same server that I'm paying for in production and runs for as long as until I can merge that pull request and then it will spin down. So you got 6 pull requests in. You're running 7 servers, And you're paying for 7 servers even though 1 person is literally visiting that thing once a week. You know, like, it would be nice if they could spin down like Heroku did. Totally. Yeah.

Yeah. Next up is DigitalOcean, which DigitalOcean, you know, primarily, at least initially known for their droplets, Which are essentially just a VPS or a virtual private server where it, like, provisions you your own server, sends you your log or your, your login credentials.

You get in there. You get access to control that thing as if you were like a system admin for your own server. Right? And that was really cool. I remember feeling, like, super powerful, being in control of my own server, being in control of my own NGINX and everything like that and And really, like, dialing in that control. It was such a a nice cheap way to host a lot of stuff that allowed you to essentially Have full control, but I did not want to be a system admin. So I've kind of moved to, not managing my own server and doing a lot of these other ones. And DigitalOcean kind of also realized that not everybody wants that. They they were seeing the rise of services like Netlify and Vercel and and those types of things. So They have their own app platform, which, honestly, I I I only use the app platform once To attempt to deploy a personal site or something, it was like a Gatsby site.

You know, I I don't even know why it failed. It could have been a node version. It could have been anything. It failed. I closed it, and I have not used it since.

So I you know, DigitalOcean, they're very reliable. They they have a lot of Great things. I I don't have necessarily warm and fuzzy feelings about them as a a company necessarily given the CSS trick stuff, that happened. But, you know, they're definitely, like, a good option and a reliable option to host on. And if you run your own Server on there. You're your own VPS. You know, you you can, like, really save a lot of money, doing that kind of thing depending on what type of services. Also Yeah. You think, like, Kubernetes, Clusters and stuff like that. So, I mean, they're they're a legitimate option for, big time, small time, anytime apps. Yeah. They do

Like most things now, they initially were $5 SSD server, which is unfathomable to be able to get a server that runs on an SSD It was $5 a month, and you could scale it up really easily. Like, I remember I was getting tons of traffic. All I did was Drag the slider, and I had to power it down, drag the slider, go I used to host my boss monster on DigitalOcean.

I would run several sites off of 1 droplet, like Pons of sites off of 1 droplet and it was super cost effective. Yeah. Yeah, it's great. I did try the app platform as well. Actually, they even they sponsored my sticker drop as well. So Full disclosure. They paid me money, but I wasn't I again, I also had some issues with the app platform as well.

It was very early on. They're likely yes, this was the likely ironed out by now. But then I didn't realize that they have serverless functions. They have S3 compatible storage, which is really cool because You can just use the AWS libraries.

Anything that's like hosting images on Amazon S3, you could just use that library and and Pop DigitalOcean in there or same with Linode. You can pop their URL and the library will just work super well.

So it's it's It's pretty good. They do databases as well, took quite a bit in there. But, yeah, they they had a big layoff on their like they were always known for their Like articles, you know, like anytime you searched anything Nginx,

a DigitalOcean article would come up. And that's also why they bought CSS tricks. Right? But then They also bought Scotch dot io, which Oh, yeah. You go to Scotch dot io, it just redirects you to DigitalOcean now. Like so that's a kind of a huge bummer to me. It's like, I I don't know if If they just integrated all their content in here. But, you know, the Scotch. Io stuff was always so good. The CSS trick stuff Is it a huge bummer? So, you know, I I I like DigitalOcean as a service and as a a technical thing, but, you know, I I tend to not, like, really, like I said, get warm fuzzies about them, about this stuff, but, you know, nobody's perfect. No. What about Linode? Linode, who, again, full disclosure, has sponsored this podcast before.

Linode has is often been Considered like a really good VPS virtual private server option. Leno does everything. They've been around for a long time. Very trusted.

You know, I I don't really have anything negative to say about Linode. Although, you know what? I just went to linode.com.

Woah. Yeah. Yeah. So I I I feel like I'm at Linode's website somewhat frequently, so this must have just happened. But, Akama Akamai Akamai? Akamai.

Akamai. Akamai. I don't know how people say this, but Akamai.

Akamai. Yeah. Or Akamai. See, I wanna, like, go Japanese with it Just based on the way it's spelled, but, you know, looks like they're fully rebranded, And, Linode is now basically fully Akamai instead of Linodeau. So it looks like Linode might be going away at the dinosaur

In terms of its naming. Yeah. So Akamai bought the node as their edge play, meaning that I can't I can't keep saying this now. Akamai is a major what what do you call Akamai? Cloud? Akamai is an American content delivery network cybersecurity and cloud service company. So, like, they have servers everywhere. Often when It's coming from Akamai, and they bought the note to sort of go into their edge Play. You know? So it's kind of interesting. It's officially

Akamai.

Akamai.

Akamai.

So it's it's interesting that they just Dropped the Linode branding because, like, Linode to me is like that's what everybody used.

That's where I ran my 1st ever server. And then DigitalOcean came around with their $5 SSDs, and a lot of people moved over to that.

It's interesting now that They're going full like corporate.

Like, I don't know a single, like, Dev that would use Akamai to run their stuff, But I know lots of major, major companies that will use it. Infrastructure,

Media Temple. Oh, yeah. Yeah. They got by GoDaddy. A lot on Media Temple. They got bought by GoDaddy, and it was like the day that that happened. I moved everything to DigitalOcean at that time because I I still love Media Temple. Media Temple was the hot hot pick for a little while in terms of where everybody was hosting.

What about okay. So next one To be Netlify. Netlify primarily known for their free static site hosting. At least that's why people initially, Like caught on to Netlify. Netlify really came out at a great time where, you know, not a lot of hosting companies made things as easy as seamless As nice to work in as Netlify.

And and since then, they've continued to evolve. They recently did a major rebranding, which you know, actually, I've gotten used to the logo. I I really No. It looks like Walmart. Don't you think it looks like the Walmart logo? Well, didn't say I loved it. I said I've gotten used to it.

I've, I've entered the cold water, and I'm like, alright. This cold water's fine. I'm not like, oh, I love the cold water.