Static site hosting hurdles(notes.volution.ro)
notes.volution.ro
Static site hosting hurdles
https://notes.volution.ro/v1/2022/09/notes/b08118d8/
182 comments
> what's wrong with shared hosting?
You answered that yourself:
> It costs less than $10/month
That’s a lot of dollars for a static website. There are a myriad of free options and there have been for years. Kinda disappointing that they weren’t mentioned. Anyone wanting to deploy a static website knows the big 4, completely free: Netlify, Vercel, CloudFlare Pages, GitHub Pages.
You answered that yourself:
> It costs less than $10/month
That’s a lot of dollars for a static website. There are a myriad of free options and there have been for years. Kinda disappointing that they weren’t mentioned. Anyone wanting to deploy a static website knows the big 4, completely free: Netlify, Vercel, CloudFlare Pages, GitHub Pages.
I prefer not to use free services because they're not sustainable, and they usually come with strings attached
Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years)
The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/
I thought mine was more like $8 but I honestly don't remember. It's a fair price for steady service IMO
Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years)
The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/
I thought mine was more like $8 but I honestly don't remember. It's a fair price for steady service IMO
> I prefer not to use free services because they're not sustainable, and they usually come with strings attached
When I checked Dreamhost several years ago, I found that it was also an oversold service that relied on most customers using way less than the promised capacity. This doesn’t mean that it’s bad at hosting websites, but it’s not something I wanted to pay for.
So I hosted my websites with Nearly Free Speech (NFSN), where hosting is actually by what you consume. For small static sites, you could get a lot more mileage with NFSN and still not pay more than a couple of dollars a month. It’s a lot cheaper than your Dreamhost plan, and is truly sustainable because NFSN gets very close to recovering its costs plus a little more to sustain, grow and become better. NFSN also doesn’t have tricks like referral programs and other special discounts, unlike Dreamhost (talking from what I’ve seen about Dreamhost in the past).
The major downside is it doesn’t have cPanel and fancy application installers. But that shouldn’t be an issue for people who would use scp to setup web pages on a host.
When I checked Dreamhost several years ago, I found that it was also an oversold service that relied on most customers using way less than the promised capacity. This doesn’t mean that it’s bad at hosting websites, but it’s not something I wanted to pay for.
So I hosted my websites with Nearly Free Speech (NFSN), where hosting is actually by what you consume. For small static sites, you could get a lot more mileage with NFSN and still not pay more than a couple of dollars a month. It’s a lot cheaper than your Dreamhost plan, and is truly sustainable because NFSN gets very close to recovering its costs plus a little more to sustain, grow and become better. NFSN also doesn’t have tricks like referral programs and other special discounts, unlike Dreamhost (talking from what I’ve seen about Dreamhost in the past).
The major downside is it doesn’t have cPanel and fancy application installers. But that shouldn’t be an issue for people who would use scp to setup web pages on a host.
Sure, NearlyFreeSpeech is probably closer to the ideal I'm talking about, but I happen to use Dreamhost.
My point was that shared hosting exists, is good, and is the right solution to this problem. My point was not that you should use Dreamhost :)
I tried NearlyFreeSpeech a few years ago; some sibling comments describe my experiences
My point was that shared hosting exists, is good, and is the right solution to this problem. My point was not that you should use Dreamhost :)
I tried NearlyFreeSpeech a few years ago; some sibling comments describe my experiences
> I prefer not to use free services because they're not sustainable
Just a guess from outside, but Microsoft is likely to be sustainable even if you use GitHub Pages to serve your static site on a free account.
Just a guess from outside, but Microsoft is likely to be sustainable even if you use GitHub Pages to serve your static site on a free account.
When I say "sustainable", I don't just mean that the company might not have enough money to keep its lights on
It's more that some product manager or VP will notice this free service and want to attach their strings to it.
Having worked in big tech, it happens very often. Google Groups is a famous example at Google (among many). It was way better 15 years ago, but it just wasn't "worth it" to keep the lights on in its current state, so it shuffled through a series of product managers/teams who wanted to "improve" it.
Microsoft has a long history of this as well. I feel like this is another generational thing -- people forgot what Microsoft used to be like, and how their free products turned hostile. So far Github is OK, but I'm sure glad there are alternatives.
I prefer to just pay money to a company that provides a service, and I hope they profit from that. That incentives should be aligned. So far with Dreamhost that has worked out exactly as expected.
If I had spent any time migrating to the latest and greatest thing in the last 13 years, that would have easily burned the money I have saved by using a free service.
e.g. I have hosted sites on other platforms that are now down and useless, as I'm sure many others here have.
It's more that some product manager or VP will notice this free service and want to attach their strings to it.
Having worked in big tech, it happens very often. Google Groups is a famous example at Google (among many). It was way better 15 years ago, but it just wasn't "worth it" to keep the lights on in its current state, so it shuffled through a series of product managers/teams who wanted to "improve" it.
Microsoft has a long history of this as well. I feel like this is another generational thing -- people forgot what Microsoft used to be like, and how their free products turned hostile. So far Github is OK, but I'm sure glad there are alternatives.
I prefer to just pay money to a company that provides a service, and I hope they profit from that. That incentives should be aligned. So far with Dreamhost that has worked out exactly as expected.
If I had spent any time migrating to the latest and greatest thing in the last 13 years, that would have easily burned the money I have saved by using a free service.
e.g. I have hosted sites on other platforms that are now down and useless, as I'm sure many others here have.
I don't disagree with you but you can't use Google to support your argument. They have to be the worst player out there when it comes to supporting free services over the long-term. You're so much safer with Github's free tier, there's no comparison.
If you use your own domain, you can easily change your hosting should it go down.
This had me wondering when GitHub Pages was actually introduced; earliest sign I can find is a blog post [0] from December 2008, so that's almost 14 years ago.
[0] https://github.blog/2008-12-18-github-pages/
[0] https://github.blog/2008-12-18-github-pages/
It’s static hosting. If they change their terms, it couldn’t be any easier to switch. I switched most of my Netlify sites to CloudFlare Pages in like 10 clicks each. The whole point of having a static file is that they’re super easy to manage.
Worst case scenario you pay a few cents to host on S3 and stick any free-range CDN on it.
I categorically refuse to use any non-static hosting for static content. Your shared hosting runs code and can be compromised, especially if you host multiple software/sites on it.
Worst case scenario you pay a few cents to host on S3 and stick any free-range CDN on it.
I categorically refuse to use any non-static hosting for static content. Your shared hosting runs code and can be compromised, especially if you host multiple software/sites on it.
Sure, that is a lot for hosting a single static site. But, that $10 essentially gives you unlimited sites, unlimited email hosting, SSL cert management, lots of storage, unlimited network, and much more…
It's never unlimited, the terms and conditions for shared hosting are specifically designed to prohibit use cases (ex. file storage not connected with a website) that generate excessive usage.
And if you somehow find a loophole you'll quickly become persona non grata.
As the saying goes, TANSTAAFL.
And if you somehow find a loophole you'll quickly become persona non grata.
As the saying goes, TANSTAAFL.
There are web hosting plans at less than 3$/month.
There are also community hosting networks offering different kind of hosting services for a small sum / year. Here is an example of such a network mostly france based but I am sure there are same kind of initiatives all over the world: https://www.chatons.org
There are also community hosting networks offering different kind of hosting services for a small sum / year. Here is an example of such a network mostly france based but I am sure there are same kind of initiatives all over the world: https://www.chatons.org
Shoutout to Gitlab as well, which is what I use for personal sites.
There are still some limits to these (for example Netlify limits the bandwidth you can use each month), but yeah, for most practical purposes the free tier should do just fine.
On a side note, I'm wondering if one can host one site simultaneously on e. g. Netlify and Vercel and load-balance those (for example, with round-robin DNS) to stay within free limits for longer.
On a side note, I'm wondering if one can host one site simultaneously on e. g. Netlify and Vercel and load-balance those (for example, with round-robin DNS) to stay within free limits for longer.
[deleted]
You could also just throw a CDN in front of Netlify (I do this with Cloudflare) and it will be extremely hard to reach that limit.
Your domain alone is going to cost about half that, and much more for fancy domains. Depending on whether you need a site mail contact (sometimes required for [email protected]) and certificate (for any ecommerce site), we're talking about at least twice that. We do talk about serious hosting, do we?
Your costs are way off.
.com is around ~10$/year, email server is included in practically all shared hosting, and basically every shared hosting offers free TLS via Let's Encrypt (or some other provider.)
.com is around ~10$/year, email server is included in practically all shared hosting, and basically every shared hosting offers free TLS via Let's Encrypt (or some other provider.)
Ten dollars sounds a bit expensive for shared hosting? I have been happy with Hawkhost for the last 10 years, which starts their shared hosting options at $2.99/month. That is 10 GB storage, unlimited bandwidth, host as many domains as you want, SSH access, choose between servers in EU or America. I even use it for some email addresses.
I have great respect for the folks keeping this stable and working for decades for such a low price!
I have great respect for the folks keeping this stable and working for decades for such a low price!
Nothing's wrong, it just gives much more than needed to serve a static site!
I like the idea to statically pre-generate entire HTTP responses, with all headers, and just serve a byte stream mindlessly once a URL is mapped. If TLS is handled by a separate proxy (that only does TLS termination), the "web server" becomes as trivial as it gets. Fast, simple, due to the simplicity probably bulletproof.
I like the idea to statically pre-generate entire HTTP responses, with all headers, and just serve a byte stream mindlessly once a URL is mapped. If TLS is handled by a separate proxy (that only does TLS termination), the "web server" becomes as trivial as it gets. Fast, simple, due to the simplicity probably bulletproof.
I don't really follow what you're saying
It serves static sites. I upload my files with rsync, scp, or git, and they are served
It serves static sites. I upload my files with rsync, scp, or git, and they are served
There's still a "web server" in front of those files that speaks HTTP and delivers those files. An extremely simple one, but it still exists.
What they're proposing is cutting out the "speaks HTTP" part in favor of entirely pre-recorded responses. Whether you think that's feasible or not depends on where you draw the line in the sand, but it can certainly be easier to implement than nginx.
What they're proposing is cutting out the "speaks HTTP" part in favor of entirely pre-recorded responses. Whether you think that's feasible or not depends on where you draw the line in the sand, but it can certainly be easier to implement than nginx.
Web servers exist already. Does what you’re describing exist?
[the author here] Well, the article does point in the last section "Putting it in practice" to my own implementation <https://github.com/volution/kawipiko>. :)
Another DreamHost fan here. I host dozens of hybrid sites on both the shared hosting and VPS and the service is great. My setup is pretty simple, a Perl-based SSG which generates static HTML on-demand if it happens to be missing from the tree.
I've had a few minor issues over the years, often self-inflicted, and whenever I use the support panel, I get a helpful human response within an couple of hours, usually with a resolution. If I have to respond, I can respond to the email by email!
All in all, can't praise DreamHost enough.
I've had a few minor issues over the years, often self-inflicted, and whenever I use the support panel, I get a helpful human response within an couple of hours, usually with a resolution. If I have to respond, I can respond to the email by email!
All in all, can't praise DreamHost enough.
Same here except with opalstack.com It’s run by the same great team that was behind webfaction before godaddy bought it.
Complete agree. Been DH customer since 2004.
Just wish they used newer hardware than they do on their VPS & Dedicated offering.
Just wish they used newer hardware than they do on their VPS & Dedicated offering.
I have no idea what kind of hardware they use for VPS, but whatever thing I'm doing, they've handled it well. Haven't tried Dedicated yet.
What you're describing is a caching system, not a static site generation system.
It's both, and can run in several different modes.
In dynamic mode, you are correct that the HTML files act as a cache.
In static mode, the on-demand layer (and any related hooks in the web server) are turned off, with all the pages being pre-generated.
There is also a hybrid mode, where the access log (and content store) is scraped for updates and they're integrated into the static HTML on a schedule.
Each of these has its own advantages and drawbacks in terms of security, accessibility, performance, and convenience.
In dynamic mode, you are correct that the HTML files act as a cache.
In static mode, the on-demand layer (and any related hooks in the web server) are turned off, with all the pages being pre-generated.
There is also a hybrid mode, where the access log (and content store) is scraped for updates and they're integrated into the static HTML on a schedule.
Each of these has its own advantages and drawbacks in terms of security, accessibility, performance, and convenience.
I've also been a Dreamhost customer for a long time. Note that Dreamhost's $10/mo is for I-don't-know-exactly number of domains. If you own a domain name you can add it in their dashboard, point it to their name servers, and you're up and running. Their services includes e-mail which means avoiding the perils of fully self-hosting.
While you could save a few dollars renting a VPS, it's only cheaper if your time is worth nothing. If you're just going to do static hosting I've found it to be a good deal.
While you could save a few dollars renting a VPS, it's only cheaper if your time is worth nothing. If you're just going to do static hosting I've found it to be a good deal.
Yeah I think it's infinite domains ... You pay a yearly fee for each domain, which is something like $16.
But the hosting is a flat fee at less than $10/month. (edit: just checked, actually I pay yearly for a discount.)
So I find that to be pretty nice, because I have had 5 domains at one point. And now I have 3 or so.
But I always keep the same hosting account. It works well in practice.
But the hosting is a flat fee at less than $10/month. (edit: just checked, actually I pay yearly for a discount.)
So I find that to be pretty nice, because I have had 5 domains at one point. And now I have 3 or so.
But I always keep the same hosting account. It works well in practice.
You can register your domains anywhere and point them at Dreamhost. I don't recall any fees for setting up a new domain with them so long as you already own it.
Dreamhost is hugely underrated.
Their custom panel with deep integrations are phenomenal for side projects or small businesses. In under a minute you can have your web server, SSL cert, database and more all setup and working - and you don’t have to manage any of it.
I wish more companies offered their level of managed services.
(If anyone knows of others, I’d like to hear who)
Their custom panel with deep integrations are phenomenal for side projects or small businesses. In under a minute you can have your web server, SSL cert, database and more all setup and working - and you don’t have to manage any of it.
I wish more companies offered their level of managed services.
(If anyone knows of others, I’d like to hear who)
Is there anything really wrong with a CPanel host with FTP upload?
Namecheap, Dreamhost, GoDaddy even (well maybe not them lol). There are a billion shared hosts everywhere and CPanel really isn't hard to use for HTTPS enabling or getting FTP locations to work with.
------
Bonus points: shove a random .php file in there and it probably will work if you need just a little bit of dynamic content.
Namecheap, Dreamhost, GoDaddy even (well maybe not them lol). There are a billion shared hosts everywhere and CPanel really isn't hard to use for HTTPS enabling or getting FTP locations to work with.
------
Bonus points: shove a random .php file in there and it probably will work if you need just a little bit of dynamic content.
>Is there anything really wrong with a CPanel host with FTP upload?
Nothing, other than that it's not cool with the kids because it's the grandpa's way of being a webmaster.
Personally, being an old school grump, I'll choose FTP upload over Git nonsense any day of the week because why in the nine seas of the seven hells do I need to sign up for Github, upload all my crap there, download-install and run a Git daemon, feed it my Github login credentials, let the daemon download and sync/compile/whatever the code I have there, and then probably run the whole contraption through sixty dozen frameworks of JavaShit to have a website?
I'll just fire up Filezilla or whatever is the trendy FTP client nowadays, punch in my login creds, upload my crap that I wrote up in Notepad++, maybe have some fun with PHP because I'm old school, and be done with it. :V
Nothing, other than that it's not cool with the kids because it's the grandpa's way of being a webmaster.
Personally, being an old school grump, I'll choose FTP upload over Git nonsense any day of the week because why in the nine seas of the seven hells do I need to sign up for Github, upload all my crap there, download-install and run a Git daemon, feed it my Github login credentials, let the daemon download and sync/compile/whatever the code I have there, and then probably run the whole contraption through sixty dozen frameworks of JavaShit to have a website?
I'll just fire up Filezilla or whatever is the trendy FTP client nowadays, punch in my login creds, upload my crap that I wrote up in Notepad++, maybe have some fun with PHP because I'm old school, and be done with it. :V
Lots of us old school grumps still running things the old fashioned way for many years, serving millions of requests without issue, customers happy, and with a deployment pipeline anyone can understand :)
Because were more interested in getting things done, rather than tech fad signaling.
You over-focus on what's cool or fashionable. For many of us that's absolutely not the reason to go (or not to go) with a platform.
GIT is extremely useful for versioning. I want that. If I make a dumb mistake I want to have a diff that I've fixed a typo / grammar / added more links etc.
You neither need to use GitHub nor give your GitHub credentials to anything. You can just make a public repo and have it cloned / pulled-from by literally anyone interested -- why would anyone clone your public blog repo and re-host it? You can use sr.ht, Codeberg or just host your own GIT -- it's not that hard if you're into it (I am not).
Your way of doing it is fine but let's not pretend that everyone else is following fashion or coolness. That's very rarely true. There's a list of very good reasons to use a public GIT repo + Netlify + use a static site generator on your own machine to only produce a directory of HTML+CSS files.
GIT is extremely useful for versioning. I want that. If I make a dumb mistake I want to have a diff that I've fixed a typo / grammar / added more links etc.
You neither need to use GitHub nor give your GitHub credentials to anything. You can just make a public repo and have it cloned / pulled-from by literally anyone interested -- why would anyone clone your public blog repo and re-host it? You can use sr.ht, Codeberg or just host your own GIT -- it's not that hard if you're into it (I am not).
Your way of doing it is fine but let's not pretend that everyone else is following fashion or coolness. That's very rarely true. There's a list of very good reasons to use a public GIT repo + Netlify + use a static site generator on your own machine to only produce a directory of HTML+CSS files.
Generally speaking, I subscribe to the philosophy of KISS.
For a multi-user environment where a dozen people could be accessing the same file at any given time, yeah some sort of version control system will probably make everyone's life easier.
For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity.
In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
This isn't to say your way isn't wrong /for you/, of course. Whatever floats your boat. For me, it's all just unnecessary complexity that will invite in all sorts of gremlins to waste my time.
For a multi-user environment where a dozen people could be accessing the same file at any given time, yeah some sort of version control system will probably make everyone's life easier.
For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity.
In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
This isn't to say your way isn't wrong /for you/, of course. Whatever floats your boat. For me, it's all just unnecessary complexity that will invite in all sorts of gremlins to waste my time.
> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
At a minimum, static site generators create indexes, table-of-contents, tags, sorts by date, and other such features.
Pretty much no one writes good, raw, HTML these days. Documentation is written Sphinx, texinfo, docbook, and many other formats. Why? Because compiling chapters (or pages) together through static analysis is a very useful pattern for writing.
HTML is just an output pattern. Your actual words should be in a document generator at a minimum.
At a minimum, static site generators create indexes, table-of-contents, tags, sorts by date, and other such features.
Pretty much no one writes good, raw, HTML these days. Documentation is written Sphinx, texinfo, docbook, and many other formats. Why? Because compiling chapters (or pages) together through static analysis is a very useful pattern for writing.
HTML is just an output pattern. Your actual words should be in a document generator at a minimum.
My website [1] is good raw (X)HTML [2]. It's just a couple of pages though, nothing fancy. If I was keeping a blog or something, I would definitely go for an SSG.
[1]: https://notpushk.in/
[2]: https://gitlab.com/notpushkin/notpushk.in
[1]: https://notpushk.in/
[2]: https://gitlab.com/notpushkin/notpushk.in
> It's just a couple of pages though, nothing fancy
Nope. Anything I can have a machine generate for me is fancy if I have to write it by hand.
Nope. Anything I can have a machine generate for me is fancy if I have to write it by hand.
> For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity.
Hard disagree. As I said above and you ignored it (no clue why): I want to have a history of my static website.
> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
I can and I don't want to. Markdown is tons easier, you write out an article, execute one command, push the updated HTML+CSS files to GIT and you're done. If we're talking about simplicity let's not ignore that scenario because it really is quite simple.
I got a backlog of 30 things to work on and 500+ to check out "one day when I have the time". Going back to hand-crafting HTML is likely at spot #1784 in my brain. It's a meaningless paperwork that can and must be outsourced to computers.
Hard disagree. As I said above and you ignored it (no clue why): I want to have a history of my static website.
> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
I can and I don't want to. Markdown is tons easier, you write out an article, execute one command, push the updated HTML+CSS files to GIT and you're done. If we're talking about simplicity let's not ignore that scenario because it really is quite simple.
I got a backlog of 30 things to work on and 500+ to check out "one day when I have the time". Going back to hand-crafting HTML is likely at spot #1784 in my brain. It's a meaningless paperwork that can and must be outsourced to computers.
Git for static site versioning? Why not just copy the HTML into a new folder? Takes seconds. Zero complexity. Gets backed up with your regular system backups.
Git is great for collaborative or complex projects, but for a static site, you're using a freight train to bring a single tomato to market.
Git is great for collaborative or complex projects, but for a static site, you're using a freight train to bring a single tomato to market.
Well, even though I can reinvent `git diff` I still don't want to. GIT gives me good diffs and I don't view it as an unnecessary overhead.
¯\_(ツ)_/¯
¯\_(ツ)_/¯
I'm fairly certain that was a joke
There’s a massive difference in quality and ease of use between cPanel and dreamhost custom panel.
I’ve been a customer since 2004
I’ve been a customer since 2004
Well, I'm sure that's true.
But I guess my overall point is that CPanel is way easier than anything the original poster / author wrote.
But I guess my overall point is that CPanel is way easier than anything the original poster / author wrote.
Please check https://elest.io
You can deploy WordPress, Ghost, Magento and 185 fully managed software. You get a dedicated VM with stellar performances, SSL, smtp, security, borg ans S3 backups, monitoring, logs and full root access even if it's managed.
We also support CI/CD pipelines.
Disclaimer: I work there ;)
Disclaimer: I work there ;)
I think this is what Cloudflare Pages tries to solve
You just connect your git repo and tell it what command to run to build your site and where the html output is
You just connect your git repo and tell it what command to run to build your site and where the html output is
FWIW I also tried NearlyFreeSpeech, which is the top comment in the same thread I linked:
https://news.ycombinator.com/item?id=29253277
I think it is good, and will solve people's static hosting problem. It's a server that you don't have to manage. It has a nice fast custom web interface.
Except I didn't realize it was FreeBSD. That probably doesn't matter for most, but I'm used to Linux, so I like Dreamhost better. Also I feel like they are using some kind of slower NFS disk, whereas Dreamhost feels like a bare metal disk mostly.
-----
I was trying to find another thread here, where someone remarked that "shared hosting" got a bad reputation in the early days due to janky control panels and bad/aggressive marketing.
Also a lot of the companies seem to have gotten acquired in the early 2000's, i.e. they changed hands a lot.
But again I've been using Dreamhost since 2009 and it's been great. No complaints except the typical thing everyone does of raising the domain name pricing after a year (the advertised price is the "first year discount").
They have not raised the hosting fees. (You might save $3 per year using a domain name purchased elsewhere, but that doesn't seem worth the hassle to me.)
So I thought there were many other shared hosting companies, but maybe not? Maybe they all got caught up in acquisitions and then the service declined? (That's exactly what's going to happen with the free cloud services you're all using now BTW, so that's why I stick with something older and proven.)
I have used 1and1 in the early 2000's, but I remember it being very janky and weird, and Dreamhost is a lot better technically. They seem to have more competent system administration.
----
FWIW here is a thread with some competitors:
https://lobste.rs/s/jkutwc/recommendations_for_shared_hostin...
Honestly I wonder if Dreamhost is more unique now than it used to be? I thought of it as "commodity shared hosting" -- i.e. a Linux OS and a web server. But I think that actually being able to manage that competently is a dying art :-/
Other threads I bookmarked while looking for shared hosting that supports FastCGI (dynamic sites, not static, and not PHP!):
bluehost: https://www.bluehost.com/help/article/fastcgi-for-php
hostgator: https://www.hostgator.com/help/article/does-hostgator-suppor...
I'd be interested to know if those companies are comparable to dreamhost!
https://news.ycombinator.com/item?id=29253277
I think it is good, and will solve people's static hosting problem. It's a server that you don't have to manage. It has a nice fast custom web interface.
Except I didn't realize it was FreeBSD. That probably doesn't matter for most, but I'm used to Linux, so I like Dreamhost better. Also I feel like they are using some kind of slower NFS disk, whereas Dreamhost feels like a bare metal disk mostly.
-----
I was trying to find another thread here, where someone remarked that "shared hosting" got a bad reputation in the early days due to janky control panels and bad/aggressive marketing.
Also a lot of the companies seem to have gotten acquired in the early 2000's, i.e. they changed hands a lot.
But again I've been using Dreamhost since 2009 and it's been great. No complaints except the typical thing everyone does of raising the domain name pricing after a year (the advertised price is the "first year discount").
They have not raised the hosting fees. (You might save $3 per year using a domain name purchased elsewhere, but that doesn't seem worth the hassle to me.)
So I thought there were many other shared hosting companies, but maybe not? Maybe they all got caught up in acquisitions and then the service declined? (That's exactly what's going to happen with the free cloud services you're all using now BTW, so that's why I stick with something older and proven.)
I have used 1and1 in the early 2000's, but I remember it being very janky and weird, and Dreamhost is a lot better technically. They seem to have more competent system administration.
----
FWIW here is a thread with some competitors:
https://lobste.rs/s/jkutwc/recommendations_for_shared_hostin...
Honestly I wonder if Dreamhost is more unique now than it used to be? I thought of it as "commodity shared hosting" -- i.e. a Linux OS and a web server. But I think that actually being able to manage that competently is a dying art :-/
Other threads I bookmarked while looking for shared hosting that supports FastCGI (dynamic sites, not static, and not PHP!):
bluehost: https://www.bluehost.com/help/article/fastcgi-for-php
hostgator: https://www.hostgator.com/help/article/does-hostgator-suppor...
I'd be interested to know if those companies are comparable to dreamhost!
As a long time (but very light) Nearly Free Speech user who is also more used to Linux, I'm curious if you ran into specific problems because of them using FreeBSD, or if it was just the general feeling of things being slightly different than you're used to (which is totally a valid reason to prefer something else, I'm just wondering if it was more than that)?
I think a lot of it was the network file system issue I mentioned -- the shell felt slow, and I suspect it was because of a network disk. I can't be sure, but I think that is a significant difference between Dreamhost and NearlyFreeSpeech.
Also at that point I had used Dreamhost for ~10 years, so I was just more comfortable with it. I like how my files are in ~/oilshell.org and my logs are in ~/logs/oilshell.org. If I had started with NearlyFreeSpeech I'm sure it would have been fine
IIRC the reason I tried it was because I was looking for FastCGI support (i.e. non-PHP dynamic sites that you don't have to maintain a daemon for)
I don't quite remember, but I think they did have some FastCGI support, but it wasn't quite what I wanted, or maybe the Python version was different, etc. It looks like a great service, but I don't currently use it
Also at that point I had used Dreamhost for ~10 years, so I was just more comfortable with it. I like how my files are in ~/oilshell.org and my logs are in ~/logs/oilshell.org. If I had started with NearlyFreeSpeech I'm sure it would have been fine
IIRC the reason I tried it was because I was looking for FastCGI support (i.e. non-PHP dynamic sites that you don't have to maintain a daemon for)
I don't quite remember, but I think they did have some FastCGI support, but it wasn't quite what I wanted, or maybe the Python version was different, etc. It looks like a great service, but I don't currently use it
Yep. Been on Dreamhost since 2004. Just create the html file and sftp it using FileZilla. Setting up a domain is just a few clicks on their admin site. PHP + MySQL works perfectly. All for $10/month.
Shell is what I use to generate my sites also https://mkws.sh! Very simple, very eficient!
[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is <https://redbean.dev/> which I find just so intriguing, and not far from my own <https://github.com/volution/kawipiko> proposal.)
Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.
It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.
The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:
* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)
* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;
The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.
Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.
It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.
The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:
* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)
* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;
The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.
This is wrong on many levels.
Most people don't need all that complexity and configuration options, especially if you just want it to work.
Asset minification can be done locally, besides the ominous gatekeepers don't give a fuck. I've got a static website with lots of files, just HTML and CSS, not even minified I think, and a dozen lines of JS, and it's a solid 100/100 on Page Speed Insights.
Link headers? There's a HTML tag for that and it's fast enough: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types...
You're just bloating everything up.
Most people don't need all that complexity and configuration options, especially if you just want it to work.
Asset minification can be done locally, besides the ominous gatekeepers don't give a fuck. I've got a static website with lots of files, just HTML and CSS, not even minified I think, and a dozen lines of JS, and it's a solid 100/100 on Page Speed Insights.
Link headers? There's a HTML tag for that and it's fast enough: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types...
You're just bloating everything up.
The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough
Shared hosting is basically where somebody configures and runs Apache or Nginx for you ... they know how to do this, and it definitely works!
Shared hosting is basically where somebody configures and runs Apache or Nginx for you ... they know how to do this, and it definitely works!
> I don't think it's still a common choice for today.
Not true at all. About 37% of the web hosting market is shared hosting. Just do a simple web search for the size of the web hosting services market to find this information. It's one of the 3 most common choices today – and it's always been that way.
Not true at all. About 37% of the web hosting market is shared hosting. Just do a simple web search for the size of the web hosting services market to find this information. It's one of the 3 most common choices today – and it's always been that way.
It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront.
But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitches this as an attempt to “standardize the hosting side of static sites”, which doesn’t pass muster for me. We’ve already standardized the hosting side of static sites by using the file system. Shifting to a new storage format besides “HTML on disk” doesn’t unify anything, nor does it seem desirable to have fewer options for serving content.
But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitches this as an attempt to “standardize the hosting side of static sites”, which doesn’t pass muster for me. We’ve already standardized the hosting side of static sites by using the file system. Shifting to a new storage format besides “HTML on disk” doesn’t unify anything, nor does it seem desirable to have fewer options for serving content.
I agree -- the OP said space for all the separate HTTP response variations might be an issue, and "With a smart enough storage format all of these could be solved".
I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.
I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.
>We’ve already standardized the hosting side of static sites by using the file system.
Worth noting that the incoming younger generations can't and don't into file systems.[1]
Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point.
We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.
[1]: https://www.theverge.com/22684730/students-file-folder-direc...
Worth noting that the incoming younger generations can't and don't into file systems.[1]
Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point.
We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.
[1]: https://www.theverge.com/22684730/students-file-folder-direc...
In fairness to younger generations, I can never figure out how to use file choosers in modern operating systems or in crap like google drive.
It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
(Partially because the dialog box sucks, and partially because I only do that once every 6 months or so.)
It's like some UI designer didn't understand folders, then somehow forced their brain damaged mental model of them on the rest of the population. After that, for some reason I will never understand, the rest of the industry copied the design.
(I've worked on filesystem implementations, tested for POSIX compliance, debugged insane customer issues, etc, etc. I know how directories work...)
It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
(Partially because the dialog box sucks, and partially because I only do that once every 6 months or so.)
It's like some UI designer didn't understand folders, then somehow forced their brain damaged mental model of them on the rest of the population. After that, for some reason I will never understand, the rest of the industry copied the design.
(I've worked on filesystem implementations, tested for POSIX compliance, debugged insane customer issues, etc, etc. I know how directories work...)
> It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
Which OS? For all its flaws (and there are many related to this issue, like overzealous hiding), macOS lets me add ~ as a 'Favourite' which then shows up in file choosers as well as the main file browser app.
Which OS? For all its flaws (and there are many related to this issue, like overzealous hiding), macOS lets me add ~ as a 'Favourite' which then shows up in file choosers as well as the main file browser app.
>It's like some UI designer didn't understand folders,
He probably didn't.
He probably didn't.
I think people in the web development space will continue to understand this concept. People who are curious will learn how the internals work.
For everyone else, who cares? Search is so good that it doesn’t matter where a file lives on your device. They don’t need to understand the internals of how directories work.
Good riddance! Even though people knew how to use files and folders no one did it well. It was a mess of “new directory” and “copy of copy of essay5.doc” I’m so thankful that most folks don’t have to deal with that anymore. They can use their computers instead of fighting them.
For everyone else, who cares? Search is so good that it doesn’t matter where a file lives on your device. They don’t need to understand the internals of how directories work.
Good riddance! Even though people knew how to use files and folders no one did it well. It was a mess of “new directory” and “copy of copy of essay5.doc” I’m so thankful that most folks don’t have to deal with that anymore. They can use their computers instead of fighting them.
I’m apparently young enough to be targeted by this article so I’ll weigh in. We’re better off for it, files as a storage layer and/or format (meaning how routes on web servers are defined by the folder structure) suuucks. File semantics are annoying, complicated enough that nobody really gets them right, and broken at the margins. The concept of a virtual read head and seeking around files would never be invented today. File descriptors keeping random external magic state? What could go wrong? All but a tiny few file operations not being atomic — bleugh. See the stuff Ansible has to do just to get atomic copy. Permissions, attrs, xattrs, acls, and SELinux tags are a god damn mess. Locking is also a mess and filesystem dependent — sqlite doesn’t officially support NFS because of it. And with all that useless metadata we still don’t have a way of actually reliably specifying the format or encoding of files leading to garbage library after garbage library for guessing it. File paths being binary strings on Linux is a ridiculous tripwire, running out of inodes or open file handles is a leaky abstraction, links — hard and soft are a bandaid and make traversal stupid to reason about. Look at the dumb shit tar has to do to deal with it. Holding handles to deleted files is absolutely ass backwards and a pox on the people that made it necessary for updates to work. File rotation just shouldn’t be necessary. The application having to think about compression is the wrong layer. Whoever invented unix:abstract files committed a warcrime.
If you’re someone who likes working with the filesystem directly, why? Seriously why? It really does seem like anything would be better.
Even for code, wouldn’t you rather things like Python modules or packages be first class objects? No more sys.path nonsense, no more namespacing, just your whole venv in a single trivially relocatable file.
If you’re someone who likes working with the filesystem directly, why? Seriously why? It really does seem like anything would be better.
Even for code, wouldn’t you rather things like Python modules or packages be first class objects? No more sys.path nonsense, no more namespacing, just your whole venv in a single trivially relocatable file.
Unless you are an engineer working directly with code concerning file systems, you don't need to know any of that. Well, maybe file permissions, but most people don't need to deal even with that in their daily uses of computers.
Being able to understand where your data is located in a computer and knowing how to manipulate them makes a lot of subsequent data management easier. For one, a file system is independent of any given piece of software. You don't need to rely on your word processing program knowing where your documents are, you can just tell it where your document is. You don't need to wrangle with sending a picture from your Photos program to your email program, you can tell your Photos program where to save the picture and you can just tell your email program where your picture is.
And did I say picture? Is it a JPEG? PNG? GIF? An abstraction of the file system won't tell me, but if I go look in the file system I can immediately tell what the picture is, and where it is too.
And like I just alluded to, you get to decide where the files reside too. Your Photos program might stuff all 6000 of your pictures under "C:\Program Files\VendorMcVendorface\Photos\userdata", and sure, that works, but that's nonsense. You could sort everything exactly how you want it where you want it. "C:\Photos\2006\Yosemite" for just all the pictures you took on a trip to Yosemite National Park in 2006, for example.
Admittedly, it's a feat that file systems have been successfully abstracted away for Joe Average, but not knowing how to navigate and use file systems is going to bite you in your arse when something inevitably comes around demanding you do it.
Understanding file systems is one of those bits of knowledge and wisdom in life you can do without, until you can't. And by then, you don't have time to call for a time out and get a crash course on it.
Being able to understand where your data is located in a computer and knowing how to manipulate them makes a lot of subsequent data management easier. For one, a file system is independent of any given piece of software. You don't need to rely on your word processing program knowing where your documents are, you can just tell it where your document is. You don't need to wrangle with sending a picture from your Photos program to your email program, you can tell your Photos program where to save the picture and you can just tell your email program where your picture is.
And did I say picture? Is it a JPEG? PNG? GIF? An abstraction of the file system won't tell me, but if I go look in the file system I can immediately tell what the picture is, and where it is too.
And like I just alluded to, you get to decide where the files reside too. Your Photos program might stuff all 6000 of your pictures under "C:\Program Files\VendorMcVendorface\Photos\userdata", and sure, that works, but that's nonsense. You could sort everything exactly how you want it where you want it. "C:\Photos\2006\Yosemite" for just all the pictures you took on a trip to Yosemite National Park in 2006, for example.
Admittedly, it's a feat that file systems have been successfully abstracted away for Joe Average, but not knowing how to navigate and use file systems is going to bite you in your arse when something inevitably comes around demanding you do it.
Understanding file systems is one of those bits of knowledge and wisdom in life you can do without, until you can't. And by then, you don't have time to call for a time out and get a crash course on it.
> Worth noting that the incoming younger generations can't and don't into file systems. [...] We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.
[the author here] The article is not about misunderstanding file-systems.
As I've commented earlier on a different thread, <https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.
[the author here] The article is not about misunderstanding file-systems.
As I've commented earlier on a different thread, <https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.
Not that I'm interested in arguing against your intent, but the second and third paragraphs clearly lay out the article is about the younger generations not knowing what a file system is.
I linked it here because, with regards to "already standardized the hosting side of static sites by using the file system", it means squat if the webmaster-to-be doesn't know what a file system is. There's no preconception of using files to hold and serve data from if you don't know (and possibly don't care) about file systems.
If we're going to be discussing attempts at changing the paradigm, then it stands to reason to understand the environment at large that might be encouraging it. If we're going to be talking about something replacing file systems for data storage, it's pertinent to know first of all that the younger generations give zero bits about files.
Also, SEO is at best a tangent to data storage and serving. Some webmasters might not even care to bother with SEO if they don't care about search engine rankings.
I linked it here because, with regards to "already standardized the hosting side of static sites by using the file system", it means squat if the webmaster-to-be doesn't know what a file system is. There's no preconception of using files to hold and serve data from if you don't know (and possibly don't care) about file systems.
If we're going to be discussing attempts at changing the paradigm, then it stands to reason to understand the environment at large that might be encouraging it. If we're going to be talking about something replacing file systems for data storage, it's pertinent to know first of all that the younger generations give zero bits about files.
Also, SEO is at best a tangent to data storage and serving. Some webmasters might not even care to bother with SEO if they don't care about search engine rankings.
That's fascinating! Young people struggling with files and folders just like my Mom does.
It's really not surprising.
The most familiar computer to young people, their smartphone, does everything to hide and abstract away the file system and even the fact that it's a computer.
When someone doesn't even realize a concept exists, it shouldn't come as a surprise they will struggle.
The most familiar computer to young people, their smartphone, does everything to hide and abstract away the file system and even the fact that it's a computer.
When someone doesn't even realize a concept exists, it shouldn't come as a surprise they will struggle.
More cynicism is warranted here. "Platform companies" like Google and Apple love it when users fail to understand how their devices work, because they get locked-in to the plaftorms. This is the successful end result of a long campaign of deliberate miseducation of users.
S3 is not competitive. Here:
https://neocities.org/supporter
https://neocities.org/supporter
Competitive by what metric? My site lives more or less entirely within the AWS free tier. I think my total AWS bill is around $20/mo, and 80% of that is for the stupid number of domain names I’m hosting zones for.
Quick question: Why wouldn't I use my free tier registrar DNS? Are there really that man DNS queries serviced cause you pay based off the number of responses? Especially if they are stupid domains.
As far as I can tell, there’s only 2 upsides I’m getting by using AWS as a registrar:
1. I’m lazy, and I already manage a bunch of other stuff in AWS, so it’s convenient for me to have the domains in the same place
2. For some of the domains, I’m serving records that point to other AWS resources (like Cloudfront and S3). AWS’s Route53 has clever helper features when you’re pointing records at other AWS services).
Otherwise, you’re right that there’s plenty of registrars that’ll do perfectly solid DNS
1. I’m lazy, and I already manage a bunch of other stuff in AWS, so it’s convenient for me to have the domains in the same place
2. For some of the domains, I’m serving records that point to other AWS resources (like Cloudfront and S3). AWS’s Route53 has clever helper features when you’re pointing records at other AWS services).
Otherwise, you’re right that there’s plenty of registrars that’ll do perfectly solid DNS
For me my static sites are small enough that it all falls within the free tier and I can deploy everything using the CDK.
If you're ok with using Cloudflare's free plan for your DNS, you can stop paying for each hosted zone.
"HTML on disk" does not cover headers.
But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.
But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.
> [...] the article somehow concludes that bringing your own server with the right configuration is not an option.
[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)
However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.
Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.
[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)
However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.
Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.
But do you really need different headers for different resources for a static site? I can imagine a distinct "downloads" folder maybe, but not much more.
Just using the file system is inadequate for some reasons that TFA mentions. For instance, returning gzip or Brotli compressed versions of resources, or returning HTTP 301/302 redirects for certain requests.
Also if you use CloudFront be aware you'll be paying for bandwidth, so if one of your pieces goes viral (or you're just a popular writer) the cost can be surprisingly high (over $50/mo).
Also if you use CloudFront be aware you'll be paying for bandwidth, so if one of your pieces goes viral (or you're just a popular writer) the cost can be surprisingly high (over $50/mo).
Pretty sure you can stay in free tier without a CC on file though? So assume they’d just deactivate your services if you breach free tier resources for the month..(?)
> check that with/without .html extension serving works properly; (i.e. /some-file.html should perhaps return the same content as /some-file, or even better, choose one as canonical and redirect for the other one;)
Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect?
If your canonical URL is /example, I see no reason at all to support .html. If it’s /example.html, I see no particular reason to support /example or /example/. If it’s /example/, there may be a smidgeon of value in supporting /example. If it’s /example and you ever have paths below that (/example/example), then there may be slight value in supporting /example/.
If you switch from one format to another, do ensure that all existing URLs work. I used to use .html, so my old *.html URLs now redirect to */, but only for old articles, not new ones that were never .html, because I like being fancy like that.
But overall, I say: for at least the .html and trailing slash suffixes, no software should ever be causing these errors (I have heard rumours of improper transformations once or twice, but seen no evidence, and neither of these are ambiguous “will the automatic linkifier include or exclude that punctuation at the end” cases), so it’s all about humans and what incorrect URLs they might type out. And most of these sorts of things, people just won’t do.
Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.
Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect?
If your canonical URL is /example, I see no reason at all to support .html. If it’s /example.html, I see no particular reason to support /example or /example/. If it’s /example/, there may be a smidgeon of value in supporting /example. If it’s /example and you ever have paths below that (/example/example), then there may be slight value in supporting /example/.
If you switch from one format to another, do ensure that all existing URLs work. I used to use .html, so my old *.html URLs now redirect to */, but only for old articles, not new ones that were never .html, because I like being fancy like that.
But overall, I say: for at least the .html and trailing slash suffixes, no software should ever be causing these errors (I have heard rumours of improper transformations once or twice, but seen no evidence, and neither of these are ambiguous “will the automatic linkifier include or exclude that punctuation at the end” cases), so it’s all about humans and what incorrect URLs they might type out. And most of these sorts of things, people just won’t do.
Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.
> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect?
At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. drops the slash; sometimes even the site owner forgets be consistent. Thus having those redirects in place means not having dead links pointing to your site.
With regard the `.html`, with and without, it's a matter of taste... However, the same point applies, perhaps you've been inconsistent along the years, thus having redirects saves the dead links...
However you are right about the "canonical" URL: for search engine purposes, having a single page serving the content, and the rest being redirects, is kind of essential. (Or at least having a `<link rel="canonical" ...>` if not a redirect.)
> Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.
It is when you don't want dead links. :)
At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. drops the slash; sometimes even the site owner forgets be consistent. Thus having those redirects in place means not having dead links pointing to your site.
With regard the `.html`, with and without, it's a matter of taste... However, the same point applies, perhaps you've been inconsistent along the years, thus having redirects saves the dead links...
However you are right about the "canonical" URL: for search engine purposes, having a single page serving the content, and the rest being redirects, is kind of essential. (Or at least having a `<link rel="canonical" ...>` if not a redirect.)
> Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.
It is when you don't want dead links. :)
You seem to have missed a good chunk of what I said.
But to address some particular points:
> sometimes the application he is using for bookmarking, sharing, etc. drops the slash
Do you happen to have any evidence of this? I’ve heard it mentioned very occasionally, but never seen it, including any probability of it in logs (though I have seen more bizarre things), and the only ways I can imagine it being likely to happen would break many other things too, so that it doesn’t seem likely.
> perhaps you've been inconsistent along the years, thus having redirects saves the dead links...
And so I strongly advocate for retaining such redirects. Just not gratuitous support for other things.
> It is when you don't want dead links.
I said for the sake of it. If by “dead links” you mean “existing URLs that worked in the past”, that’s not “for the sake of it”, but good cause. But if you’re speaking about proactively allowing things that never worked in the past, that’s exactly what I’m arguing against. I want robust justification for every extra URL that is supported, of the machine or human that is likely to encounter it and why. (As an example of this, I’d honestly quite enjoy returning 400 for requests with unknown query strings parameters, which in the context of static websites mostly means any query string, in order to truly have only one URL for the content; but I acknowledge that this is not pragmatic because it’s not uncommon to inject additional query string parameters, typically for the purpose of spying on users in unwanted utm_* parameters and the likes.)
But to address some particular points:
> sometimes the application he is using for bookmarking, sharing, etc. drops the slash
Do you happen to have any evidence of this? I’ve heard it mentioned very occasionally, but never seen it, including any probability of it in logs (though I have seen more bizarre things), and the only ways I can imagine it being likely to happen would break many other things too, so that it doesn’t seem likely.
> perhaps you've been inconsistent along the years, thus having redirects saves the dead links...
And so I strongly advocate for retaining such redirects. Just not gratuitous support for other things.
> It is when you don't want dead links.
I said for the sake of it. If by “dead links” you mean “existing URLs that worked in the past”, that’s not “for the sake of it”, but good cause. But if you’re speaking about proactively allowing things that never worked in the past, that’s exactly what I’m arguing against. I want robust justification for every extra URL that is supported, of the machine or human that is likely to encounter it and why. (As an example of this, I’d honestly quite enjoy returning 400 for requests with unknown query strings parameters, which in the context of static websites mostly means any query string, in order to truly have only one URL for the content; but I acknowledge that this is not pragmatic because it’s not uncommon to inject additional query string parameters, typically for the purpose of spying on users in unwanted utm_* parameters and the likes.)
[deleted]
> the cloud operator, given that all of the above choices are self-hosted (or at least require some system administration skills), would immediately go for a hosted solution like CloudFlare Pages, Netlify, Vercel, or one of the source code hosting sites that also have static site hosting solutions like SourceHut pages or GitHub pages;
i think of myself as a graybeard (in the article's parlance; i find the term exclusionary) and i use cloudflare in front of github pages. every year i've spent as this craft has seen me accumulate more than a year's worth of new things i'd like to program or learn, 30 years in the list is very long. spending my time and energy doing IT for a static web site is a major waste
i think of myself as a graybeard (in the article's parlance; i find the term exclusionary) and i use cloudflare in front of github pages. every year i've spent as this craft has seen me accumulate more than a year's worth of new things i'd like to program or learn, 30 years in the list is very long. spending my time and energy doing IT for a static web site is a major waste
Yeah exactly. As I am saying to another person in this comment section here: it's not about if I can do do the thing in HTML+CSS and upload it. Of course I can. But it's extremely low in my list of priorities. I prefer to write a Markdown article, run just one command, preview locally and if happy, do a `git push` -- the rest is being handled for me.
Way too many people wear their meaningless manual busywork as a badge of honor.
No time or patience for that crap. These are the things that the computers were invented to do. Let them, they do it better. You are a creative force, use your energy on creative endeavours, not on pointless BS.
I, like you, have no less than 500 things in my mental (and partially written) backlog to "check one day". I want to eventually get to that point, not to write HTML.
Way too many people wear their meaningless manual busywork as a badge of honor.
No time or patience for that crap. These are the things that the computers were invented to do. Let them, they do it better. You are a creative force, use your energy on creative endeavours, not on pointless BS.
I, like you, have no less than 500 things in my mental (and partially written) backlog to "check one day". I want to eventually get to that point, not to write HTML.
I guess everyone has their own solution to this. Here's mine:
- Write some static html and one stylesheet
- Pay DigitalOcean for the cheap plan
- Run nginx + letsencrypt
- Apply linux security updates promptly
- Occasionally pay to renew the domain
So yeah, that does take a little bit of (very simple) systems administration skills, and it's a recurring commitment. But there is no such thing as a successful but unmaintained web site. Even if you don't have to maintain the infrastructure, you have to maintain the content. So I don't mind the occasional maintenance tasks. They keep me in touch with linux systems administration in a good way.
It's cool to write your own web server software, I guess. But serving static html is pretty much a solved problem. I felt like the OP was inventing problems with it that don't really exist in practice.
- Write some static html and one stylesheet
- Pay DigitalOcean for the cheap plan
- Run nginx + letsencrypt
- Apply linux security updates promptly
- Occasionally pay to renew the domain
So yeah, that does take a little bit of (very simple) systems administration skills, and it's a recurring commitment. But there is no such thing as a successful but unmaintained web site. Even if you don't have to maintain the infrastructure, you have to maintain the content. So I don't mind the occasional maintenance tasks. They keep me in touch with linux systems administration in a good way.
It's cool to write your own web server software, I guess. But serving static html is pretty much a solved problem. I felt like the OP was inventing problems with it that don't really exist in practice.
I used to do something similar, but DigitalOcean App Platform's $0/month "starter" plan[0] hosts a static site for even less effort.
When I was self-hosting on a DigitalOcean droplet, I was using Caddy instead of nginx, which handled letsencrypt for me, so that was nice.
[0]: https://www.digitalocean.com/pricing/app-platform
When I was self-hosting on a DigitalOcean droplet, I was using Caddy instead of nginx, which handled letsencrypt for me, so that was nice.
[0]: https://www.digitalocean.com/pricing/app-platform
I'm using Caddy with Docker labels auto-configuration.
It's somewhat PITA to configure if you don't need a public cert, eg something for testing or not having a public A/AAAA record, but otherwise the automagik just works.
The only negative moment is what Caddy container restarts when the dependent containers starts|restarts, so you briefly lose all connectivity to all sites behind Caddy.
[0] https://github.com/lucaslorentz/caddy-docker-proxy
It's somewhat PITA to configure if you don't need a public cert, eg something for testing or not having a public A/AAAA record, but otherwise the automagik just works.
The only negative moment is what Caddy container restarts when the dependent containers starts|restarts, so you briefly lose all connectivity to all sites behind Caddy.
[0] https://github.com/lucaslorentz/caddy-docker-proxy
There are also security implications that the webserver has access to the socket directly.
> Each caddy docker proxy instance can be executed in one of the following modes.
> Server
> Acts as a proxy to your Docker resources. The server starts without any configuration, and will not serve anything until it is configured by a "controller".
> Server instances doesn't need access to Docker host socket and you can run it in manager or worker nodes.
This can be mitigated by running in the Controller mode
> Server
> Acts as a proxy to your Docker resources. The server starts without any configuration, and will not serve anything until it is configured by a "controller".
> Server instances doesn't need access to Docker host socket and you can run it in manager or worker nodes.
This can be mitigated by running in the Controller mode
Let the updates run automatically. Put certbot on a cron. Ride it until ubuntu LTS I am on dies. So easy. :)
You can also use Caddy in place of NGINX and let it handle Lets Encrypt for you :)
I hadn’t really touched caddy in a while. For a static site I may just do that if my cron script ever falls over. I was also feeling hipster and wanted to play with Justine’s redbean. It is sort of appealing to just drop a binary off somewhere and be done with it, but like `apt install nginx` is also trivial as a user :)
Static hosting on VPS cite is easy as hell. Get a VPS with Ubuntu 22.04 for as low as 3 Euros/Month, execute the following commands:
```
sudo apt-get install -y nginx python3-certbot-nginx certbot sudo ufw allow "Nginx Full" sudo unlink /etc/nginx/sites-enabled/default sudo mkdir -p /srv/https/website sudo chown -vR $MYUSER:$MYUSER /srv/https/website
echo "I've created my website here." > /srv/https/website/index.html
cat > conf <<- EOM server { listen 80; listen [::]:80;
sudo cp config /etc/nginx/sites-available/website sudo ln -s /etc/nginx/sites-available/website /etc/nginx/sites-enabled/website sudo certbot --nginx -n -d $URL --agree-tos --redirect -m $EMAIL --webroot -w /srv/https/website ```
Setup your DNS to the IP of VPS and you're done setting up your static website. Updates now are just `rsync`
```
sudo apt-get install -y nginx python3-certbot-nginx certbot sudo ufw allow "Nginx Full" sudo unlink /etc/nginx/sites-enabled/default sudo mkdir -p /srv/https/website sudo chown -vR $MYUSER:$MYUSER /srv/https/website
echo "I've created my website here." > /srv/https/website/index.html
cat > conf <<- EOM server { listen 80; listen [::]:80;
root /srv/https/website;
index index.html;
server_name $URL;
location / {
try_files \$uri \$uri/ =404;
}sudo cp config /etc/nginx/sites-available/website sudo ln -s /etc/nginx/sites-available/website /etc/nginx/sites-enabled/website sudo certbot --nginx -n -d $URL --agree-tos --redirect -m $EMAIL --webroot -w /srv/https/website ```
Setup your DNS to the IP of VPS and you're done setting up your static website. Updates now are just `rsync`
Yeah but what about SSL? You’ll need a handful of more lines of nginx, plus a script that runs once a month or so to get a new LetsEncrypt cert. Supposing that script you write or copy/paste works, now you’re good.
Until your site gets mentioned on HN or other social media. If you are in fact using a 3 euro/month VPS you’re almost certainly sharing 1-2 CPU cores with some other colocated VPSes. If your site gets a sudden surge in demand (and particularly if you have any images or video on your site) you’re either going to get hugged to death, or worse, people will complain that your site loads slowly and accuse you of writing too much JS.
My recommendation is to use Github/GitLab pages with a free Cloudflare in front for caching and SSL. That’s the setup I use for my site (https://chrisuehlinger.com, but grumps beware: it is absolutely soaked in JS). It’s free/month, doesn’t require moving parts like a manually rolled LetsEncrypt bot, and holds up when my site gets traffic.
Until your site gets mentioned on HN or other social media. If you are in fact using a 3 euro/month VPS you’re almost certainly sharing 1-2 CPU cores with some other colocated VPSes. If your site gets a sudden surge in demand (and particularly if you have any images or video on your site) you’re either going to get hugged to death, or worse, people will complain that your site loads slowly and accuse you of writing too much JS.
My recommendation is to use Github/GitLab pages with a free Cloudflare in front for caching and SSL. That’s the setup I use for my site (https://chrisuehlinger.com, but grumps beware: it is absolutely soaked in JS). It’s free/month, doesn’t require moving parts like a manually rolled LetsEncrypt bot, and holds up when my site gets traffic.
> Yeah but what about SSL? You’ll need a handful of more lines of nginx, plus a script that runs once a month or so to get a new LetsEncrypt cert. Supposing that script you write or copy/paste works, now you’re good.
The setup might be a bit more involved, but nothing that can’t fit in a single Bash script.
> Until your site gets mentioned on HN or other social media. If you are in fact using a 3 euro/month VPS you’re almost certainly sharing 1-2 CPU cores with some other colocated VPSes. If your site gets a sudden surge in demand (and particularly if you have any images or video on your site) you’re either going to get hugged to death, or worse, people will complain that your site loads slowly and accuse you of writing too much JS.
An HN “hug of death” is a laughably small amount of traffic for a static file web server. Nginx can serve hundreds of static HTML/JS/CSS files per second even on a cheap VPS.
> My recommendation is to use Github/GitLab pages with a free Cloudflare in front for caching and SSL. That’s the setup I use for my site (https://chrisuehlinger.com, but grumps beware: it is absolutely soaked in JS). It’s free/month, doesn’t require moving parts like a manually rolled LetsEncrypt bot, and holds up when my site gets traffic.
I’m sure that setup works well for you, but it’s overkill for serving static files. Unless you’re a truly special case, literally everything you need can be handled in a single VPS, which is dead simple to manage and very easy to move around if needed.
The setup might be a bit more involved, but nothing that can’t fit in a single Bash script.
> Until your site gets mentioned on HN or other social media. If you are in fact using a 3 euro/month VPS you’re almost certainly sharing 1-2 CPU cores with some other colocated VPSes. If your site gets a sudden surge in demand (and particularly if you have any images or video on your site) you’re either going to get hugged to death, or worse, people will complain that your site loads slowly and accuse you of writing too much JS.
An HN “hug of death” is a laughably small amount of traffic for a static file web server. Nginx can serve hundreds of static HTML/JS/CSS files per second even on a cheap VPS.
> My recommendation is to use Github/GitLab pages with a free Cloudflare in front for caching and SSL. That’s the setup I use for my site (https://chrisuehlinger.com, but grumps beware: it is absolutely soaked in JS). It’s free/month, doesn’t require moving parts like a manually rolled LetsEncrypt bot, and holds up when my site gets traffic.
I’m sure that setup works well for you, but it’s overkill for serving static files. Unless you’re a truly special case, literally everything you need can be handled in a single VPS, which is dead simple to manage and very easy to move around if needed.
This is great but what the article is about that you're underestimating is the decision anxiety and subsequent complexity of arriving at the specific configuration you've posted.
Even after you've for some reason decided on which tech to use (nginx, etc.), it doesn't set itself up (well it does but not in as easy-to-use config as yours). Examples of how to configure it well are going to vary depending on where you read - your example is unique, which should one follow.
Or if you want to create your own config from scratch reading docs, I'm sure your configuration is the product of many hours of trial and error and a bit of debugging.
---
As an aside, for anyone reading this who is looking for a good static hosting setup, this is a great one.
Even after you've for some reason decided on which tech to use (nginx, etc.), it doesn't set itself up (well it does but not in as easy-to-use config as yours). Examples of how to configure it well are going to vary depending on where you read - your example is unique, which should one follow.
Or if you want to create your own config from scratch reading docs, I'm sure your configuration is the product of many hours of trial and error and a bit of debugging.
---
As an aside, for anyone reading this who is looking for a good static hosting setup, this is a great one.
> This is great but what the article is about that you're underestimating is the decision anxiety and subsequent complexity of arriving at the specific configuration you've posted.
The same can be said about finding your static site generator, your favorite social media, the color of your car, your home deco, the race of your next dog...
If you want a life where people do the choices for you and stuff edibles into your mouth, there is one easy solution: a nursing home.
The same can be said about finding your static site generator, your favorite social media, the color of your car, your home deco, the race of your next dog...
If you want a life where people do the choices for you and stuff edibles into your mouth, there is one easy solution: a nursing home.
That's fair but...
- SSGs do have some of the same problems as mentioned in the articles. Selection could be easier.
- Social media is mostly selected based on networks, so that's not as relevant here.
- Colour of your car, home deco.... "race"? of your next dog are subjective/aesthetic and not as functionally imperative. So not quite so comparable.
Taking your car analogy and looking at selecting - say - the model of car, this is much easier. They're broadly arranged into obvious well-understand functional categories, and unless you're a dedicated car nut who WANTS to invest time & energy into customisation, they generally are drivable and function well straight out of the lot. Much easier to set up than a static host or SSG.
- SSGs do have some of the same problems as mentioned in the articles. Selection could be easier.
- Social media is mostly selected based on networks, so that's not as relevant here.
- Colour of your car, home deco.... "race"? of your next dog are subjective/aesthetic and not as functionally imperative. So not quite so comparable.
Taking your car analogy and looking at selecting - say - the model of car, this is much easier. They're broadly arranged into obvious well-understand functional categories, and unless you're a dedicated car nut who WANTS to invest time & energy into customisation, they generally are drivable and function well straight out of the lot. Much easier to set up than a static host or SSG.
I switched from Vercel static site hosting, because I recently read an article here about how it's usually more economical to scale vertically instead of horizontally (i.e. use one big server for everything).
Even though I'm only running a few services, I did the math and realized it's absolutely true. I can fit everything I'm running onto one DigitalOcean droplet behind Cloudflare for $24/month + an extra 25gb block storage for $2.5/month + $5/month for backblaze backups.
Everything being: a bunch of static sites, Keycloak Auth, Rocket.Chat, Odoo business management software, Nginx Proxy Manager, Outline (self hosted Notion), Docker, Portainer, Cockpit, Listmonk.
Static sites are free actually, besides storage. You can just add a location directive pointing to the folder in Nginx Proxy Manager and it'll serve the files for you.
The biggest memory hog is Keycloak which is a Java app so it uses 700mb of ram.
But in any case I have set up an entire small business software suite with a hosting cost of $31.5 and I can host unlimited static sites with no additional cost.
Even though I'm only running a few services, I did the math and realized it's absolutely true. I can fit everything I'm running onto one DigitalOcean droplet behind Cloudflare for $24/month + an extra 25gb block storage for $2.5/month + $5/month for backblaze backups.
Everything being: a bunch of static sites, Keycloak Auth, Rocket.Chat, Odoo business management software, Nginx Proxy Manager, Outline (self hosted Notion), Docker, Portainer, Cockpit, Listmonk.
Static sites are free actually, besides storage. You can just add a location directive pointing to the folder in Nginx Proxy Manager and it'll serve the files for you.
The biggest memory hog is Keycloak which is a Java app so it uses 700mb of ram.
But in any case I have set up an entire small business software suite with a hosting cost of $31.5 and I can host unlimited static sites with no additional cost.
There's a bit of risk to having all your eggs in one basket.
One is security, although containers mitigate that. Another is resource allocation. If one piece of software hogs all the resources, others will suffer.
Personally I split things just because it matches my mental model. My personal website runs somewhere. My professional website runs somewhere else. My home server gets its own dedicated hardware.
One is security, although containers mitigate that. Another is resource allocation. If one piece of software hogs all the resources, others will suffer.
Personally I split things just because it matches my mental model. My personal website runs somewhere. My professional website runs somewhere else. My home server gets its own dedicated hardware.
The other problem is that one goes down, they all go down. A static website has absolutely no reason to go down.
Hardly a problem for a personal blog.
I host a few things on my baremetal server at home. When I get kernel updates (2-3 times a month) the Docker container with the Pi-Hole is rebooted and for 30 secs DNS resolution doesn't work in our home network. I probably can fix that by changing the script to do blue-green deployment (only stop the container after a new one has been brought up) but it honestly isn't such a problem.
If it bothers me I will likely spend no more than one hour to fix it.
I host a few things on my baremetal server at home. When I get kernel updates (2-3 times a month) the Docker container with the Pi-Hole is rebooted and for 30 secs DNS resolution doesn't work in our home network. I probably can fix that by changing the script to do blue-green deployment (only stop the container after a new one has been brought up) but it honestly isn't such a problem.
If it bothers me I will likely spend no more than one hour to fix it.
It's all containerized. The only reason for it to go down is if DO or CF have an outage. Which is rare enough that it's not an issue for me.
But often does because the host, external lib or cloudfaire has an issue.
There's also HTTP HEAD requests, and "304 Not Changed" that you need to take care of. This is what makes static site download look instantaneous. There's more of such optimizations.
With all these I find it better to stick with old Apache or similar service for speed, rather than a simpler service that only takes care of GET.
With all these I find it better to stick with old Apache or similar service for speed, rather than a simpler service that only takes care of GET.
If one has the pre-generated response for a "simple" `GET` request (one that doesn't use conditional headers, ranges, or other advanced HTTP features), then a server could easily generate proper responses (based on that simple response) to any such complex requests. For example:
* `HEAD` is just taking the `GET` response and replying with just the headers (no body);
* if the pre-generated `GET` response contains an `ETag` header, then the server could easily handle an `If-Match` and `If-None-Match`; (else, such a static server implementation could fallback for each resource with a temporary generated `ETag` that is obtained by hashing the path of the resource and some random token generated when the server was started;)
* if the pre-generated `GET` response contains a `Last-Modified` header, then the server could easily handle `If-Modifiend-Since` and other related conditional requests; (else, the server could just consider that all resources have the `Last-Modified` header equal to the moment the server was started;)
* if the client requests a range of that resource, the server could easily respond with a slice of the stored `GET` response;
In fact, what I describe here is nothing out of the ordinary, all caching proxies do exactly this: they store the "simple" `GET` response, and then they derive all other responses based on that.
* `HEAD` is just taking the `GET` response and replying with just the headers (no body);
* if the pre-generated `GET` response contains an `ETag` header, then the server could easily handle an `If-Match` and `If-None-Match`; (else, such a static server implementation could fallback for each resource with a temporary generated `ETag` that is obtained by hashing the path of the resource and some random token generated when the server was started;)
* if the pre-generated `GET` response contains a `Last-Modified` header, then the server could easily handle `If-Modifiend-Since` and other related conditional requests; (else, the server could just consider that all resources have the `Last-Modified` header equal to the moment the server was started;)
* if the client requests a range of that resource, the server could easily respond with a slice of the stored `GET` response;
In fact, what I describe here is nothing out of the ordinary, all caching proxies do exactly this: they store the "simple" `GET` response, and then they derive all other responses based on that.
[deleted]
Just because there are a lot of options, doesn't make something complicated. Hosting a static site - arguably the simplest kind of site - could be easily done with any of the options listed and derided at the start of the article.
Sobering, eye-opening, and encouraging in one swell foop. I am bookmarking & backing this page up because it coalesces many many issues that have been plaguing me with static site generation.
Well done.
Well done.
I'm very confused by this entire post.
No mention of neocities or shared/managed hosts (Namecheap or even GoDaddy?)
I mean, I know we nerds look down upon GoDaddy and other such sites, but it's cheaper than setting up a VPS and good enough for any static site.
No mention of neocities or shared/managed hosts (Namecheap or even GoDaddy?)
I mean, I know we nerds look down upon GoDaddy and other such sites, but it's cheaper than setting up a VPS and good enough for any static site.
GitHub Pages works well for me.
https://pages.github.com/
https://pages.github.com/
One of the features I don't think Fastmail advertise at all is that you can host static websites from your user storage - with HTTPS etc. You can use one of their subdomains or your own domain, it can do photo galleries I think as well as redirects.
Last month I paid $1 for route53, 12 cents for S3. and am hosting my https site which I create with publii. Works fine. Took a little time to set up, but now it is just a button push to update the site. Great for my personal blog and phtot gallery.
I pay 80 cents for the same as you. I only have 1 domain on route53. But I do also have a Lambda and API_GW mixed in there that get's infrequent to zero use.
Yeah I went with Netlify for my static site because I have zero desire to ever been an IT admin.
I do skip the static generator part and go with artisinally hand crafted HTML/CSS/JS instead. It’s radically simpler and ultimately better imho.
I do skip the static generator part and go with artisinally hand crafted HTML/CSS/JS instead. It’s radically simpler and ultimately better imho.
How do you get your content into Netlify? They push the CI/CD angle pretty hard (sometimes to the exclusion of other things; e.g. bugs in the CLI that break things if you aren't on their expected/happy path) and the fetishization of GitHub-integrated CI/CD leads to stuff that is about as complex as the traditional undesirable IT overhead.
My static website is in a private GitHub repo. I simply push to that.
Because my site is not statically generated there’s no real complexity here? When I’m working on it locally I simply open a .html file from my local drive in a browser. When I’m done I push to GitHub and Netlify updates in seconds.
Because my site is not statically generated there’s no real complexity here? When I’m working on it locally I simply open a .html file from my local drive in a browser. When I’m done I push to GitHub and Netlify updates in seconds.
If that's a concern, you can choose to deploy your site from a .zip file uploaded straight to Netlify
I used to use Amazon but something broke somewhere and I haven' fixed it. Netlify was very low effort on my part. However I really like the idea of this approach as it helps feed into owning your own data. So I may have another go using this.
I just use a VPS, Caddy with a 10 line Caddyfile and scp my html on to the machine.
I don't find any real hurdles here and the only thing running on the server is Caddy to serve the content on https/http. Anything that's not a valid path returns a 404 custom page I made and that's it.
To get my HTML I use Hugo locally, but I'm not a huge fan of Hugo itself due to it's documentation which cannot be followed linearly and I plan on writing something to do just this - convert some markdown files and a folder structure to an HTML. I'm sure such a tool already exists but I'm curious about building something like this myself.
I think the hurdles appear depending on what you expect or want to do with your static page, but the base setup is I think pretty straightforward.
I don't find any real hurdles here and the only thing running on the server is Caddy to serve the content on https/http. Anything that's not a valid path returns a 404 custom page I made and that's it.
To get my HTML I use Hugo locally, but I'm not a huge fan of Hugo itself due to it's documentation which cannot be followed linearly and I plan on writing something to do just this - convert some markdown files and a folder structure to an HTML. I'm sure such a tool already exists but I'm curious about building something like this myself.
I think the hurdles appear depending on what you expect or want to do with your static page, but the base setup is I think pretty straightforward.
I read this as:
The problem is there are 99 ways to do to it from sysadmin-y to cloud-y.
My solution is to add 100th way.
——-
If static hosting is hard use Netlify or similar. Just point it at your Github and you are done!
They mentioned Netlify.
The problem is there are 99 ways to do to it from sysadmin-y to cloud-y.
My solution is to add 100th way.
——-
If static hosting is hard use Netlify or similar. Just point it at your Github and you are done!
They mentioned Netlify.
This is less of an article, and more of an advertisement for cloudflare..
No, you don't need a CDN for your lightweight static site. nginx and your home fiber gigabit connection will do _JUST_FINE_ (tm), even when slashdotted or getting on frontpage at HN.
Also, just drop the generators and write your html already.. Sure, it's fun to learn a new toy, but in end, any abstraction between your content and the HTML being served is just another link in the chain of things that can break.
Organize your HTML files well, use minimal styling and it becomes quite managable, you literally don't have a technology stack.. just dump the files on ANYTHING IN THE UNIVERSE that has a webserver and a file system, and you're good to go.
No, you don't need a CDN for your lightweight static site. nginx and your home fiber gigabit connection will do _JUST_FINE_ (tm), even when slashdotted or getting on frontpage at HN.
Also, just drop the generators and write your html already.. Sure, it's fun to learn a new toy, but in end, any abstraction between your content and the HTML being served is just another link in the chain of things that can break.
Organize your HTML files well, use minimal styling and it becomes quite managable, you literally don't have a technology stack.. just dump the files on ANYTHING IN THE UNIVERSE that has a webserver and a file system, and you're good to go.
[the author here] Indeed I mention Cloudflare quite a lot, and that is for two reasons:
(A) If you do want to have a performant website (be it static or dynamic) you do need a CDN with edge caching; else the physics with it's insistence on a cap for the light speed will put a minimum theoretical latency of 25ms say between Bucharest and Toronto, which in practical terms translates towards at least 100ms one way, or 300ms just to establish a TCP connection, and around 500 for a complete TLS handshake... And no amount of bandwidth can solve that.
(B) Cloudflare is the only free choice that allows you to use your own domain and that doesn't impose any (published) limits on your usage. If you know of other CDN providers that give you this for free please let me know and I'll add their link to the article.
(A) If you do want to have a performant website (be it static or dynamic) you do need a CDN with edge caching; else the physics with it's insistence on a cap for the light speed will put a minimum theoretical latency of 25ms say between Bucharest and Toronto, which in practical terms translates towards at least 100ms one way, or 300ms just to establish a TCP connection, and around 500 for a complete TLS handshake... And no amount of bandwidth can solve that.
(B) Cloudflare is the only free choice that allows you to use your own domain and that doesn't impose any (published) limits on your usage. If you know of other CDN providers that give you this for free please let me know and I'll add their link to the article.
A modest middleway is using Server Side Includes (SSI) to do simple templating stuff. It works on Apache, nginx — and Caddy as well. Its a nice combo of "no stack" and some dynamic elements in your HTML and CSS.
One forgotten hurdle of static site hosting is in-memory caching.
At most http-server default setup each request goes down to the filesystem.
Mostly your are lucky and your filesystem itself has some kind of caching mechanism, so you won't notice.
But if your static site ends up in a "very high requests" situation, you should think about in-memory caching of your static files.
With nginx you should set static files to be on a separate cookieless domain and proxied to a different port with the nginx cache keys set how you want them.
You should be using brotli dialled up to 11 for scripts and stylesheets. This takes ages to do if done on the fly but works great if using an nginx cache.
Images need to be on another cookieless domain with the cache configured to work with accept headers, in that way you can serve webp instead of jpg, again with the wonder cache able to serve jpg to Internet Explorer and curl, with real browsers getting webp from cache.
Nowadays you can use nginx to convert to webp, I use VIPS instead so my thumbnail generator goes from source to webp without an intermediary step with the resized image stored as jpg.
Building an origin server for a CDN is a different task to building a regular server. The focus for cached resources is getting the byte size down, not serving a billion requests at once. The CDN can do that.
After I built my nginx proxy with cache I was happy with what happens with memory and how the Linux strengths are leveraged with no wheels reinvented.
You should be using brotli dialled up to 11 for scripts and stylesheets. This takes ages to do if done on the fly but works great if using an nginx cache.
Images need to be on another cookieless domain with the cache configured to work with accept headers, in that way you can serve webp instead of jpg, again with the wonder cache able to serve jpg to Internet Explorer and curl, with real browsers getting webp from cache.
Nowadays you can use nginx to convert to webp, I use VIPS instead so my thumbnail generator goes from source to webp without an intermediary step with the resized image stored as jpg.
Building an origin server for a CDN is a different task to building a regular server. The focus for cached resources is getting the byte size down, not serving a billion requests at once. The CDN can do that.
After I built my nginx proxy with cache I was happy with what happens with memory and how the Linux strengths are leveraged with no wheels reinvented.
> Building an origin server for a CDN is a different task to building a regular server. The focus for cached resources is getting the byte size down, not serving a billion requests at once. The CDN can do that.
I think this put perfectly in words what I've believed for some time, but failed to compile into words...
However, having once you've gotten your cached resources down to the smallest size, you can now also optimize for serving a lot of them at once. :)
I think this put perfectly in words what I've believed for some time, but failed to compile into words...
However, having once you've gotten your cached resources down to the smallest size, you can now also optimize for serving a lot of them at once. :)
I'd be nice to run a self-hosted site from a home server. Currently paying a third party for a static site, but space is so limited. Storage space isn't that expensive, until you have to pay monthly for it. Mostly just want to host my own pictures.
Would really like a hands on workshop to learn to do it (how to get a static IP, setup everything correctly, how to use https).
Would really like a hands on workshop to learn to do it (how to get a static IP, setup everything correctly, how to use https).
It costs me about 1 dollar a month (never more than 2 dollars) to host my website.
I use:
- VuePress
- Amazon S3
- Amazon Certificate Manager
- Amazon CloudFront
- Amazon Route53
For deployment:
- CircleCI
- s3deploy
It's a super simple (and cheap) setup. Just push a commit and the site gets updated.
I use:
- VuePress
- Amazon S3
- Amazon Certificate Manager
- Amazon CloudFront
- Amazon Route53
For deployment:
- CircleCI
- s3deploy
It's a super simple (and cheap) setup. Just push a commit and the site gets updated.
Hi, what do you use circleCI for here?
Why would you ever host a static site yourself? There is nothing special about it, it's just text. Use any of the dozen different free static site hosters.
If you're just trying to learn web server tech, then do it all yourself, but jump through the hoops too; don't use a tool that does it all for you, that defeats the purpose.
If you're just trying to learn web server tech, then do it all yourself, but jump through the hoops too; don't use a tool that does it all for you, that defeats the purpose.
Ok so let's make a UI that asks for your credit card and which host you want... This has nothing to do with the web servers IMO. Even if we give people the configuration done there will still be other issues. It has to be as easy as pressing one "go online" button, really.
Cloudflare has free hosting for static content. there are some limits, but my sites are tiny.
The limits are actually pretty darn extreme for CF Pages — no bandwidth limits, 20000 files, and 500 deployments per day.
It's mind-boggling for me to read the comment section with people paying (and recommending!) anything above 0$/mo for static page hosting, because most likely GitHub / CF Pages can handle more requests than that and requires zero maintenance.
It's mind-boggling for me to read the comment section with people paying (and recommending!) anything above 0$/mo for static page hosting, because most likely GitHub / CF Pages can handle more requests than that and requires zero maintenance.
I think these issues only exist if you decided to host the site yourself, I did and currently optimizing Caddy settings, but kawipiko surely seems interesting, however I use caddy as a reverse proxy too, so I can't switch.
If you just to chose to use Cloudflare Pages you will get the best settings, and performance by default, its effortless.
I self host because Cloudflare already has enough control on the internet, it serves more than 20% of the web!
https://w3techs.com/technologies/history_overview/web_server
If you just to chose to use Cloudflare Pages you will get the best settings, and performance by default, its effortless.
I self host because Cloudflare already has enough control on the internet, it serves more than 20% of the web!
https://w3techs.com/technologies/history_overview/web_server
I wonder if HTTP exchanges / Web Bundles (from the Web Packaging proposal) would bring the approach of statically generating request-response pairs more to the mainstream.
If I understand correctly, then with both hosting and browser support for Web Packaging proposal, one could even statically pregenerate the whole signed exchange or bundle and skip the server-side TLS part as well.
The whole certificate renewal process will probably make that last part nonviable.
Not considering other potential effects on the web if the proposal gets adopted of course.
If I understand correctly, then with both hosting and browser support for Web Packaging proposal, one could even statically pregenerate the whole signed exchange or bundle and skip the server-side TLS part as well.
The whole certificate renewal process will probably make that last part nonviable.
Not considering other potential effects on the web if the proposal gets adopted of course.
Strange that a pretty common way to serve static sites is not mentioned: Multi-stage Docker builds [e.g. 1] an nginx-alpine image in Gitlab CI, that is automatically deployed to Kubernetes/a Docker host somewhere. Add the Let's Encrypt Container for automatic SSL.
[1]: https://github.com/lewish/asciiflow/blob/fd0f72714cd307cbb02...
[1]: https://github.com/lewish/asciiflow/blob/fd0f72714cd307cbb02...
I highly doubt this is a common approach!
Most mkdocs or hugo sites I see on GH or GL are served this way. Anyway, hard to proove - we need a new study!
I am currently using GitLab to do my static site hosting for free using their pages feature. And I get to use my own domain name and have SSL/https support automatically.
I've also come across https://staticdeploy.io/ which is self hosted and more akin to something like Vercel which manages a bit more than just serving/hosting.
Too bad it doesn't seem fully baked. I love the workflow of Vercel with the auto deployments from git and the infinite deploys via tags. Haven't found a good self-hosted alternative yet.
Too bad it doesn't seem fully baked. I love the workflow of Vercel with the auto deployments from git and the infinite deploys via tags. Haven't found a good self-hosted alternative yet.
With wrangler2 (https://github.com/cloudflare/wrangler2) you can deploy a static site to Cloudflare for free (you don't get any of the features of Cloudflare Pages though):
echo '# Hmm' > index.md
npx @11ty/eleventy
npx wrangler publish --assets _site/ --name name-of-static-website --latest
echo '# Hmm' > index.md
npx @11ty/eleventy
npx wrangler publish --assets _site/ --name name-of-static-website --latest
Quick but important note: for those who don't know already, Volution sells a square space-esque managed site builder with hosting, which means this post does have a minor conflict of interest (although these days I guess it's called content marketing). Haven't seen it mentioned yet in the comments.
[the author here] Where do I sell a "square space-esque managed site builder with hosting"? I need to get on some of that revenue! :) :) :)
Under the name of "volution" I own the following:
* volution.ro -- where this article was posted, which contains no products or hosting services, or even advertising to anything; (it does contain links to my GitHub projects, all of which are purely open-source; and links to my business site bellow and to another project I'm working on but which has nothing to do with hosting;)
* volutico.eu -- which is a "under construction" page for my consulting firm;
* github.com/volution -- where there are a few more polished open-source projects, including <https://github.com/volution/kawipiko> which is an open-source implementation of the ideas described in this article;
So, either there this is a case of mistaken identity, or please point me in the right direction.
(Searching on the internet for `volution` it does yield some companies which have a similar name, but those have nothing in common with me.) :)
Under the name of "volution" I own the following:
* volution.ro -- where this article was posted, which contains no products or hosting services, or even advertising to anything; (it does contain links to my GitHub projects, all of which are purely open-source; and links to my business site bellow and to another project I'm working on but which has nothing to do with hosting;)
* volutico.eu -- which is a "under construction" page for my consulting firm;
* github.com/volution -- where there are a few more polished open-source projects, including <https://github.com/volution/kawipiko> which is an open-source implementation of the ideas described in this article;
So, either there this is a case of mistaken identity, or please point me in the right direction.
(Searching on the internet for `volution` it does yield some companies which have a similar name, but those have nothing in common with me.) :)
Ah, my apologies! This is the one I thought you were associated with; one letter makes a big difference: https://www.volusion.com/
I figured it was one of those "founder-has-a-blog-with-very-similar-name-to-capture-new-users" situations. Nothing wrong with it, just something I feel it's important to be aware of. Sorry for the mixup!
I figured it was one of those "founder-has-a-blog-with-very-similar-name-to-capture-new-users" situations. Nothing wrong with it, just something I feel it's important to be aware of. Sorry for the mixup!
What's wrong with Netlify or Surge.sh?
fasthttp doesn't implement HTTP/1 correctly, and doesn't implement HTTP/2 at all. It's not an appropriate choice for a general purpose tool or library. The code is also not correctly formatted. Strong negative signals.
> fasthttp doesn't implement HTTP/1 correctly
Could you point to an issue describe such an improper behavior?
> doesn't implement HTTP/2 at all
Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: <https://github.com/valyala/fasthttp/issues/144>
And I'll quote here what I've said there:
> Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.
Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that actually supports these is the best approach.
Could you point to an issue describe such an improper behavior?
> doesn't implement HTTP/2 at all
Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: <https://github.com/valyala/fasthttp/issues/144>
And I'll quote here what I've said there:
> Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.
Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that actually supports these is the best approach.
There is another easy option: BunnyCDN. You can just drop the files on there via ftp.
Any simple thing can be made overly complex. If you're dealing with a truly simple static site, upload your client-side code to Netlify and call it a day. If you want more control, then it will come with more complexity.
The article is right in that setting up a server for any kind of hosting is not a simple task. There are no "good defaults" or "templates" easily embeddable/extendible for your specific use-case.
I use a static site generator, a vps and a git post-receive hook to build and deploy my site. Does not require any third-party providers (apart from the vps) and takes about 15 minutes to setup.
Are there any static hosts that provide HTTP logs?
I know it’s not perfect, but I want to have some sort of analytics without trackers.
I know it’s not perfect, but I want to have some sort of analytics without trackers.
You could just use GoatCounter <https://www.goatcounter.com/>; it's simple to deploy it yourself (it's open-source), but it's also free to use it hosted, and it seems to be quite privacy friendly (if one could call a web analytics solution as such).
If you are already using CloudFlare, they have a (free and) simple enough web analytics solution. (They say they are also privacy friendly, but given it's not open-source you can't check.)
As with static hosts that provide HTTP logs, perhaps they are, but certainly they won't be for free, as log shipping (from the edge where most hosted solutions cache things to the aggregator) and then storing those isn't quite that cheap...
If you are already using CloudFlare, they have a (free and) simple enough web analytics solution. (They say they are also privacy friendly, but given it's not open-source you can't check.)
As with static hosts that provide HTTP logs, perhaps they are, but certainly they won't be for free, as log shipping (from the edge where most hosted solutions cache things to the aggregator) and then storing those isn't quite that cheap...
I forgot to specify my goal when asking about HTTP logs: I want to get some basic analytics without adding anything to my HTML.
I love Goat Counter, but I still have to add a tracker (a privacy friendly one, but a tracker nonetheless).
Cloudflare looks like it might actually provide what I'm looking for, but the price is a bit too high for my low traffic hobby projects (looks like it starts at $20/month). I could just host my site on a VPS for cheaper than that (although I'd prefer some sort of managed/hosted offering under $10/month, if I can find one).
I love Goat Counter, but I still have to add a tracker (a privacy friendly one, but a tracker nonetheless).
Cloudflare looks like it might actually provide what I'm looking for, but the price is a bit too high for my low traffic hobby projects (looks like it starts at $20/month). I could just host my site on a VPS for cheaper than that (although I'd prefer some sort of managed/hosted offering under $10/month, if I can find one).
No, with Cloudflare you can use for free the "web analytics" product; you can even use it for any site, not only those hosted at CloudFlare. (Perhaps what you've seen is the "cache analytics" or "traffic analytics" which indeed are payed.)
(I use it "web analytics" on my own site thus I can confirm that it's free.)
(I use it "web analytics" on my own site thus I can confirm that it's free.)
Their site indicates that the free tier requires adding a JavaScript beacon (which is what I’m trying to avoid).
Is that what you’re using? Or did I misread their offering (which seemed to clearly indicate a paid plan was required for the non-JavaScript analytics)?
See at the bottom how it says “sign up for a paid plan” in the section that says “there is no code to add”:
https://www.cloudflare.com/web-analytics/
Edit: Oh, you're the OP! Just checked out your site and you are indeed using their JavaScript beacon. I know I'm being unreasonable, but in my case, I'm going for no JavaScript, and no trackers (so some sort of request logging on the server or proxy side is likely my only option). It's my attempt to "be the change you want to see in the world".
Is that what you’re using? Or did I misread their offering (which seemed to clearly indicate a paid plan was required for the non-JavaScript analytics)?
See at the bottom how it says “sign up for a paid plan” in the section that says “there is no code to add”:
https://www.cloudflare.com/web-analytics/
Edit: Oh, you're the OP! Just checked out your site and you are indeed using their JavaScript beacon. I know I'm being unreasonable, but in my case, I'm going for no JavaScript, and no trackers (so some sort of request logging on the server or proxy side is likely my only option). It's my attempt to "be the change you want to see in the world".
Yes, the Cloudflare web-analytics does require JavaScript.
With regard to no-JavaScript sites I understand; and for example the only JS on my site is the one for GoatCounter and Cloudflare web-analytics. GoatCounter does fallback nicely in case of no-JavaScript, meanwhile Cloudflare just doesn't work.
However, with regard to Cloudflare web-analytics, given that I already serve my site through them, there is no privacy lost by also using their analytics.
GoatCounter is good for assessing a long-term picture regarding readership, meanwhile CloudFlare is good for assessing performance issues.
Also note that if one registers a domain with Google for their webmaster tools (previously called Search Console?), although one doesn't use any of the Google services on the site, just because your visitors are using Chrome you can get performance metrics that way... So that's that about privacy... :)
With regard to no-JavaScript sites I understand; and for example the only JS on my site is the one for GoatCounter and Cloudflare web-analytics. GoatCounter does fallback nicely in case of no-JavaScript, meanwhile Cloudflare just doesn't work.
However, with regard to Cloudflare web-analytics, given that I already serve my site through them, there is no privacy lost by also using their analytics.
GoatCounter is good for assessing a long-term picture regarding readership, meanwhile CloudFlare is good for assessing performance issues.
Also note that if one registers a domain with Google for their webmaster tools (previously called Search Console?), although one doesn't use any of the Google services on the site, just because your visitors are using Chrome you can get performance metrics that way... So that's that about privacy... :)
Take a look at how I do analytics https://s.mkws.sh! Simple log parsing with awk!
apt install apache2
mkdir /var/www/your_domain
cp /home/a/website /var/www/your_domain
don’t forget to add cloudflare workers + r2. the best parts of lambda and s3, without the egress billing.
I've never even worked with lambda and s3, and CF workers and R2 took like 20 minutes for me to learn and set up.
I don't know how they made it so incredibly easy to learn and get going compared to AWS, but every time I try to figure out how to do AWS I get confused and get put off.
I don't know how they made it so incredibly easy to learn and get going compared to AWS, but every time I try to figure out how to do AWS I get confused and get put off.
aws has too many knobs, presumably to satisfy the union of the needs of all the enterprise customers. that said, lambda+s3+dynamodb+ec2 are pretty good once you tape over all the knobs that aren't needed. i work with them like this[1].
these days i build on aws and r2. aws for the nuts and bolts, r2 for high bandwidth egress. it's a perfect match.
1. https://github.com/nathants/libaws
these days i build on aws and r2. aws for the nuts and bolts, r2 for high bandwidth egress. it's a perfect match.
1. https://github.com/nathants/libaws
Not mentioning S3 here seems weird
>hosting these static sites, and we are still in the early 2000s
eh no?
This is a very good white paper.
I think the industry (or part of a generation of programmers) somehow collectively forgot that it exists. I don't see any mention of it in the article -- it solves the problem exactly. It easily serves and survives all the spikes from Hacker News that my site gets.
Shared hosting is a Linux box with a web server that someone ELSE manages. You get an SSH login, and you can use git and rsync.
It's associated with PHP hosting, but it is perfect for static sites.
http://www.oilshell.org/blog/2021/12/backlog-assess.html#app...
Answer to the HN question: What's the fastest way to get a page on the web?
https://news.ycombinator.com/item?id=29254006
FWIW I also have a Linux VPS with nginx and a HTTPS certificate, but it's a pain. I much prefer using shared hosting for things I want to be reliable.