Static site hosting hurdles
notes.volution.ro
notes.volution.ro
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.
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.
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
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.
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
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.
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.
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.
And if you somehow find a loophole you'll quickly become persona non grata.
As the saying goes, TANSTAAFL.
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
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.
.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.)
I have great respect for the folks keeping this stable and working for decades for such a low price!
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.
It serves static sites. I upload my files with rsync, scp, or git, and they are served
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.
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.
Just wish they used newer hardware than they do on their VPS & Dedicated offering.
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.
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.
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.
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)
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.
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
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.
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.
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.
[1]: https://notpushk.in/
Nope. Anything I can have a machine generate for me is fancy if I have to write it by hand.
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 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.
¯\_(ツ)_/¯
I’ve been a customer since 2004
But I guess my overall point is that CPanel is way easier than anything the original poster / author wrote.
Disclaimer: I work there ;)
You just connect your git repo and tell it what command to run to build your site and where the html output is
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!
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
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.
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.
Shared hosting is basically where somebody configures and runs Apache or Nginx for you ... they know how to do this, and it definitely works!
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.
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 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.
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...
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...)
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.
He probably didn't.
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.
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.
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.
[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.
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.
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.
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
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 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.
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).
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.
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. :)
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.)
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
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.
- 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.
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.
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.
> 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
```
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`
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
* `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.
Well done.
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.
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.
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.
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.
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.
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.
(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.
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.
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. :)
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).
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.
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.
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.
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 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.
[1]: https://github.com/lewish/asciiflow/blob/fd0f72714cd307cbb02...
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.
echo '# Hmm' > index.md
npx @11ty/eleventy
npx wrangler publish --assets _site/ --name name-of-static-website --latest
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.) :)
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!
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.
I know it’s not perfect, but I want to have some sort of analytics without trackers.
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 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 use it "web analytics" on my own site thus I can confirm that it's free.)
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".
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... :)
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.
these days i build on aws and r2. aws for the nuts and bolts, r2 for high bandwidth egress. it's a perfect match.