![\"domains\"](\"/img/domains.webp\")
Host static sites. Sounds trivial, right?
\nHere are details worth considering, whether you host on your own servers or rely on a platform like the one we're\nbuilding.
\nSecuring all traffic is a no-brainer.
\nAll HTTP traffic is redirected to HTTPS, and we\ninclude HSTS headers everywhere.
\nWe go a bit further,\nwith referrer-policy: no-referrer, x-content-type-options: nosniff, x-frame-options: SAMEORIGIN out of the box.
We've been there: the latest launch is broken, a rollback is in order.
\nWe've made it as fast and simple as possible, and as with any launch, it's effective across our infrastructure in\nmilliseconds.
\nAnd to make sure wires don't get crossed, the entire admin console is fully reactive.
\nxmit is smart enough to only upload files that have changed. It's open source (0BSD license), so you can inspect the\ndetails. In short, it generates a manifest of all file hashes, uploads it only if it's new (checked by hash),\nthen uploads only files whose hashes are new.
With atomic launches, it's all or nothing, and within the milliseconds of propagation delays of our coordination\nsystem (etcd). A client won't see HTML referring to a new JS/CSS/asset until it's been made\navailable on its connection, avoiding a common source of 404s.
\nTo fully avoid 404s, previous launches also need to be excluded slowly: servers need to fall through, so a client which\nloaded HTML just before a launch, which referred to JS/CSS/assets not included in said launch, still gets enough chances\nto load them (today, over 5 launches and 10 minutes, such that removing a resource propagates consistently within an\nshort window).
\nEvery upload can be accessed through a dedicated xmit subdomain, letting you vet it before launch if you didn't enable\nlaunch on upload. Those subdomains are only accessible to your team. They stick around, so it's easy to check what was\nonline at any point in recent history.
\nHTTP/2 was a leap forward. QUIC is\nanother.
\nWe support both, announced through DNS HTTPS records and Alt-Svc headers.
\naccept-ranges: bytesResume downloads, play videos in Safari, and more. We support range requests and advertise it to clients.
gzip whenever worthwhileRather than hardcode a list of extensions or MIME types worthy of compression,\nwe give it a go on everything, and use the compressed version when requested and smaller.
\nETag & if-none-matchna\nOur servers only rely on content-addressible caching. Browsers cache URLs.
\nWe do not introduce any propagation delays in CDNs, proxies, or browser caches other than through headers you control.
\nBut if the browser saw a resource already, no reason to transfer it again. That's\nwhere ETag comes in.\nWe always report one, and return 304 Not Modified if it appears in the if-none-match header received from clients.
www subdomainUnless you launch a site there, we redirect www to its parent domain for you.
Name your page hello.html and access it at /hello. Simple and practical.
xmit.toml, which isn't served, offers simple settings. For example:
fallback = "index.html" # for Single Page Apps\n404 = "404.html" # for custom 404 pages (none in SPAs)\n\n[[headers]] # add a CORS header\nname = "access-control-allow-origin"\nvalue = "*"\n\n[[headers]] # unset "referrer-policy"\nname = "referrer-policy"\n\n[[headers]] # cache assets for a year\nname = "cache-control"\nvalue = "public, max-age=31536000"\non = "^/assets/"\n\n[[redirects]]\nfrom = "^/new/(.*)"\nto = "/$1"\npermanent = true # 301 instead of 307\nA quick update to let you know we've enabled Brotli\ncompression, as requested by @McNeely on the fediverse.
\nThis should yield better performance with modern browsers, as Brotli achieves higher ratios than gzip.
\nWe moved compression from request time with caching, to upload time with full persistence. This should improve tail\nlatencies a fair bit, notably with larger media like photos, audio, and video, at the cost of slower uploads.
\n" }, { "id": "https://xmit.dev/posts/pcarrier-com/", "url": "https://xmit.dev/posts/pcarrier-com/", "title": "Migrating pcarrier.com: over a GB, and a zoo of domain redirects", "date_published": "2024-05-04T00:00:00.000Z", "content_html": "There really is joy in using one's own software to solve one's own problems. I can't help but share my experience migrating\nmy personal website to xmit.co, from a small VPS running nginx. I won't argue the benefits, having already\ndone so in our first post (though I failed to point out what might be the most obvious to me, high availability\nthrough redundancy).
\nI have domain acquisition syndrome. For my name alone, over the years I've collected gcarrier.fr, pcarrier.ca,\npcarrier.fr, pcarrier.com, rrier.ca, rrier.fr.\nThe last two are merely a domain hack so I could be emailed at pc@rrier.ca & pc@rrier.fr.
pcarrier.com is the only web property left standing; everything else redirects to it,\nwith a quick hack so I could be found through @pc@rrier.ca & @pc@rrier.fr on the fediverse.
I already had an organization #19: perso, so I went straight to DNS, where I created the following records for all domains:
@ CNAME 19.xmit.co.\n* CNAME 19.xmit.co.\n@ TXT "xmit=19"\nThen I launched my >1GB web directory with xmit pcarrier.com. That crashed halfway through the upload.\nImplemented chunked uploads in the xmit CLI, released it, and finally relaunched with caching rules in xmit.toml:
[[headers]]\nname = "Cache-Control"\nvalue = "public, max-age=31536000"\non = "/fonts/.*"\nFor all the other domains, I launched a separate site with xmit rrier.ca from a directory with a lone xmit.toml:
[[headers]]\non = "^/.well-known/webfinger$"\nname = "access-control-allow-origin"\nvalue = "*"\n\n[[redirects]]\nfrom = "^/.well-known/webfinger$"\nto = "https://mastodon.social/.well-known/webfinger?resource=acct%3Apcarrier%40mastodon.social"\n\n[[redirects]]\nfrom = "^/(.*)"\nto = "https://pcarrier.com/$1"\npermanent = true\nAfter that, I headed to the xmit admin, clicked on the newly created site,\nrenamed it to pcarrier.com redirs, and added all the other domains on it:
That's all. I thought this worth sharing, though looking back this migration didn't amount to much.\nHappy to be building a rather boring piece of infrastructure.
\n" }, { "id": "https://xmit.dev/posts/small-things/", "url": "https://xmit.dev/posts/small-things/", "title": "Shipping small things (0pw.me, 1pw.me, found.as)", "date_published": "2024-05-17T00:00:00.000Z", "content_html": "As the design for signali.ng awaits reviews, I found myself with a fair bit of time and\ninfrastructure readily available. This gave me the unique opportunity of putting small non-commercial services together\nquickly.
\nThe idea is simple: no sign up, no account, anybody can maintain a 64KiB chunk of data by associating it to a public\nkey.
\nAs the updates must be signed using the corresponding private key,\nsomething verified by both the infrastructure and serious clients, only people with the private key can update it,\nand only people with the private key and maintainers of the service can delete it.
\nTo make it easy and lightweight on web clients without trusting NIST curves, we adopted\nTweetNaCl.js's cryptography.
\nTo support arbitrary chunks of data without going through base64 or the like, the protocol is based\non CBOR rather than JSON or HTTP paths.
\nTo avoid ever logging public keys, reads pass the key being looked up in a POST body.\nDon't disclose the public key and only maintainers of the service know where to get your data.
\nEncrypt your data and nobody can. Which leads me to the first app using this service,
\nAgain, the idea is simple: no sign up, no account, anybody can associate up to 64KB of text by associating it to a\npassword.
\nOf course, it leverages 0pw.me to store the encrypted data. 0pw.me was built for it,\nreally. And it was built, as the name might suggest, to store my 1password secret key so I can\nrecover it on the go, even if I lose all my devices.
\nThe password is used to derive the private key used for 0pw.me's signature, the one needed to deecrypt\nthe data.\nThis derivation uses 100,000 rounds of SHA-256 PBKDF2 with a static salt.
\nThere really isn't much more to it, adding up\nto only 219 lines of Preact within 30KiB compressed of an\nopen source website whose build is reproducible thanks to the Vite ecosystem.
\nFeeling inspired by the simplicity of 0pw.me, quick editing experience of 1pw.me,\nspeedy service of xmit.co, I put together a service to associate a redirection, webpage, or (later)\narbitrary file under 1MB to a URL: found.as.
\nPick a path, pick a password, see what's there if anything, choose what should be there, whether it be a redirect,\nhand-written HTML, markdown, or an arbitrary file, hit a button, observe the result in a new tab, then share at will,\nknowing you can come back and edit it later.
\nIt reuses the key derivation from 1pw.me, but this time the salt depends on the path being edited,\nguaranteeing that the same strong password can be used for multiple paths without correlation in our store.\nUnlike 1pw.me, the data is never encrypted as the purpose is to publish.
\nSupport for markdown with YAML metadata is implemented entirely in browser allowing for live previews, which combined\nwith cbor-x, TweetNaCl.js,\nand Preact, puts the admin UI just under 60 KB compressed; of course, the generated resources\nare served without any overhead.
\nWhen I wrote about migrating pcarrier.com to xmit.co, I missed an opportunity to touch on this\ntopic. There's nothing like building for your own needs, and there's nothing like using what you build.
\nPublishing found.as' landing page through its admin UI was a mind-altering\nmoment. I figured I should support uploading files too, so I could ship favicon.ico,\nthe site-wide default icon, without a backend rule for it.
\nOne day, I might need my 1password secret key urgently, without access to any of my devices.\nI look forward to it.
\nAnd of course, all those services use xmit.co. They get the exclusive privilege of exposing APIs\nthrough it, something I hope to allow through proxying and a serverless runtime at one point or another. I'll be sure\nto (re-)build with those.
\n" }, { "id": "https://xmit.dev/posts/free-subdomains/", "url": "https://xmit.dev/posts/free-subdomains/", "title": "Free subdomains for completely free websites", "date_published": "2024-05-18T00:00:00.000Z", "content_html": "We're now offering free subdomains for completely free websites. In the spirit of the IndieWeb,\nI'd recommend owning your own domain, but the tradeoff is that resources will only persist as long as you renew it.\nNothing lasts forever, but as long as we're here and not required to remove your content, using a free subdomain\nguarantees that it remains available.
\nSo jump into our docs, where you'll be directed to skip DNS setup, and deploy a subdomain\nof xmit.dev if you like our brand, madethis.site for a personal site. If\nyou're using a personal API key (rather than a team's), it'll require an extra argument on first deploy to specify which\nteam the site should belong to. Otherwise, everything works exactly the same.
\nAnd because it's easy to add and remove domains to sites from the admin interface, even if you do have your own domain,\nyou might as well evaluate xmit.co without any DNS changes.
\nPlease reach out if you'd like to provide different domains to our community.
\n" }, { "id": "https://xmit.dev/posts/slower-launches/", "url": "https://xmit.dev/posts/slower-launches/", "title": "Slower uploads", "date_published": "2024-05-23T00:00:00.000Z", "content_html": "A quick update to let you know we now acquire certificates synchronously during uploads.
\nThis lets us report any issues with the certificate acquisition process in real time.\nIt also means that when we tell you an upload is ready, it's truly ready.
\nUnfortunately, this adds up to 30 seconds to the xmit execution time.
As part of this change, we show the preview URL as part of every upload, even those launched right away.
\n" }, { "id": "https://xmit.dev/posts/form2mail/", "url": "https://xmit.dev/posts/form2mail/", "title": "Form to mail, sneak peek at new projects", "date_published": "2024-10-15T00:00:00.000Z", "content_html": "We have yet to properly document the feature, but you can now create forms that send emails to the address of your choosing. Some details on Pierre's blog.
\nStarted prototyping a mailing list turning blog. Still very early days, and might not get anywhere. Again some details on Pierre's blog.
\nAlso thinking of building a web-based (Monaco-powered), offline-first editor, so anyone can write HTML and CSS and start a site without any installs. Either directly from the admin UI, or possibly on another domain altogether. This requires the API surface for xmit download, which gives it a new sense of urgency.
libk.org is a dynamic DNS service that provides a very simple interface.
\nNot much else to say about it that isn't already there:\nit's the typical minimal service we are glad to offer.
\n" }, { "id": "https://xmit.dev/posts/bob/", "url": "https://xmit.dev/posts/bob/", "title": "Oncle Bob, a desktop app for webweaving", "date_published": "2025-11-21T00:00:00.000Z", "content_html": "onclebob.com just launched.
\nKeeping this brief, but it feels like a milestone: Oncle Bob meaningfully moves the needle in the direction xmit was always meant to head — an effort to simplify putting sites on the web.
\nThe xmit CLI isn't going anywhere. Professional organizations should still rely on CI/CD pipelines for deployment. The CLI is a wonderful tool for people comfortable taming it.
But for everyone else, Oncle Bob opens the door to a dramatically better experience around static sites. Now I can write guides for starting a blog on a fully self-managed stack without worrying that mandatory command-line usage will scare readers away.
\nI don't know that I'll write such guides myself anytime soon. In the meantime, I loved reading Adam's guide, which reminded me that DNS is another pain point worth addressing.
\n" }, { "id": "https://xmit.dev/posts/analytics/", "url": "https://xmit.dev/posts/analytics/", "title": "Launching analytics on xmit.co", "date_published": "2025-11-28T00:00:00.000Z", "content_html": "xmit.co now sports server-side analytics. We do not use cookies, record the IP address or geolocation in any way. We do not track sessions.
\nEntirely backed by strictly filtered access logs injected in a ClickHouse cluster and queriable from a new tab on the site.
\nFor each HTTP request, we record:
\n/, /style.css, etc.)Head to xmit.co/analytics.
\n" } ] }