Home / Articles / No server, by design / Versions / v1.1.0
No server, by design: what changed in v1.1.0
From v1.0.0 (2026-10-11, 1f924000f) to v1.1.0 (2026-10-11, this release), paragraph by paragraph.
0 paragraphs added, 0 removed, 13 changed in place, 64 unchanged. About 17 words added and 28 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
# No server, by design: first I got rid ofretired the database, now I am getting rid ofretiring the back end
Summary: For years my rule has been not to use a database: the file system is the database, and the Load, Extract, Transform, Save pipeline (LETS) loads state, caches it and writes it back as files you can version, diff and read. The second step has been creeping up on me, and the newsroom made it explicit: get rid ofretire the back end too. The SGit Newsroom is now a content site for several audiences, with personas, a reading meter, a payment on-ramp, a newsroom of your own, encrypted sharing and databases that run in the reader's browser, and none of its application logic runs on a server. What is left on the server side is commodity: static hosting, a vault server that stores only ciphertext, a payment link, DNS and a build pipeline, with a sign-in provider next. The design came from a constraint: the vault server cannot see anything, by design, so everything that needs to see has to happen in the browser. It also came from a security call: the gaps a server would close do not match this site's readers, and the article lists them, with what a server would cost to close each one. The result scales without its complexity scaling, ships fast (114 releases between 1 and 11 October), and lines up with the things I care about: sovereignty, privacy, explainability and determinism. The article maps the architecture, the evolution, the accepted gaps, and how far I think the pattern can be pushed.
3 unchanged paragraphs
And I think this is the next major pattern of my architecture. First I gotretired ridthe of databases.database. Now I am getting rid ofretiring the back end. I am literally lookinglook at everything through this lens:lens now: why do I need that? Why do I need the Lambda function? Why do I need the EC2 instance? Why do I need the cost? This article is that pattern: where it came from, what the newsroom looks like when you draw it, why the security gaps it leaves are the right ones to leave, and how far I think it can be pushed.
1 unchanged paragraph, under In short
• Step one was getting rid ofretiring the database. The file system is the database. The LETS pipeline (Load, Extract, Transform, Save) loads state, works on it, and saves every intermediate result as a file you can version, diff and read. Memory-FS and Issues-FS are libraries built on that idea.
• Step two is getting rid ofretiring the back end. The application moves to the browser. The SGit Newsroom has personas, a reading meter, a payment on-ramp, a newsroom of your own, encrypted sharing, article versions, and SQL and SPARQL databases, and none of it runs on a server.
9 unchanged paragraphs, under Step one: the file system is the database {#files}
The point is not that files are clever. It is that a database server is a large, stateful, always-on thing that you have to provision, secure, back up, migrate and pay for, whether or not anyone is using it, and most of the time what it holds would be perfectly happy as files. Load the state, work on it in memory, save it back: that is a cache, a database and an audit trail in one, and git gives it history for free. ItIn effect, it is basically loading state and caching state,it, and that works reallyvery well. Issues-FS, which keeps issues as JSON files inside git repositories, with pluggable storage for memory, disk, S3, SQLite or a zip file, is the same idea applied to an issue tracker.
8 unchanged paragraphs, under Step two: the back end goes too {#backend}, What the newsroom is now {#newsroom}
It is worth listing what the SGit Newsroom does today, because the list is the argument. If you look at it as a pattern for a news organisation, it is, I would argue, ridiculouslyremarkably powerful: a content site publishing for several audiences, where each reader can have a personalised experience and an area of their own, in a completely private way, with on-ramps for different payment models. The column on the right is where each part runs.
| What it does | How | Where it runs |
|---|---|---|
| Publishes for several audiences, with a markdown twin of every page for agents | A static build from markdown sources, with an index for agents | Built in CI, served as files |
| Lands a reader as someone: a CISO as a CISO | Personas kept in a vault, opened with a published read key, followed or forked | Browser |
| Builds personas from what you read, several per reader | Pay to keep your persona: a graph you can watch grow | Browser |
| Charges by the share of a page you read, never blocks, lets you go below zero | SG Meter, a library any site can add | Browser |
| Lets you say what a page was worth, and that sets its price | Pay after you read | Browser |
| Takes money | A £5 Stripe payment link, no account, nothing renews.renews; Thelive linksince is11 October, a few hours after this article first said it was not set yet: until it is, the top-up is a simulated cartyet | A payment provider's hosted page |
| Gives every reader a newsroom of their own and a reading history | Kept in the browser's own storage | Browser |
| Sends your reading to us, if you choose, for a front page designed for you | Encrypted in the browser to a published public key, dropped into a write-only lane | Browser, then a vault lane |
| Takes newsletter sign-ups | The same encrypted, write-only inbox | Browser, then a vault lane |
| Shows how each article changed | Versions and diffs from git | Built in CI |
| Runs SQL and SPARQL over the site's own data | SQLite and Oxigraph compiled to WebAssembly | Browser |
| Signs you in (next) | Client-side OAuth with a provider | Browser and the provider |
There is no account database, no session store, no API server and no back end to deploy. The things that would normally need one, payments and identity, are rented from companies whose product they are: the payment page as soon as the link is set,now, and sign-in next. And the next pieces are already shaped to fit: a model in the client, with the reader's own key, and a persona that follows the reader to their phone and their agent, through a vault only they can open.
1 unchanged paragraph, under Not "no servers": commodity servers {#commodity}
I want to be precise about the claim, because "serverless" has come to mean several things. I am not saying there are no servers. Of course there are. GitHub Pages serves the files. A vault server stores the ciphertext. A payment provider will taketakes the money. A sign-in provider will vouch for an identity. DNS points at all of it, and GitHub Actions builds it.
15 unchanged paragraphs, under It scales without the complexity scaling {#scale}, Security as a business tool {#security}
That is a security judgement, and I think it is the right one. The question in Who are you protecting against? is the right question here: the site's readers are not an adversary trying to steal reading, because nothing is behind a wall. What is protected is narrower, and it is protected well: the reader's own history, from other people. It never leaves their browser unless they send it, and then only encrypted to a key we publish. A bigger back end would have made the site more secure against threats it does not face, and less useful, less private and slower to change for the readers it has. The advantages of a more robust server side are massivelyfar outweighed by the complexity, the deployment and the over-engineering it would bring. The meter's model also says what would change the call: if the balance ever unlocked something, the gaps would stop being acceptable, and that feature would get a signed receipt or a server, and not before.
23 unchanged paragraphs, under Why it is easy to throw technology away {#openness}, It ships fast {#speed}, Sovereignty, privacy, explainability, determinism {#principles}…
• Not that it is finished. The payment link is not set yet; sign-in,Sign-in, cross-device personas, a model in the client and signed receipts are next, not done.
4 unchanged paragraphs, under What comes next {#next}, Where this comes from {#sources}
Two voice memos of mine. I asked an agent in a separate Claude session to turn them into this article, with its figures and data, and to check every feature against the newsroom's and this site's own pages and repositories; this site's agent then rewrote it in the voice of this site, checked two things the draft could not confirm, and corrected them: the payment link iswas not set yet (the live top-up page iswas still the simulated cart),cart; it went live later the same day, and the article now says so), and client-side sign-in is next, not shipped. The argument is mine, and so is the editorial responsibility. The release counts are from this site's git log as of 11 October 2026, counted before this release; the accepted gaps are SG Meter's security model, paraphrased. Sources: LETS (Load, Extract, Transform, Save): a deterministic and debuggable data pipeline architecture, May 2025; Issues-FS on PyPI; on the newsroom, Databases with no server, SG Meter's security model and the newsroom; on this site, Where the vault keys live, Encrypted memory for agents that run somewhere else, A link to a persona, Pay to keep your persona, Going live with the reading meter, Pay after you read, Who are you protecting against?, Every mistake added a rule, How to run synthetic users and A chat box on a site with no server; and Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan, Local-first software: you own your data, in spite of the cloud, Ink & Switch, 2019.