lithair-website is tagged v0.1.0 today. The tag points at the commit that published “A Page Load Is a SELECT Somewhere” — the article that ends with “the site you’re reading runs on lithair.” Tagging there was deliberate. The version anchors the live production state of a site that has been running for months without a version number.
The standard pattern
Most projects tag early and often. v0.0.1 lands the first prototype. v0.1.0 lands a public-facing milestone. SemVer is well-understood. Tagging is part of the discipline that says “this commit is the one I trust.”
This is good practice. It keeps the relationship between source and deployed binary auditable. It gives external users (or your future self) a stable target to pin against.
I haven’t been doing it.
The realization
For the months lithair-website has existed, it has been running on main. The deployed binary was always the latest commit. There was no “released version” because there was no external user other than me, and “what’s in main” was a perfectly adequate answer when I needed to pin something.
That answer worked until a month ago, when this site started hosting a blog with public posts. Once readers exist, the question changes from “what’s the latest” to “what’s the version that produced the page in front of me.” Without a tag, that’s a moving target — meaning what readers see today might not be what the source says next week.
Tagging v0.1.0 fixes that. The production baseline gets a name.
What’s in v0.1.0
Everything that makes lithair-website a production site rather than a demo:
- Multi-site virtual hosting — Host-header dispatch via lithair-core’s
HostRouter<T>. One binary serveslithair.netandarcker.orgon the same port. No reverse proxy in front. - TLS via rustls — Let’s Encrypt multi-SAN cert covering
lithair.net,www.lithair.net,arcker.org,www.arcker.org. HTTP-01 standalone validation. Auto-renewal hooks tied to systemd. - www → canonical 301 redirect — Path-preserving, all HTTP methods, via lithair-core’s
with_redirectprimitive. - Admin dashboard — request logs, security metrics, real-time monitoring, CPU/RAM/latency percentiles. Mounted at a randomized path per startup.
- CrowdSec LAPI integration — local bans, CTI reputation, Cloudflare passthrough, JWT machine auth.
- arcker.org blog — Astro-built static site, dark monospace theme, RSS feed. Nine posts live, including a four-post project-vision series.
No nginx. No Caddy. No reverse proxy. The framework is the web server.
Why this matters to me
The site is the demo, and the demo is the integration test. Multi-site hosting shipped to lithair-core and was wired into production on lithair-website within hours. The admin dashboard exercises the same request-pipeline hooks that framework users get. The TLS stack is rustls all the way down. When I broke the admin UI by accident on the same evening I shipped multi-site, I caught it within four hours because the production site was the test bench.
That tight feedback loop is the reason I tagged the framework’s primitives in the same week I tagged the showcase site. lithair-website v0.1.0 is paired with lithair v0.1.4. Same release cycle, same evidence.
What this is not
It’s not “you should host your blog on the framework you’re building.” For most builders, that’s an unreasonable burden — your blog isn’t supposed to be a production stress test for your framework.
It’s not “the site is feature-complete.” There’s still tech debt — orphaned modules from a previous lithair-core API generation are blocking cargo check/cargo test on main. Cleanup before contributor onboarding.
It’s not “v0.1.0 is the recommended way to deploy lithair-website.” It’s the production baseline of one specific deployment. The repo is open, the code is reusable, but the operational story (data dirs, certs, environment variables, systemd) is documented for my use, not generalized.
It’s: when a site has been running in production long enough to host real readers, it deserves a version number. v0.1.0 is the version that says “this is the site they’re reading.”