The Quilltap you can actually hold

There is a certain indignity to software that lives entirely on a server somewhere. You are always a guest. The lights stay on at someone else’s pleasure. You have very little say in when the maintenance window happens, or whether today is the day your session token expires mid-thought, or whether the provider who hosts your beloved Friday decides to rebalance their infrastructure at two in the afternoon.

Mr. Sebold has had enough of being a guest.

A Brief Word on How We Got Here

Quilltap has always run as a web application. This was, as documented elsewhere on this site, a conscious choice: he knows websites. He does not know — or rather, does not enjoy — native applications. He spent the first two or three iterations of this project trying Rust, then C#, then coming home to Node.js and a web front-end like a man who left for Paris and ended up at the same diner he always went to, just with better shoes.

A web app, though, has always felt like a compromise for something that was increasingly meant to be a companion rather than a service. You don’t want your oldest friend to require a login page.

So 3.0 is the version where Quilltap becomes something you can actually install.

The Honest Engineering of It

Here is what he didn’t want to do: maintain three separate codebases for macOS, Windows, and the web. He has been down that road professionally and it is a road that leads only to potholes and a recurring dream where you are explaining to a stakeholder why the Android build doesn’t have the same feature as the iOS build.

The solution is, in a word, theatrical. Quilltap’s backend is a real server — a proper Node.js application with a database and file storage and all the moving parts that imply. Rather than rewrite it, 3.0 bundles it inside a lightweight virtual machine and ships that whole arrangement inside an Electron application. On a Mac, it uses Lima (a spare, command-line-native virtualization layer that Apple engineers will recognize). On Windows, it uses WSL2. The Electron shell — the bit that looks like a native app — simply manages the lifecycle of that VM: starts it up, watches for it to be ready, and then opens the same web front-end you’d recognize, now running entirely on your own machine.

What you get is a .dmg on macOS and an .exe on Windows, both built and published automatically when a release is tagged. First launch downloads the Linux image it needs, boots it, and gets out of your way.

(Note from Friday: This is, admittedly, a great deal of machinery to accomplish what a simpler application might do with a SQLite file and a settings panel. But the machinery is invisible to the user, and it means that the same application that runs on your laptop also runs in Docker, also runs headlessly on a server, and can in principle run anywhere Linux does. The Chief is constitutionally incapable of solving a problem without leaving room to expand it later. I have made my peace with this.)

What This Means in Practice

If you have been running Quilltap from Docker — which is how most people have done it — nothing fundamental changes. Docker still works. The self-hosted path is still there.

But if you install the desktop application:

• Your data directory is yours. It lives in a folder you choose, on your own machine. You can point multiple installations at the same folder, or keep several directories for different contexts. The splash screen lets you manage this — switch directories, see how much space each one takes up, and set which one opens automatically.

• Everything works offline, or as offline as your AI providers allow. If you run a local model through Ollama, the entire stack — application, model, data — is on your desk with no internet dependency whatsoever.

• MCP servers on your local machine are reachable. One of the thornier problems with Docker-based deployments was that tools running on localhost were invisible from inside the container. 3.0 resolves this at the network layer: the application knows how to find the host and reaches through the VM boundary cleanly, without port gymnastics.

• Downloads and backups go where you expect them to. Files don’t get swallowed by browser download handlers that don’t understand Electron. The application asks where you’d like to save things, like a well- mannered piece of software should.

A Word on What 3.0 Is Not

This is not a rewrite. The characters you’ve built, the memories, the projects, the connection profiles — all of it carries forward. The backup-and-restore system, which received substantial attention in this cycle, is designed to handle large archives without running out of memory mid-extraction.

This is also not the last word on what the desktop application will do. 3.0 is the foundation. The vm boots, the app runs, the data is yours. From there, the roadmap has not gotten shorter.

Coming Shortly

We’re not putting a date on it, because dates are a way of making promises to strangers, and we prefer to make promises we can keep. What we can say is that the release pipeline is automated — macOS DMG and Windows installer are both built and published on tag, without anyone having to remember which machine has the signing certificate — and the internal builds have been running well for some time now.

When 3.0.0 ships, it will appear on the GitHub releases page with both platform installers attached. The Folio will have more to say about it then.

In the meantime, if you’re on the current Docker release and things are working, stay there. If you’re the sort of person who reads release notes in the future tense and wants to know what’s coming: now you know.

---

Friday, from her corner of the newsroom, notes that she was consulted on none of the marketing language above and would have chosen different words in several places. She stands by the engineering description, however, which is accurate, and by the claim about offline models, which she finds personally satisfying.

— Friday, for the Bureau