I'm an amateur blogger and programmer, running a custom-made static site on a Linode VM with Caddy [1]. I don't use containers or CDNs or anything fancy; my site generator just spits HTML into a folder and I rsync it to the server.<p>Do I need anything more than this? Is there some modern technology that is demonstrably better than my workflow? I worry I've been left behind, but I also find containers and other modern obsessions to be overkill for my needs.<p>Thanks for any and all advice.<p>[1]: https://caddyserver.com/
The best “I just want to serve HTML” workflow I’ve found is the Netlify/GitHub Pages workflow, as long as you consider version control useful.<p>I can see two downsides to using a VM. 1) You need to update it. 2) Your website goes down if your VM goes down. Do these matter? I’d say 1) is moderately important and 2) depends on your website.<p>Using Netlify fixes these issues (but introduces other potential problems). Does that make it “demonstrably better”? Depends. I’m not you, so I don’t know any pain points or annoyances you have or what you consider important. At the end of the day it doesn’t make a difference to the actual website.<p>That said, it is very quick to try. Why not spend an hour or so and see if it’s worth it for yourself?
You don't need more than that.<p>There are easier ways _depending on the context of what you already know_. There are better ways depending on what you're optimizing for. For you I bet this will be hard to beat. For me, I'd probably throw it in AWS S3, because that's what I know without having to think about it or do much work.<p>Containers and other such things are more for when you need different things, like a dynamic site or backend async processing, or not a site at all, and especially when you need some/all of that and are tired of sysadmining a VM.
You don’t need a VM for static sites.<p>As others have said, you can just drop it in S3.<p>The other alternative is Cloudflare pages. It’s cheaper than s3 with a generous free tier. I find it less hassle than uploading to s3. Git commit, git push, a few moments later it’s deployed on a global CDN.<p>Both options will be cheaper than running a VM and maintenance free.
Linode VM and Caddy isn't too left behind. It's likely to continue being well within "just fine" parameters for at least the next decade.<p>At some date after that point you'll be seen as a retro computing hobbyist if you're willing to change your personal brand, and people will flock to your blog to learn just how you manage to pull it off...
AWS S3 bucket set to serve static pages, use the aws command line to sync it with your source folder.<p>Its easy, cheap and resilient. If you want you can then cloudflare the site or aws have an equivalent service.
That VM is obsolete, the new way is<p><a href="https://jamstack.org/" rel="nofollow">https://jamstack.org/</a><p>for instance host with<p><a href="https://www.netlify.com/" rel="nofollow">https://www.netlify.com/</a><p>Basically you check your files into GitHub and chill, it is as easy as it gets.
The only concern is that you don't have any redundancy. What happens when you push an update? What if the service provider shuts down the VM to patch it?<p>If you are fine with your site being down for short periods of them then this approach is perfectly fine. Otherwise you'd need to set up multiple instances and some sort of load balancing between then.<p>Others have suggested hosted solutions for static sites (Netlify, Vercel, Github Pages, Cloudflare) and I think those would be a lot easier if you want a no fuss production solution.
You're paying $5-10 per month to host static files on a linode VM, when you could host it for free on netlify, vercel, github pages... etc<p>Vendor lock-in is no where near as bad for static sites too, as the actual static build is the same just slightly different deploy commands for different platforms.<p>A commercial product might not exist in a few years, but you can't guarantee someone else will pay for your Caddy server VM, after you're gone too.
You need something better if what you've got isn't doing the job. Doesn't sound like that's the case, so, there you go<p>I serve my blog from Node.js on Heroku, even though it's mostly statically rendered, because that's my comfort zone. A CDN or even nginx would be more efficient, but I don't need it to be. I much prefer having the breezy and familiar workflow
One thing to take into account is the flexibility of already having a VM over the touted CDN/jamstack workflow.<p>I think of it in terms of marginal cost. What is the cost of spinning up another site in a CDN/jamstack workflow? Not too bad if it's also static. What about spinning up another service like a database? Or not even leaving the HTTP space, what about a non-static site? I like having the flexibility of say hacking together a RSS aggregator in a weekend and throwing it onto my VPS behind my already running reverse proxy.<p>(Oh and it's a "free" VPN if you are already paying for the VPS for another reason.)
The only thing I'd add is a CI/CD pipeline to make updating the VM easy. Maybe an Ansible playbook to better ensure the files get copied and that Caddy gets updated, if needed. All optional though.
a vm running a server is not really "simple", at least not by my idea for static html. i would think a vm/server is only needed if you have specific hosting requirements.<p>maybe i'm missing something as i didn't see anyone else suggest it, but i would just use github pages, or even something like gdrive, dropbox, mega can host html i think.
Caddy, you say?<p>This is what I would do.<p>Keep the Markdown files on your local PC.<p>- Add/modify Markdown files.<p>- run a bash script to<p>- - rsync them all to your VPS<p>- - run Caddy on VPS<p>Done.<p>View on your favorite web browser.