Finding a new web host for this blog

From inception, this site was hosted on GitHub Pages, but now I'm investigating other web hosts. I won't address my reasons for abandoning GitHub in this post; use your imagination.

Specifically, I'm looking for something fast, simple, cheap, and ideally open source. Spoiler: I went with Grebedoc, but had some issues integrating with SourceHut. pgs.sh is probably Pareto optimal for SourceHut.

New web hosts

After some brief research, I had this table:

Based on these observations, I was initially drawn to Grebedoc and pgs.sh (from pico.sh). I like SourceHut (it's so fast and simple!), but its static site hosting doesn't use a CDN and seems to require its own command line tool (probably a GraphQL wrapper). I've used (and liked) NearlyFreeSpeech.net before, but again no CDN. Codeberg Pages sounds like it's having some growing pains (hence Grebedoc's existence).

I decided to drill into the first two options.

Grebedoc

Grebedoc ("codeberg" backwards) is explicitly designed as an off-ramp from GitHub Pages, and I believe it (or at least its code) is intended to replace Codeberg's original "pages" infrastructure. I like that it can serve pages from 6 different regions. I also like the concept of it being run as a public utility. Somewhere, I read that the whole thing costs less than $50/month to run, so it will hopefully be viable for a long time.

If you're git-pushing your site to a web hook-enabled code forge (like Codeberg), it sounds easy to setup. I wasn't sure how easy it would be to use from SourceHut. I'm also not entirely sure I'm sold on using Git for the output of my web site's build process. I version-control my site's source, but I don't really need versioning on the output. Git is good for generating diffs, though.

If I was planning to host my site's source on Codeberg, I'd definitely choose Grebedoc. But... I actually store my site's source on SourceHut, so nontrivial setup is required.

pgs.sh

I love pico.sh's SSH-based tools. It's so simple! Just ssh in, and your "account" is created automatically. No messing around with passwords! Account recovery is difficult, but that's a future problem.

pgs.sh is incredibly easy to setup. All you do is rsync your site over and optionally setup a custom domain. And $2/month is cheap--less than a cheap VPS!

Only downside I see is that its CDN has just 2 regions: US and EU. And that's only a downside because I'm eyeing Grebedoc and its 6 regions.

The Decision

In the battle between free+six-region vs. cheap-but-easier, I'm decided to try the fancier-deployment-but-more-complicated-setup option: Grebedoc.

Setting up Grebedoc for SourceHut (custom domain)

With e.g. {user} replaced with appropriate values.

1. Create an empty "pages" branch (in a subdirectory): git init -b pages
2. Add and commit site contents
3. Set up and push to SourceHut remote: git remote add origin git@git.sr.ht:~{user}/{repo} and git push -u origin pages
4. DNS: Add TXT record with Git clone URL (https://git.sr.ht/~{user}/{repo}) to _git-pages-repository.{domain} subdomain (e.g. _git-pages-repository.til.schemescape.com)
5. DNS: Add ALIAS (or CNAME) record for the host subdomain, pointing to grebedoc.dev
6. Tell Grebedoc to create the site and certificate (first time only): curl https://grebedoc.dev/ -X PUT -H "Host: {domain}" --data "https://git.sr.ht/~{user}/{repo}"

Next, you create a GIT_POST_RECEIVE web hook on SourceHut to trigger updates to the web site... or at least that was what I had hoped to do. Unfortunately, while SourceHut does have some support for web hooks, it is entirely GraphQL-based, and I couldn't find a way to specify a fully custom payload (request body). Without the URL as the request body, Grebedoc returns HTTP 400 (bad request). This, unfortunately, means I found no way to trigger automatic Grebedoc updates from SourceHut.

Instead, I just updated my "commit my changes" script to fire off the relevant web request using curl:

curl https://{domain}/ -X PUT --data "https://git.sr.ht/~{user}/{repo}"

This causes Grebedoc to pull the updated repository and deploy any relevant changes.

Conclusions

Well, that was a bit disappointing. Without custom web hook support, I couldn't get automatic deployments working from SourceHut. I might be able to get this working via SourceHut's CI ("builds") infrastructure, but I had been hoping for a trivial solution. I wasn't able to evaluate the performance boost from the six-region CDN, but I'm personally seeing page load times in the 400 - 700 ms range.

In the end, my setup has a manual step anyway, so maybe I should have just saved some time and rsync'd to pgs.sh.