ezBookkeeping: a Go and Vue self-hosted ledger that runs on a Raspberry Pi

The problem ezBookkeeping solves: your transaction history on your own disk

Most personal finance apps assume the ledger lives on someone else's server. ezBookkeeping takes the opposite position. The README describes it as a self-hosted personal finance app built for privacy and control, and the deployment story backs that up: a single Docker command, or a downloaded binary invoked as ./ezbookkeeping server run. The intended operator is someone with a home server, a NAS, or a Raspberry Pi who is willing to run one more container in exchange for keeping the data local. The README explicitly names those three device classes as targets, which tells you the project is optimizing for small always-on boxes rather than a VPS with spare capacity. The scope is personal bookkeeping, not business accounting: recording daily transactions, importing statements, searching and filtering them, and charting the result.

Two-level accounts, scheduled transactions, and the rest of the data model

The feature list describes two-level accounts and two-level categories, so the hierarchy stops at parent and child rather than an arbitrary tree. Transactions can carry image attachments and location data with maps, and the project supports scheduled transactions, which means recurring entries are a first-class concept rather than something you re-enter each month. Analysis runs through built-in charts plus custom queries where you choose the chart dimensions yourself. That last point is the one worth noting: the README does not describe a fixed report set, it describes a query surface you compose. For a single-user ledger that is a reasonable design, because the questions people ask of their own spending change over time and a fixed dashboard ages badly. The trade-off is that a custom query interface pushes configuration work onto the user in a way that a canned monthly report would not.

Getting it running: one Docker command, then a volume you must not forget

The README gives the shortest path as docker run -p8080:8080 mayswind/ezbookkeeping, with a latest-snapshot tag available for daily builds. The default port is 8080, and the app is then reachable at http://{YOUR_HOST_ADDRESS}:8080/. The README is direct about the production caveat: you need to mount a persistent volume when starting the container to prevent data loss, and it points to the Docker installation page for the specifics. That warning matters more than it looks, because the one-liner above creates no volume, so anything recorded in that container disappears with it. The binary route is equally short: download a release and run ./ezbookkeeping server run on Linux or macOS, or .\ezbookkeeping.exe server run on Windows. Building from source requires Go, GCC, Node.js and NPM, then ./build.sh package -o ezbookkeeping.tar.gz on Linux or macOS, or .\build.bat package -o ezbookkeeping.zip on Windows. A Docker image can be built with ./build.sh docker. Storage backends are SQLite, MySQL and PostgreSQL, and the README lists Windows, macOS and Linux plus x86, amd64 and ARM as supported targets. The README does not spell out the environment variables or config keys used to select a database backend, so treat that as something to confirm in the installation documentation before you migrate away from the default.

Import is the real feature: CSV, OFX, QIF, MT940 and Firefly III

The import list is unusually long for a project this size: CSV, Excel, OFX, QFX, QIF, IIF, Camt.052, Camt.053, MT940, GnuCash, Firefly III and Beancount. Camt.052 and Camt.053 are the ISO 20022 bank statement formats, and MT940 is the older SWIFT statement format, so the project is targeting people who can pull structured exports from their bank rather than only hand-keying entries. For CSV and Excel the README mentions custom column mapping, rules and scripts, which is the mechanism that makes arbitrary bank exports workable: you map your file's columns onto the app's fields and attach rules to transform them. Migration from Firefly III and Beancount is listed as a supported import path, which is a concrete answer to the question of what happens to an existing ledger. The honest limitation is that column mapping is configuration you have to get right per bank, and the README does not describe an error-reporting model for partially mapped imports, so a malformed CSV is something you should test on a throwaway dataset before trusting it with a year of statements.

Authentication, 2FA, OIDC and the application lock

Because this is a web service holding financial records, the security surface is not incidental. The README lists two-factor authentication, OIDC external authentication, login rate limiting, and an application lock using a PIN code or WebAuthn. OIDC support means you can put the app behind an existing identity provider instead of maintaining a separate password, which is the pattern most homelab operators already run for other services. The application lock is a second gate in front of an already authenticated session, which is useful on a shared device but is not a substitute for transport security. Note what the README does not claim: there is no mention of encryption at rest, so the protection of the database file itself is your responsibility, which for SQLite means filesystem permissions and disk encryption on the host. That is a normal arrangement for self-hosted software, but it should be a conscious decision rather than an assumption.

Where ezBookkeeping is the wrong tool

This is a personal bookkeeping app, not an accounting system, and the distinction is not cosmetic. There is no mention of double-entry enforcement, no chart of accounts beyond the two-level structure, and no reconciliation workflow described in the README. If you need books that balance by construction, or records an accountant will accept, this is the wrong layer. The second boundary is operational: self-hosting means you own backups, upgrades and uptime. A single Docker command is easy to start and equally easy to lose, and the README's own volume warning is the clearest signal that data durability is on you. The third boundary is the AI features. The README lists text and receipt image recognition, MCP support for AI integration, and agent skill plus API command-line script tools. Those are real capabilities, but they are also the parts of the project most likely to depend on external services or credentials, and the README does not describe how recognition is performed or what it sends where. If sending receipt images to a third party is unacceptable to you, verify that path before enabling it.

How it compares with Firefly III, and why the import list matters

Firefly III is the obvious reference point, and not only because it appears in the import list. Firefly III is a PHP application with a long-standing emphasis on double-entry accounting and a rules engine for categorizing transactions. ezBookkeeping is a Go binary with a Vue front end, and its pitch is resource efficiency on small hardware plus a mobile-first PWA interface. The practical difference is what each one optimizes for: Firefly III models your money as accounts with debits and credits, while ezBookkeeping models it as transactions with two-level categories and accounts. If you have ever wanted an enforced balance, the Firefly III model is closer to that. If you want something that starts in one command, idles quietly on a Pi, and imports your bank's Camt.053 file, ezBookkeeping is the lighter path. The fact that ezBookkeeping can import a Firefly III export makes the move one-directional in practice: trying it costs you an export, while moving back means re-importing into a model that expects different invariants.

Maintenance, licensing and what to verify first

The project is MIT licensed, which is permissive: you can run, modify and redistribute it, including in modified form, provided the licence and copyright notice are preserved. That is a description of the licence text, not legal advice, and if you plan to redistribute a modified build you should read the LICENSE file in the repository yourself. On maintenance cost, the release history shows v1.6.1 in July 2026, v1.6.0 the day before, and v1.5.1 in May 2026, so the cadence is active but the gaps between minor lines are measured in weeks to months rather than days. Upgrading a Docker deployment means pulling a new image and restarting the container, which is cheap; the expensive part is the database, and that is where your storage choice matters. SQLite keeps everything in one file, which makes backup a file copy but ties you to a single writer. MySQL or PostgreSQL give you a proper server and a migration path, at the cost of running and backing up another service. The README does not document the schema migration behaviour between versions, so before upgrading a ledger you care about, take a copy of the database file or dump first, then run the new image against it. The translation table in the README also shows community-maintained locale coverage with per-language progress badges, which means non-English interfaces vary in completeness and are worth checking for your language on the demo instance before you commit.

Editorial conclusion

Adopt ezBookkeeping if you already run a NAS or home server, want SQLite as the default store, and care more about importing existing bank exports than about double-entry accounting. Do not adopt it if you need enforced double-entry bookkeeping or a hosted service you never administer. Before committing real data, mount a persistent volume as the README instructs, run the Docker image once, and confirm that your bank's CSV or OFX export maps cleanly through the custom column mapping step.

Official sources

1. License: MIT
2. mayswind/ezbookkeeping on GitHub
3. Project website
4. README
5. Releases