Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day?
Then you can even run multiple projects off the same server.
Then you can even run multiple projects off the same server.
It's way way way way easier managing a basic VPS that can be highly performant for your needs. If this was 2010, I'd agree with you but tooling and practices have gotten so much better over the last decade (especially the last 5 years).
I can see though that today's AI models could eventually replace the human in the loop and truly automatically fix every possible situation.
People often forget there is a massive economy out there for niche solutions and if you're a small team you don't exactly need a large slice to make a nice life for yourself.
I really doubt that people who can’t install an ssh key should be able to practice software engineering. Sometimes, I think that software engineering should be a protected profession like other types of engineering. At least it will filter out the people who can’t keep their OS up to date.
I felt more comfortable maintaining a VPS back between 2005 and 2015, but at that point attackers were dramatically less sophisticated and numerous and I was a lot more overconfident/naive. At least for solo operations I'm now inclined to use a PaaS… the exception to that is if said operation is my full time job (giving me ample time to make sure all bases are covered for keeping the VPS secure) or it's grown enough that I can justify hiring somebody to tend to it.
I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowledge about the thing that is running your code.
If it's so easy, surely it's no big undertaking to explain how one self hosts a fully secured server. No shortcuts, no "just use the usual setup" (we don't know what it is!), no skipped or missed bits. Debian to Caddy to Postgres, performant and fully secure, self upgrading and automated, from zero to hero, documenting every command used and the rationale for it (so that we may learn).
Or is it perhaps not as simple as you say?
What you have stated requires more knowledge (especially Postgres). You’re not going to get it from a blog post, and will need to read actual source docs and man pages.
This whole thing is merely cheap online snark masquerading as wisdom. No, not all SWEs know how to maintain Linux servers, and many (most?) SWE roles have all of zero overlap with that kind of work. If businesses could fire all their expensive server admins and replace them with some college kid and a $5 VPS, they would long since have done so.
If this is anything more than poseur snark, put your money where your mouth is and either write a comprehensive resource yourself, or at least compile a list of resources that would suffice for someone to be able to securely run and maintain a live server in production. No, not Hello Worlds, actual prod. Then, when next this comes up, link us to your guide rather than just spraying spittle on the plebs who lack your expertise.
Do something more constructive than low effort snark.
Claim one: setting up unattended-upgrades, SSH keygen, and automating cert rotation is trivial and easily automated.
Claim two: you should know how to manage a Linux server. Here are docs.
https://www.man7.org/linux/man-pages/dir_all_by_section.html
I agree with Node.js version deprecations being a huge problem and personally advocate for an evergreen WebAssembly platform for running apps. Apps should run forever even if the underlying platform completely changes, and only require updating if the app itself contains something that needs updating.
The speed. Imagine the performance. There are plenty of mature C++ web server frameworks, it's really not difficult. If you're afraid of C++, you could choose something else. Rust if you're insane, or golang if you're insane but in a different way.
Anyway. Nginx is not going away, so the argument is a bit silly. "What if js went away". Same thing.
I get that if you get a problem then it'll take a bit of work to fix, but all of this seems like a lot less work than dealing with support for a platform you don't control.
I haven't rebooted my DO droplets in something like 5 years. I don't monitor anything. None of them have been "retired".
And this is also bearing in mind that I complicate my setup a bit by running the different sites in docker containers with Caddy acting as a proxy.
With storage volumes for data and a few Bash scripts the whole server becomes throw-away that can be rebuilt in minutes if I really need to go there.
And for sure any difficulty and ops overhead pales in comparison to having to manage tooling and dependencies for a typical simple JS web-app. :)
Using SSH keys + fail2ban means that for a simple static site, it will be sufficient for a decade at least.
TLS certificates get auto-renewed with letsencrypt every 3 months via certbot.
Installing security updates depends heavily on what is your threat model, if you're just displaying some static content you fully own, you'll be usually fine.
Literally never seen a VPS being "retired", if it happened to you, change provider.
I've got a bunch of VPS running for 10+ years, I never need to touch them anymore.
My homelab has been going strong for the past 8 years. I did have to do some upgrade/maintenance work to go from being an old laptop without screen to a minitower low power machine, and when I added 30TB of storage. Other than that, it's running smoothly, it also uses TLS and all the rest.
You basically create a github, put a dockerfile inside it with your nginx config, frontend files, backend etc., then push and the Cloud Run instance is built for you then deployed into production. By default you are paying only for active requests, when a http request hits your box GCP will wake it up, charge for the CPU time used for serving it, then leave it idle for free for about 15 minutes. If another hit comes in that interval, you have instantaneous response because the instance is warm, otherwise it will wake up again and see a few seconds of latency (ie. during the night, when you have few visitors etc).
It also scales up automatically if you have substantial traffic, you don't have to do anything other than design your application so that multiple instances hitting the same data storage (ex. Firestore) will play nice. It of course handles all security, versioning, HTTPS certs etc. for you, you are simply serving plain HTTP traffic within the GCP internal network and just make sure your own application (what you push to git) is secure.
The things you pay for are outbound traffic (for obvious reasons like warez etc.) as well as storage of docker images (Artifact registry, i think you only have 0.5GB free, about 3 alpine images), but you can easily set up a rule to auto-delete old images.
Overall, you can run a small business with daily/weekly updates for less than a dollar a month and hit 5 nines availability, which you will never achieve for a self-administered VPS. Sorry if it sounds like an advertisement, but it's just enormous value for a small builder.
You get a generic VPS and you can do whatever the hell you like, not paying bigG for some "obvious reasons" like outbound traffic.
And a small business will never need 5 nines availability, that's just the propaganda from big tech to over engineer and pay them for that. You can run a small/medium business and be offline for 1 hour every day (makes it 95.8%) and still be fine. It's when you're worldwide and not that small that you want better availability.
Also, you know all those AWS outages? My VPSs were never impacted to the slightest!
And while I agree with the sentiment of resisting encloudification, you can take your docker image to any other host if you want, it's a generic service. in a pinch, you can build your own and have 100% control just like the VPS case.
The point is that you don't have to, you just git push into production and forget about it. that's a good few dozens less "extra steps" than the VPS route.