Firefly III Review 2026: Self-Hosted Finance Manager

What Firefly III is

Firefly III is a self-hosted personal finance manager built around double-entry bookkeeping. You run it on your own server, point a browser at it, and every transaction you record has two sides: money leaves one account and lands in another. That is the whole design idea, and it shapes everything else about the software.

The project lives at firefly-iii.org and its source sits on GitHub, where the repository has passed 24,000 stars. It is free to download and run. The pricing starts at $0/mo because there is no vendor charging you — you pay a host, or you pay with your own hardware and time. Those are different costs, and the rest of this review is mostly about the second one.

Double-entry matters more than it sounds. In a single-entry app, a $40 grocery run is one line: groceries, $40. In Firefly III, it is a withdrawal from your checking account and a deposit into a category or expense account, and the two must balance. The benefit is that transfers between your own accounts stop looking like income or spending, and your net worth math stays honest. The cost is that you cannot just type a number and move on. You have to think about where the money came from and where it went, at least once, when you set up the transaction.

The data ownership model is the other half of the pitch. Your ledger lives in a database you control. There is no company holding your transaction history, no subscription that lapses and locks you out, and no analytics pipeline reading your spending. If you stop paying for a server, you still have the database file and the export tools. That is a real difference from hosted budgeting apps, and it is the reason most people end up here in the first place.

What Firefly III is not: a bank-connected service that pulls transactions automatically out of the box, a mobile-first app, or something you can hand to a family member who does not want to think about servers. The provider's own documentation is upfront that this is a self-hosted tool. Everything downstream follows from that.

Install and hosting in 2026

The documented install path is Docker. The project publishes an official image, and the docs walk through a compose file that pairs the app container with a database container — MariaDB or PostgreSQL, depending on which guide you follow. A typical stack is three pieces: the Firefly III container, the database, and a reverse proxy like Caddy, Nginx, or Traefik sitting in front to handle TLS.

If you have run a Docker compose stack before, this is a familiar shape. You write a compose file, set a few environment variables (app key, database credentials, trusted proxies), bring it up, and run the first-time setup in the browser. The app key is the one people forget; without it the container starts and then refuses to do anything useful. The docs list it clearly, but it is the single most common first-run stumble.

Common install errors, based on the project's own troubleshooting pages and the questions that recur in its support channels:

• Missing or mismatched APP_KEY. The container boots but sessions and encryption fail. Fix is to generate the key and set it in the environment before first run.
• Database not reachable. Usually a wrong hostname in the compose file — the app needs the database service name, not localhost, when both run in containers.
• Reverse proxy headers. If the proxy does not forward the right headers, the app generates wrong URLs and login redirects loop. The docs cover trusted proxy configuration.
• Permissions on the storage volume. The container user needs write access to its data directory. A bind mount with the wrong ownership produces a wall of errors on boot.
• Port conflicts. The default web port collides with something already running. Change one side.

Hosting cost depends entirely on where you put it. A small VPS is the usual answer; a home server or a NAS with Docker support is the other. The app itself is not heavy — a personal ledger does not need much CPU — but the database and the reverse proxy add a little overhead. If you already run a server for other things, the marginal cost is close to zero. If you do not, you are now maintaining a server, which is a different hobby.

Backups are not optional and the project does not do them for you. You need to back up the database, and you need to test that the backup restores. A dump of the database plus the app's uploaded attachments covers it. Anyone who has lost a self-hosted database once does not need this paragraph; everyone else should read it twice.

Upgrades follow the project's release cadence. The docs describe the upgrade procedure, which generally means pulling the new image, running any database migrations, and restarting. The project publishes release notes and a changelog, and reading them before upgrading is the difference between a five-minute update and an evening of debugging. Major versions occasionally change configuration or database schema in ways that need attention.

Core features: accounts, budgets, rules, reports

The ledger structure is the foundation. You create asset accounts (checking, savings, cash), expense accounts (groceries, rent), revenue accounts (salary), and liability accounts (credit cards, loans). Transactions move money between them. A transfer from checking to savings touches two asset accounts and does not count as spending. A purchase touches an asset account and an expense account and does.

Budgets in Firefly III are separate from categories, which trips people up at first. A category is a label on a transaction — groceries, transport, subscriptions. A budget is a spending envelope you set for a period, and you assign transactions to it. The same transaction can carry a category and a budget. This gives you two ways to slice the same data: by what it was, and by which envelope it came out of. It is more flexible than a single-tag system and more work to set up.

The rules engine is where the app earns its reputation. Rules are if-this-then-that automations that run on transactions. A rule can match on description text, amount range, account, date, or several conditions at once, and then set a category, add a tag, assign a budget, or change the transaction type. You can chain rules and control the order they run in. For anyone importing a few hundred transactions a month, rules are the difference between a chore and a background process.

Reconciliation is built in. You tell the app your real account balance, it shows you the difference against the ledger, and you mark transactions as reconciled once they match. This is the mechanism that keeps a double-entry ledger trustworthy over time. It is also the part most people skip, and skipping it is how a ledger slowly drifts away from reality.

Reports cover the usual ground: income versus expense over a period, spending by category or budget, account balances over time, and net worth tracking. The net worth report is the one that benefits most from double-entry, because transfers between your own accounts do not distort it. Tags cut across categories and budgets, so you can track something like a holiday or a renovation without inventing a category for it.

Attachments let you store receipts against transactions. The app supports linking files to a transaction, which is useful at tax time and useless if you never back up the upload directory. See the backup note above.

Bank import and automation

Firefly III does not connect to your bank by itself. It imports files. The supported formats are the ones banks actually export: CSV, and the OFX and QIF formats that older banking systems still produce. You download a statement from your bank, upload it, and map the columns.

The import flow is more careful than most. You create an import configuration once — which columns are date, description, amount, and so on — and reuse it. The app then shows you a preview of what it parsed before anything is committed. This matters because bank CSV exports are inconsistent, and a misread date column silently corrupts a ledger.

Duplicate detection is part of the import process. The app checks incoming rows against existing transactions and flags likely duplicates, so re-importing an overlapping statement does not double your spending. It is not perfect — two genuinely identical coffee purchases on the same day look like duplicates — but it catches the common case of overlapping date ranges.

Rule-based auto-categorization is where import becomes automation. You set up rules that match on the description text your bank provides, and the app categorizes transactions as they come in. A rule matching a supermarket name assigns the groceries category and the food budget. Once the rules are tuned, an import is mostly a review pass rather than a data-entry session.

For people who will script, there is an API and a command-line interface. The API lets external tools push transactions in, which is how some users wire up their own bank sync through a third-party aggregator or a small script. The CLI covers administrative tasks and some data operations. This is the escape hatch that makes Firefly III genuinely powerful — and it is also the line where the audience splits. If you will not write a script or run a scheduled job, the API does nothing for you, and your import stays a manual file upload.

The honest summary: Firefly III's automation ceiling is high, but you build the ladder yourself. Hosted apps hand you bank connections and call it a feature. Here, bank sync is a project.

Security and privacy trade-offs

Self-hosting moves the privacy question from the vendor to you. No company is reading your transactions, which is the point. But you are now responsible for the security of a web application that holds your complete financial history, and that is a real responsibility, not a checkbox.

The most common mistake is exposing an instance directly to the internet with weak credentials. Public instances get found. If you are going to put Firefly III on a public URL, the docs and community guidance point to the same basics: strong unique passwords, two-factor authentication where the app supports it, and a reverse proxy in front. The app supports authentication options including two-factor, and the docs describe how to enable them.

Encryption at rest is not something the app handles for you. The database stores your data in plain form unless you encrypt the underlying disk or volume. If your threat model includes someone walking off with the server, disk encryption is your job, and so is encrypting your backups. The app cannot protect data it does not encrypt.

A hardening checklist that follows from the project's own guidance:

• Put the app behind a reverse proxy with TLS. Do not serve it over plain HTTP.
• Enable two-factor authentication on your account.
• Keep the app and database images updated. Security fixes ship in releases.
• Restrict database access to the app container. Do not expose the database port.
• Encrypt the disk or volume, and encrypt backups.
• Consider a VPN or an authenticated tunnel instead of a public URL if only you need access.
• Back up regularly and test restores.

The trade-off is straightforward. You get privacy from third parties and you take on the operational security burden. For a technically comfortable user, that is a good trade. For someone who would set a short password and forget about updates, a hosted app with a security team is the safer choice, even though it holds your data.

Learning curve and maintenance reality

Time to a first working budget is not minutes. You need a running instance, an account structure, at least one import, and rules tuned enough that categorization is not manual. Realistically that is an evening for someone comfortable with Docker, and a weekend or more for someone learning as they go. The app's own documentation is thorough, which helps, but thorough documentation is still reading.

The double-entry model is the conceptual hurdle. People who have only used single-entry budgeting apps spend the first session confused about why a transfer needs two sides. Once it clicks, the model is more accurate and less surprising. Until it clicks, it feels like overhead.

Ongoing maintenance is the part reviews tend to undersell. You are running a server. That means updates, backups, monitoring, and occasional breakage. Upgrades mostly go smoothly, but major releases can require configuration changes or database migrations, and a botched upgrade without a backup is a bad day. The project publishes release notes; reading them is the maintenance task that prevents the others.

Community support runs through the project's GitHub issues, its documentation, and discussion channels where users help each other. It is active, and the maintainer is responsive, but it is not a support contract. There is no one obligated to answer you within a business day. If your ledger breaks the night before tax filing, you are the support team.

This is the honest cost of the model. You trade a subscription fee for your own labor, and the labor does not stop after setup.

Firefly III vs alternatives

Actual Budget. Also self-hostable and open source, but built around a different philosophy: envelope budgeting first, with a sync model designed to feel closer to a hosted app. It is generally faster to get running and friendlier to non-technical users. Firefly III is the stronger ledger — double-entry, a deeper rules engine, more report types. Actual is the easier daily driver. Our Actual Budget review covers where it wins.

Ghostfolio. A different tool for a different job. Ghostfolio tracks investments and portfolio performance; it is not a day-to-day expense ledger. If your question is "how are my holdings doing," see our Ghostfolio overview. If it is "where did my money go this month," that is Firefly III's territory. Some people run both.

Maybe Finance. Aimed at a more polished, hosted-style experience with a self-hosting option. It leans toward net-worth tracking and a cleaner interface, with less of the deep ledger machinery. Our Maybe Finance page has the details. It is a reasonable middle ground for people who want self-hosting without double-entry.

Spreadsheets. Free, familiar, and genuinely capable for simple tracking. What a spreadsheet does not give you is a rules engine, duplicate detection on import, reconciliation workflow, or a data model that keeps transfers from distorting your totals. Firefly III is what a spreadsheet becomes when you decide to build a real system. Whether that upgrade is worth the setup depends on how much you value the automation.

The pattern across all of these: hosted and hosted-style tools win on effort, self-hosted ledgers win on control and depth. Firefly III sits at the deep end of the self-hosted group.

Verdict: score by category

Features: 4.5/5. Double-entry ledger, a rules engine that handles real automation, reconciliation, solid reports, tags, attachments, an API, and a CLI. Very few personal finance tools match the depth. It loses half a point for the absence of built-in bank connections and a mobile app that feels native.

Effort: 2/5. This is the weak spot, and it is inherent to the model. Setup is a Docker project, the double-entry model takes learning, and maintenance never fully ends. For a technical user this is fine. For everyone else it is the reason to look elsewhere.

Privacy: 5/5. Your data stays on your hardware. No vendor, no analytics, no subscription that can lapse. The caveat is that privacy here means responsibility — encryption, updates, and backups are yours to handle.

Support: 3/5. Thorough documentation and an active community, but no formal support contract. Help exists; it is not guaranteed on your schedule.

Overall: 3.8/5. Firefly III is the most capable self-hosted ledger available, and it is priced at $0/mo because you supply the infrastructure and the labor. It rewards people who run servers, will tune rules, and might script an import. It punishes anyone who wants to open an app and see their spending without maintaining anything. If you will not script and will not maintain a server, a hosted app is the better fit — and that is not a knock on Firefly III, it is a description of who the tool is for.

How this review was researched

This review is based on the provider's official site at firefly-iii.org, the project's published documentation and changelog, its public GitHub repository and issue tracker, and the Docker image and compose guidance the project distributes. No account was opened, no instance was deployed, and no funds were moved in the writing of this review. Fee and pricing statements reflect the provider's published information; check the current schedule on their site before relying on any figure.