🛰️ xmit.co Might Be My New Favorite Static Site Host #

I have a new favorite static host: 🛰️ xmit.co. Over the years I've used Netlify, Vercel, Render, GitHub Pages, Cloudflare Pages, and a few homemade VPS (on Digital Ocean & Vultr) setups held together with Nginx, rsync, GitHub Actions, and hope. They all have their place. But 🛰️ xmit.co has been quietly winning me over, mostly because it does the thing I actually want: publish static files, fast, without asking me to reorganize my whole workflow around it.

🛰️ xmit's own pitch is direct — fast, free static hosting, updates in seconds, a system that doesn't resend files it already has, and login through WebAuthn passkeys instead of one more password. It isn't trying to be an app platform or a serverless everything-cloud. It's trying to put static sites online quickly and get out of the way. That's exactly what I want from a host. If thats not easy enough for you there is a GUI OncleBob.com also by 🛰️ xmit.co.

Boring infrastructure, on purpose #

You build your site, point Xmit at the output folder, and ship it. The CLI is plain: set a key, run something like xmit example.com dist/, done. For anyone running Build Awesome Eleventy, Astro, Hugo, Vite, Jekyll, Zola, or SvelteKit's static output, that's the whole dream — build locally or in CI, deploy the final files, move on with your day.

Pierre Carrier, who builds Xmit, wrote once about the joy of using your own software to solve your own problems, then called Xmit "a rather boring piece of infrastructure." That's the good kind of boring — the kind where the site is live and you don't have to think about it again until you want to publish something new. Not exactly a rousing sales pitch but accurate and appealing (at least to me).

🛰️ xmit.co workflow #

My actual workflow: let GitHub Actions build the site, then let 🛰️ xmit.co host the result.

1. Push source to GitHub.
2. GitHub Actions installs dependencies.
3. GitHub Actions runs the static site generator's build.
4. Upload the output folder — _site for Eleventy, dist for most Vite-based tools — to Xmit.

That split works well. GitHub owns the build, Xmit owns the hosting, my repo stays the source of truth. Xmit's own end-to-end guide walks through basically the same pattern: create an XMIT_KEY secret, run the deploy command from Actions, publish on push to main.

Compared to what I was using before #

Netlify is still great, and it more or less defined what static hosting should feel like for a lot of us. Redirects, deploy previews, serverless functions, and Netlify Forms — which can parse a plain HTML form at deploy time with no JavaScript — are all genuinely convenient, and Netlify supports redirects through either a _redirects file or netlify.toml.

Vercel is excellent if your project is a real frontend application, especially anything Next.js. It's built around Git-connected deployments, preview URLs, and scaling actual app workloads. It'll host a static site fine, but that's not really its center of gravity.

Render is solid too, particularly if you want static sites sitting next to backend services, databases, and workers. It connects to a Git repo, deploys automatically on push, and gives you dashboard redirects and automatic HTTPS.

None of those are bad tools — I've shipped real projects on all three. Xmit just feels smaller in the right way. It doesn't ask to become the center of your stack. It asks "do you have static files, and do you want them online quickly," and that's it.

Redirects that don't make me want to quit #

I've migrated enough blogs, renamed enough categories, and moved enough domains to know redirects are the thing that seems minor right up until you need them. Xmit handles them through xmit.toml. Pierre wrote about moving his own site with over a gigabyte of files and, in his words, "a zoo of domain redirects." The config is plain: [[redirects]], a from, a to, permanent = true. That's genuinely all it takes.

One thing that tripped me up: if you're deploying through GitHub Actions like I recommend above, don't forget to copy xmit.toml into your output directory before it uploads, or the redirects just silently won't do anything.

I have always found netlify's way of doing redirects super simple, Cloudflare's frustrating and xmit's is the closest I have found to netlify's _redirects. It works great.

Forms work, spam is still spam #

Xmit has form-to-email support, though as of the docs I read it's still a little thin on documentation. It's a small feature, but it makes a static site much more useful for the kind of work I do — course sites, project pages, small nonprofits, contact forms for scholars who don't want to run a whole CMS just to receive email.

The catch is the same catch every static form service has: if a form can email you, bots will eventually find it. Netlify Forms, Formspree, hand-rolled serverless forms — none of them are immune. Add a honeypot, don't publish a high-value inbox if you can avoid it, and check your spam folder regardless of how much SPF and DKIM you set up, because Gmail will bury the notification emails anyway.

If anyone knows of a good recaptcha alt for our present moment that is free/low/no-cost. I'm listening...

Why I'm sticking with it #

I do a lot of static site work for teaching, religious studies scholarship, and small nonprofit projects, and most of those sites need to be fast, cheap, and easy to leave alone for months at a time. Xmit fits that better than anything else I've tried lately — it's simple, it plays well with GitHub Actions, redirects don't require a config seminar, and forms are useful enough even with the spam caveat.

Netlify, Vercel, and Render are all still good tools, and I'll probably keep projects running on all three. But for a plain static site, Xmit is what I reach for first now.