GnuCash

Last reviewed Sep 13, 2026 · 805 words

There is no GnuCash server. It is a desktop program, first released in 1998, and "self-hosting" it comes down to one question: where does the book live, and how do 2 machines share it without corrupting it. The answer that has survived years of use for me is a SQLite book synced by Syncthing and opened on one machine at a time, with PostgreSQL as the upgrade when that rule becomes too hard to keep. If what you actually want is a ledger in a browser tab, stop here and look at Firefly III or Actual; GnuCash will never be that.

What you are buying is real double-entry

Every transaction touches at least 2 accounts, the books always balance, and the reports (balance sheet, profit and loss, cash flow, budget versus actual) are the same ones an accountant would produce. Investment accounts track lots and cost basis, scheduled transactions post rent and salary on their own, and the small-business features cover customers, vendors, invoices and bills with tax tables. Bank imports come in via OFX, QIF and CSV; direct bank connections exist through AqBanking but work mainly for European FinTS banks, so most people export from the bank and import. The catalogue's Medium difficulty is about bookkeeping, not installation; the install is a package manager command on any Linux, macOS or Windows machine, at 256 MB of RAM.

Four storage backends, and only two you should use

GnuCash saves to compressed XML by default, or to SQLite, MySQL or PostgreSQL. The XML file is loaded whole into memory and written whole on Save; the SQL backends write every change immediately and have no Save button. That distinction matters more than it looks:

Skip MySQL unless you already run it; PostgreSQL is the better-supported of the two. Do not expect multi-user from the SQL backends either. GnuCash writes a lock row when it opens a book and refuses a second concurrent open, so a shared database gives you access from anywhere, not two people editing at once.

Syncing a book file without wrecking it

The failure mode is always the same: the book is open on the laptop, the desktop opens it too, both write, the sync tool produces a conflict copy, and the last 3 weeks of reconciliation exist in 2 incompatible versions. Three rules avoid it. Use SQLite, not XML, so a crash mid-save cannot leave a half-written file. Sync the .gnucash file and ignore the .LCK lock file GnuCash drops beside it; syncing the lock file is how the other machine gets told the book is open when it is not. And close GnuCash before walking away, because the lock rule only helps if the file is actually closed.

If two people genuinely need the same book from different rooms, the honest answer is PostgreSQL on a box that is always on. Then the sync problem disappears, backups become pg_dump on a cron, and the 3-2-1 backup habit applies exactly as it would to any other service. Note that GnuCash's own automatic backup copies only exist for XML books, so a SQLite or Postgres book has no safety net until you build one.

Where Firefly III and Actual beat it, and where they do not

Both are web apps with mobile access, multi-device by nature, built around budgeting and spending categories, and easier to live with day to day. Firefly III has bank feed integrations and rules; Actual has envelope budgeting and local-first sync. Neither does invoicing, accounts receivable, lot-tracked investments, or reports an accountant will accept at year end. If your books are a household budget, pick one of them and be happy. If you run a small business, hold investments across brokerages, or are leaving QuickBooks and need proper double-entry, GnuCash is still the most complete free option and its 4,334 stars undersell how many people quietly rely on it.

What I'd do

Household or freelancer with one main machine: SQLite book in a Syncthing folder, .LCK ignored, restic backing up the folder nightly, GnuCash closed before you leave the desk. Two or more people, or a business: PostgreSQL on the home server, GnuCash on each desktop pointing at it, pg_dump every night to a second location. Either way, expect the dated interface to stay dated, and expect the accounting to be correct for as long as you keep entering it.