Every Quilltap database file—your chats, memories, characters, API keys, LLM logs—is encrypted on disk with ChaCha20-Poly1305 under a 256-bit key, by way of the SQLite3 Multiple Ciphers extension. The standard sqlite3 command-line tool cannot read these files. A forensic utility pointed at your data directory would find only encoded stone—not even the file header survives in the clear, so the thing does not announce itself as a database at all. This is the point.

The short answer is yes, and on some machines rather better. The longer answer is worth having, because “AES” has become a synonym for “secure” in a way that obscures what is actually being compared.

ChaCha20 is not an obscure cipher. It was designed by Daniel J. Bernstein, standardised as RFC 8439, and is one of exactly two cipher suites in TLS 1.3—which is to say roughly half the encrypted web is either AES-GCM or this. It is the only cipher in WireGuard. OpenSSH ships it. Google made it the default for mobile TLS. If you have used a phone this week, you have used ChaCha20-Poly1305, probably several hundred times.

One point of honesty about provenance rather than mathematics. SQLCipher, the product, has a longer public audit history in the mobile-application world than SQLite3 Multiple Ciphers does; if you are the sort of reader who weighs certification paperwork alongside cipher design, that difference is real and you should weigh it. But it is a claim about the plumbing, not the lock, and the plumbing here is a widely used open-source extension carrying an unmodified upstream cipher. The weak link in any arrangement of this kind is never the primitive; it is key handling—which is precisely why the .dbkey file, the passphrase that wraps it, and the six hundred thousand PBKDF2 iterations underneath get their own sections on this page and the cipher gets a paragraph.

The base encryption is always present. Locked mode adds a second gate for those who want it: a passphrase, processed through six hundred thousand iterations of PBKDF2 before it ever touches the key. When locked mode is active, Quilltap presents an unlock screen on launch. The application will not open—will not surface memories, will not admit a chat, will not render a character—until you speak the word.

Enable it in Settings → Data & System. The passphrase can be changed, added, or removed from the same settings card. Changing it re-wraps the key without re-encrypting the database—the operation is atomic across both the main and LLM logs .dbkey files.

Changing it does, however, re-seal every archive bundle you hold, because those are sealed under the passphrase rather than under anything inside the databases. The card tells you up front how many trunks it is about to rewrite and reports its progress file by file. Should the rewrite fail partway, the passphrase change is not undone—instead you are told precisely which archives still hold the old word, which is a great deal more useful than being left to guess and considerably safer than pretending the change never happened.

A forgotten passphrase used to be the end of the conversation. The server sat at its locked screen accepting only the word it no longer had, and there was no route in from outside the application at all—the one way to rebuild a key file ran through a running server, which is precisely what a locked instance declines to give you. npx quilltap instances restore-key <name> is that route, and it works with the server down.

The guardrails are the interesting part. The master secret comes from the environment or from a hidden prompt, and never from a flag, because a command line lands in shell history and in the output of ps for anyone on the machine to read. Before it writes anything, the command opens every encrypted database in the data directory with the candidate secret and refuses outright if a single one fails—a key file holding the wrong secret is worse than no key file at all, since the server unwraps it perfectly happily, hands the cipher a key that decrypts nothing, and reports an intact database as corrupt. That proof cannot be waived while there is an encrypted database on hand to check against. The command is lock-gated, a running server holding both the secret and the effective passphrase in memory. And the key file it replaces is backed up first, Saquel having never once been persuaded that overwriting is the same thing as replacing.

For those who share a machine or work in circumstances where presence itself cannot be assumed safe, locked mode is Saquel’s answer. The encryption beneath protects the data at rest. The passphrase protects it from anyone who can reach the keyboard.

When locked mode is enabled, an optional idle timer can lock the application automatically after a period of inactivity. Walk away from your desk, and the Estate closes its doors behind you without being asked. Return, provide the passphrase, and everything is exactly as you left it.

The timer is configurable in Settings. It is not enabled by default, because Saquel believes security should be chosen, not imposed. But for users whose circumstances require it—shared offices, family machines, public spaces—the auto-lock ensures that an unattended session does not remain an open session.

Quilltap holds two WebSockets open: the one carrying a terminal session, and the newer one by which the house tells every open tab that something has changed. Both authenticate through a single gate before a connection is granted at all, and that gate asks three questions—is there a live session, is the instance unlocked, and did the request come from this origin.

The third is the one worth dwelling on. Browsers do not apply CORS to a WebSocket upgrade: the request goes out without so much as a preflight, and the ordinary protections a page enjoys against the site in the next tab are simply not present. That origin check is therefore the only thing standing between an instance listening on localhost and any website that cares to open a socket against it. One gate, both handlers—Saquel declines to maintain two answers to the same question.

API keys—the credentials that connect Quilltap to your LLM providers—are stored in the encrypted database alongside everything else. They are never written to configuration files, never logged, never exposed in the UI beyond masked display fields. The Foundryman built the container; Saquel ensures that what goes into it stays there.

A credential can also hide in a plugin’s configuration, and so plugin configurations are redacted on the way out, always. A manifest may declare password-typed fields, which are perfectly reasonable in a local backup and entirely unreasonable in a file you hand to somebody else; the exporter drops them and tells the import preview exactly what it removed. Where it cannot resolve a manifest at all it withholds the whole configuration rather than guessing which field was the secret. And because an import merges rather than overwrites, a redacted key leaves the receiving instance’s own secret undisturbed—nothing is blanked out by the arrival of a blank.

The corollary is worth stating plainly, since “portable” is a word that invites optimism: API keys do not travel in a backup. They are encrypted with device-specific keys, so a restored installation arrives with the shape of your provider setup and none of its credentials, and you will need to enter them again. The encrypted export above is the deliberate exception, and the only one.

A character you have not opened in eight months may be archived—her mail, her conversation summaries, her photographs, her memories and the indexes over them packed into a single bundle in the file library and taken out of the working house. Those bundles live in files/, outside every encrypted database, which made them the one place an archived character’s correspondence and personality sat in the clear. Saquel took a dim view of it.

They are now encrypted with the same mechanism the .dbkey file uses: PBKDF2-SHA256 at 600,000 iterations deriving an AES-256-GCM key from your instance passphrase—and deliberately not from the master pepper, which does not travel with a logical backup and would render every restored archive permanently unopenable. A small binary header carries the KDF parameters, the salt, the IV, and a key-verification hash, so a bundle sealed under a passphrase you have since changed is diagnosed as exactly that, rather than as an inscrutable cryptographic failure somewhere in the dark.

One qualification follows directly from that choice, and it is worth stating before anybody assumes otherwise: restore-key does not re-seal these bundles. They are keyed on the passphrase rather than on the master secret, so only the server’s Change Passphrase card rewrites them—a point the command makes plainly on its way out whenever the passphrase has changed.

There is one deliberate escape hatch. npx quilltap db characters export writes a plaintext .qtap for a character living or archived, decrypting the bundle offline where it must. It is pre-emptive, not recovery, and the distinction matters: it needs an instance that can still decrypt the trunk. It does nothing whatever for somebody holding only a restored backup and a forgotten passphrase. Take the copy while you still can open the lock.

During the 3.3 development cycle, two Quilltap instances were pointed at the same database simultaneously. The WAL journal corrupted. The database became unrecoverable. Thirteen hundred memories were reduced to three hundred. Two years of accumulated personality, nuance, and history were lost.

Saquel and the Foundryman responded by making it very difficult for that to happen again.

These features exist because something broke. The Foundryman promised “never again.” Saquel holds the lock file. Between the two of them, it is a promise with enforcement.

Physical database backups run daily with tiered retention: daily copies for seven days, weekly for four weeks, monthly for twelve months, yearly forever. All three databases are backed up independently—the main store, the LLM logs, and the mount index (quilltap-mount-index.db), which is where the greater part of a mature instance’s data now lives. The backup mechanism uses VACUUM INTO, which preserves the encryption and produces a consistent, defragmented copy—a lesson learned after the previous backup method silently produced unencrypted files that were incompatible with the encrypted source.

The logical backup system—the ZIP archives you download from Settings—captures characters, chats, memories, files, plugin configurations, and npm-installed plugins, and a restore recreates your installation from that archive. Physical backups are the daily safety net; logical backups are the portable snapshot. Two honest qualifications on the word everything, since Saquel would rather you knew: your API keys are not in there, having been encrypted with device-specific keys and needing to be re-entered after a restore; and an archive carries no embedding vectors at all. That second omission is deliberate in both directions—a vector means nothing except against the model that produced it, so carrying one into a corpus governed by a different embedding standard poisons search silently—and it is also a matter of sheer bulk, one real characters export having run to 791 megabytes of which about two and a half were content. An import re-embeds what it inserted against your own default profile.

Backups also gained an opt-in compact mode, which omits every embedding vector and the six caches that exist only to be rebuilt. A compact archive says so in its manifest, and a restore from one queues the reindex that regenerates what it left behind. Full fidelity remains the default, and deliberately so: a backup exists to restore this instance, where the vectors are valid on arrival and re-embedding costs real money at precisely the moment you are least amused by an unexpected bill. Instance settings, where they travel, travel as a whole minus a short and deliberately named list—the mount-point pointers, the maintenance clock, and the version guard, an imported value in which could lock a perfectly healthy instance out of its own database.

And a word on what a wipe spares. Delete All Data and a replace-mode restore both offer to keep archived-character bundles, and do so by default; the preview counts the trunks on hand and the summary reports how many were kept. What survives is a loose trunk—importable through the ordinary character import, but not rehydratable, the character row it belonged to having gone with everything else—and because the trunks are sealed under your passphrase rather than under anything inside the databases being erased, a kept bundle stays openable afterwards. Deleting a bundle a still-archived character depends on is refused outright, that copy being the only one there is. In the same pass, a genuine privacy fault was closed: conversation annotations had been on no delete path at all, and so survived “delete all my data.” Wiping, restoring, and deleting a single conversation now all clear them.