The 342 MB workspace is only one layer of Firefly III
Firefly III is a private ledger for people who want to understand where their money went, then change what happens next. It records expenses and income using double-entry bookkeeping, with budgets, categories, tags, recurring transactions, savings goals, and reports on top. The application stays on your infrastructure unless you explicitly connect an outside service. A REST JSON API covers most of the product, which makes it possible to build a mobile client, importer, or household workflow around the same records.
The repository makes that control expensive in a familiar self-hosted way. Our checkout contained 2,415 files and about 288,449 lines of source before dependencies, while the npm install alone used 342 MB. This is a long-running PHP application with a database, persistent records, scheduled tasks, and upgrades. Someone must own those parts. The reward is a finance system whose raw history does not have to sit inside a budgeting vendor's account.
Budgets and rules go deeper than a simple expense chart
Firefly III treats transactions as records you can organize and act on. Rules can classify or modify matching entries, recurring transactions represent expected activity, and piggy banks track progress toward a goal. Reports draw from those same records rather than asking you to maintain a second spreadsheet. Multiple currencies and two-factor authentication are documented features, and the API makes the ledger useful beyond the supplied web interface.
That depth increases the cost of a wrong assumption. Open issue 12639 reports that the v6.6.6 rule-test endpoint returned no matches unless an optional accounts argument was supplied. The reporter stopped before triggering the rule because the empty preview looked suspicious. If rules can alter a meaningful set of transactions, test them on copied data and inspect the affected records. A preview endpoint should help, but one current report is enough reason not to treat it as the only guard.
What happened when we ran it
Our sandbox installed 781 npm packages in 29 seconds, leaving 342 MB on disk. The checkout was commit 46728cb in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. Npm audit reported 0 known vulnerabilities across critical, high, moderate, and low severities. Those results cover the JavaScript dependency workspace that our harness found.
There was no npm build script or target, so the build step was skipped. The repository also exposed no npm test script or target, so our harness skipped tests even though the checkout contains a tests directory and 11 CI workflow files. We did not run Firefly III's PHP suite, start a web server, connect a database, import an account, or inspect a rendered report. Calling this a passed application test would overstate what the log proves.
Importing bank data remains a separate trust boundary
The README says external tools handle imports. That separation is sensible because bank connectors have their own credentials and release cycles, but it gives the operator another component to inspect. You need to decide how transactions enter Firefly III, what access the importer receives, how duplicates are handled, and how a partial import becomes visible. Manual entry and file imports avoid some connector risk, though they demand more attention from the user.
A July 2026 Enable Banking report describes a sharp example: after 200 transactions, the next page used a mismatched date parameter, received HTTP 422, and the account's remaining transactions were skipped while the larger run appeared to continue. The report concerns the separate Firefly III Data Importer rather than the core application, but that distinction does not restore missing records. Reconcile imported totals against the bank, especially after changing a connector or requesting a long history.
Multi-currency reporting needs a trial with your own accounts
Firefly III lets users define currencies and records exchange information, but a feature checkbox does not settle every reporting expectation. Open issue 12632 describes two accounts in EUR and USD where several views showed converted amounts, while the default income, expense, and net-worth report kept the currencies separate. That may suit users who want original-currency reporting. It is a poor fit for someone who needs one home-currency number for every decision.
Release v6.6.6 also arrived specifically to fix a v6.6.5 regression that removed foreign-currency references from income entries. The quick corrective release is evidence of maintenance, while the bug shows why finance upgrades deserve a backup and a post-upgrade reconciliation. Run a representative month through reports before moving years of history. Check transfers, refunds, liabilities, exchange rates, and opening balances instead of judging the application from a clean dashboard.
Active August work supports adoption, not blind upgrades
GitHub recorded a push on August 26, 2026, and listed 24,419 stars plus 166 open issues and pull requests when we fetched the repository. Recent open discussions covered API rule testing, default multi-currency reports, and importer behavior. The combined count is not a bug total. It does show enough current traffic that an operator should search issues for the exact feature and version being deployed.
Firefly III is a strong choice for a technically comfortable person who values private, detailed records more than automatic convenience. The 29-second npm install says little about production readiness, but the documentation does acknowledge several real deployment paths. Start with disposable data, choose an importer deliberately, rehearse restore procedures, and verify reports after every upgrade that touches currencies or transaction processing.