Static Website Hosting in 2024

I recently changed the hosting for this site to GitLab Pages at gitlab.com and want to capture my evaluations here. I considered Uberspace, Cloudflare Pages, and GitHub Pages, before landing on GitLab Pages. Here’s the quick summary. Read on for the details and rants.

Uberspace

Uberspace was hosting this page for the last 8 years. Still love the UX of Uberspace. You get shell access for a user in a CentOS/RHEL environment and the uberspace command to manage domains, mails, web backends etc. Uberspace leaves a lot of freedom in your technical implementation, but removes the hassle of updating your base OS or fiddling with all the details of an Apache config. It is so much more than just hosting for a static website.

Why did I move away from Uberspace then? First and foremost, because nowadays zero dollar alternatives exist for static website hosting, which is all I need here.

And secondly, because of security concerns I have with the shared hosting. On Uberspace you share a VM with other users. If someone finds a local privilege escalation (like last year) they could compromise what you have hosted on Uberspace. Since the VM is still on CentOS 7, which is end-of-life since a couple of months, incidents like that might become more likely. Of course, Uberspace is aware of that and use TuxCare, who promise “Endless Security Patching Far Beyond the EOL Date” for “High and Critical CVEs”. Nevertheless, I think stricter user isolation should be implemented through SELinux, containers, or similar technology. Maybe Uberspace “asteroids” are already isolated well (SELinux is indeed active), but I’d like to see some more documentation and external pentests.

Cloudflare pages

According to their docs only supported frameworks can be used. Hakyll is not one of them, hence I quickly disregarded it and moved on to GitHub pages.

I later found out that Cloudflare also supports a static html option, which is very similar to what I ended up with on GitHub. However, registering an apex domain for Cloudflare Pages requires the use their nameservers, which is something I did not want to do.

GitHub pages

I like the discoverability on GitHub. That’s why it is the default for my public repos.

After configuring a first domain for GitHub Pages, the GitHub settings page (not the hosted website itself) became very slow and sometimes responded with the angry unicorn. A couple of angry unicorns later, I realized that only one domain (or a www and an apex domain) is supported, but I wanted to keep my blog subdomain in addition. So I moved on to the next contender.

GitLab pages

GitLab had no issues configuring all my domains. It also has the superior CI system. I’m not the biggest fan of GitHub actions. If you need 40k lines (granted, the biggest junk is vendored JS) for a git pull action you are doing something wrong! Just give me the git CLI already!

Anyways, on GitHub the easiest way to deploy the site was to build locally commit the Hakyll build output to the docs directory. I moved that setup over to GitLab. On GitLab I could improve the setup and not commit the build output, but instead build Hakyll’s site binary in CI, put it in a container or CI artifact, and then build the site in CI.

There is one drawback with GitLab pages though. I rely on GitLab to not change their IPv4 and IPv6 IPs used for Pages. This is probably one reason why Cloudflare wants you to use their nameservers for apex domains.