Skip to main content
Zeno works against your QuickBooks company files, and it keeps its own records too. You should know exactly what those are and where they sit, because for a bookkeeping practice they amount to client data.

​
What is stored, and where

Everything lives in one directory, %LOCALAPPDATA%\Zeno\qb-mcp by default: Two things follow from that list. The mirror holds your clients’ ledgers — names, amounts, memos, customer and vendor emails and phones — in ordinary SQLite that any tool can read. And the journal holds the full payload of everything you’ve posted, which is the same data by another route. The location can be moved with DataDirectory in appsettings.json or the QBMCP_DataDirectory environment variable — which is how a shared journal ends up on a network share.

​
How it’s protected

The databases are encrypted. The journal and every mirror are SQLCipher-encrypted under a key minted on this workstation and protected by Windows itself (DPAPI), tied to your Windows account. There’s nothing to type and nothing to lose: signing in as you is what unlocks them. A copied file, a scooped backup, or a lifted disk is ciphertext without your Windows credentials. Databases created before encryption existed are converted automatically the first time the new build touches them — note that backups taken before that date still contain unencrypted copies, and should be treated as containing the books. Because the key is tied to your Windows account, your backups are only readable restored under that same account. Mirrors can always be rebuilt with qb_sync_mirror; the journal is your posting history, so keep workstation backups and keep the account. The directory is restricted to your Windows account. On startup, Zeno cuts permission inheritance on the data directory and narrows access to the owning user, SYSTEM, and Administrators. Other accounts on the machine can’t read it, and files created later — including new mirrors — inherit the restriction. If narrowing fails for any reason, Zeno says so in its log and carries on: a permissions hiccup shouldn’t stop your bookkeeping. It stays off the cloud by default. %LOCALAPPDATA% is not synced by OneDrive or roamed between machines, which is part of why Zeno lives there. If you point DataDirectory somewhere that is synced — a Dropbox folder, a OneDrive-redirected path — copies of client data will follow that service’s rules, not Zeno’s. Don’t do that; use a network share for sharing. On a share, your licence key is what unlocks the books. A shared journal can’t use a per-account key — six workstations need the same one — so Zeno encrypts a shared data directory under a key opened by the firm’s licence. Every seat that holds the current license.key opens the journal and mirrors; when the licence changes (a seat named, updates renewed), saving the new key through any workstation’s console keeps the keyring current, and a workstation whose key no longer matches is told exactly that at startup, with the fix. A shared directory with no licence installed stays unencrypted, protected by the share alone. Two things follow. Your licence key is now a decryption key — never email it, and support will never ask for it; the machine id shown on the console’s Licence tab is what support needs. And the share’s own rules still matter: give it the same access list you’d give the client files themselves, because the running workstations hold the books decrypted.

​
What you should do

  • Turn on BitLocker on any workstation that runs Zeno. The permission narrowing protects against other accounts; only disk encryption protects a stolen or resold machine.
  • Check what your backup tool scoops up. If workstation backups include %LOCALAPPDATA%, they include client ledgers. That’s usually what you want — just make sure the backups themselves are encrypted and access controlled.
  • Removing a client removes their mirror. qb_forget_company deletes the company’s registration and its mirror database. Journal history for work already posted is kept — that’s your audit record.

​
The crash-recovery records

The write-recovery\ folder holds the exact request of any posting that was mid-flight — it’s how Zeno answers “did that write land?” after a crash. These records always stay on the workstation that made them, never on the share, and each one is sealed to that workstation’s Windows account the same way the local databases are. Records from before sealing existed remain readable and are re-sealed as they’re touched.