Hi! Welcome to the blog.
I wanted the first post to be something practical rather than purely introductory, so let me tell you about where this site lives and why I ended up there. Short answer: sourcehut, and it has been refreshingly, almost suspiciously easy.
The pitch
sourcehut Pages lets you deploy a static site from a build manifest. That’s it. You write a .build.yml file that describes how to build your site, push to your repository, and the build runner handles the rest: compiling, generating, uploading. For a Hugo blog the whole manifest is maybe fifteen lines. There’s no dashboard to learn, no plugin marketplace to navigate, no “pricing tier” hiding the features you actually want.
The URL for your site is <username>.srht.site by default, and pointing a custom domain at it requires adding a single file called .domains to your static/ directory containing your domain name, then setting a CNAME record. That’s the entire configuration surface. I spent more time choosing a font than I did setting up hosting.
Why not the obvious alternatives?
GitHub Pages is fine. Netlify is fine. Vercel is fine. But each of them is really selling a product: a dashboard, deploy previews, an analytics tab, forms integration, a CDN edge network you’re supposed to care about. The hosting is the hook.
sourcehut’s model is different. Drew DeVault built it as a suite of tools for software development: git hosting, mailing lists, CI, bug tracking, a wiki. Pages is just one piece. You pay a subscription; the service doesn’t need to surveil you or upsell you to make money. Build VMs get destroyed after each run. No cookies, no JavaScript on the service pages, no tracking pixels. Aggressively uninteresting, in the best way.
The build pipeline
The CI system, builds.sr.ht, is general-purpose. Your build manifest declares an image, packages to install, and tasks as shell scripts. Here’s the one for this blog:
image: alpine/latest
packages:
- hugo
- hut
oauth: pages.sr.ht/PAGES:RW
environment:
site: blog
domain: bmhoch.com
tasks:
- package: |
cd $site
hugo
tar -C public -cvz . > ../site.tar.gz
- upload: |
hut pages publish -d $domain site.tar.gz
The hut tool is sourcehut’s CLI; it goes in packages like anything else. The oauth field gives the build runner a scoped token to write to Pages. hut pages publish takes a tarball, uploads it, and atomically swaps it in. Deploys are fast: the Hugo build takes under a second on a bare Alpine image, and the upload scales with what’s changed.
Builds trigger on every push. If a build fails, you get an email; if it succeeds, the new version of the site is live within a minute or two. That’s the entire loop.
A note on simplicity
I think a lot about what it means for a tool to be done: a well-defined scope, filled completely, with no ambition to expand. sourcehut feels like that. It’s not trying to be your deployment platform or your observability stack. It wants to host your repository, run your builds, and get out of the way.
This blog is supposed to be about writing, not infrastructure. That’s why it lives here.
If you’re looking for somewhere to put a static site and you already care about software freedom, or you just want to pay for a service rather than be the product, give sourcehut a look. The Pages documentation is short because there isn’t much to explain.