Five posts have covered what 1.9 is about: a post in two languages, the site in the language of the page, what stands in a deploy target before the first deploy, a host that only speaks FTP and one phone shortcut instead of two. This one is the rest, in the order an operator meets it. Most of it came from two people who set 1.9 up from nothing and upgraded a copy of a 6,600-post site, doing only what the docs said.
Sending a post from an iPhone took two shortcuts until 1.9: one to take the files from the share sheet, one to open the SSH connection. Written on a train walked through both. It is one shortcut now, imported rather than built, and it runs on a Mac as well.
A shared hosting plan often comes with a directory, an FTP login and nothing else — no SSH, no rsync, no git. That has been enough for blog.sh all along; the docs just never said so until 1.9. The way there is the rclone backend, because rclone speaks FTP as one of its many remotes.
Somebody moves a blog off WordPress onto blog.sh and keeps the same hosting, the same directory, the same address. The build is ready, the first deploy goes through without an error — and the front page is still the old one. Nothing went wrong in the upload. The old site was simply never taken away, and the host prefers it.
Somebody translates their posts, opens the Czech half of the site — and the menu still says Writing, the footer still says Links, and every tag on every pill is the English word. The posts were only ever half of what a reader reads. The rest is what the site says about itself, and in 1.9 that has a language too.
Somebody writes in Czech, and some of the people who would read it don't read Czech. The usual answer is a second blog — a second archive, a second set of tags, a second feed — and within a year the two have drifted apart: a post fixed in one and not the other, a tag renamed on one side, a reader who switches languages and lands somewhere that no longer matches. blog.sh 1.9 gives a different answer: one site, and the other language beside it.
./blog.sh 1.9 is out — release on GitHub.
The release about publishing in more than one language. Name them in site.locales, and a post keeps one date, one set of tags and one series, with a text per language written by ./blog.sh translate. The site's own language keeps the root, every other one gets its own, and one rebuild makes all of them. The banner, menu, footer and tags speak each language too; a post nobody has translated still shows, linking to the one copy that exists. This very site has been running in English and Czech since the release was a draft.
Around it, the first hour: two people installed 1.9 from nothing and upgraded a copy of a 6,600-post site, doing only what the docs said, and everything they tripped over is fixed. Esc never does anything, the setup speaks your language from its first screen and will not take the template's example as your site's name, a draft's properties show where to read it — with a QR code for the phone — and doctor --online now asks the deploy target what stands in its root that the site does not put there.
A laptop dies, or a server gets rebuilt from nothing, and the question that actually matters is narrower than it sounds. Not "how do I back this up" — "which of these files does the engine actually need me to protect, because nothing else here can make them again on its own."
Most of an installation doesn't qualify. The engine itself is a git clone; pull it again and it's the same engine. Everything the build writes comes back with one rebuild, given what's left.
The instinct is to back up the site itself — the folder a browser actually sees. That's precisely the one thing this list leaves out. public.nosync, the build's own output, is exactly as disposable as the engine that made it: one rebuild reproduces it byte for byte, so keeping a copy of it would just be storing the same information twice, under two different names, and trusting the older copy by accident.
What's left, once the engine and the site it builds are both set aside, is a short list.
Twice an hour, on a large enough site, two cron jobs reach for the same folder at almost the same moment: the scheduled publish, building and deploying whatever post came due, and the sidebar refresh, rewriting a few of the same output files with fresh numbers. Most ticks miss each other by minutes. On an archive big enough that a build and a full deploy outlast the interval between them, some don't.
A deploy walking a tree that another run is still rewriting can serve a page half-written. A run pruning orphans can delete, as an orphan, a page the other run published a second earlier. Neither failure announces itself — the site just ends up quietly wrong.
One file, .blog-sh.lock in the project root, stands between those two runs — and it makes a choice that looks wrong until you see the alternative. A run that finds the lock already held does not wait for it.
There's no /admin on this site. No login form to try a password against, no session cookie to steal, no plugin list to check against last month's CVEs — not because a checklist said to strip them out, but because none of them were ever built in the first place.
The engine's own architecture notes put the rest of it plainly: the threat model is a static site with no server of its own. Nothing here listens on a port. The goal was never to harden a complex system against everything that could go wrong with it. The goal was to avoid needing one in the first place.
What's left to get wrong, once that's true, is narrower than a normal blog's list — what the pages carry, what the working directory holds, and the one thing that does arrive from outside.
Writing from a phone means one door does accept bytes from a stranger's own device: scripts/receive.sh, running as the forced command of an SSH key. It listens on nothing — no socket, no daemon, just a key that can run exactly this script and nothing else.