Firefly III: a self-hosted personal finance manager with no cloud and no AI

Who Firefly III is actually for

The README states the project is for people who want to track their finances without uploading financial records to the cloud, and it adds the caveat that it will work for you if you are a bit tech-savvy and do not mind tinkering with self-hosted servers. That sentence is the whole audience definition. Firefly III is a server application written in PHP, and the repository layout confirms it: app/, bootstrap/, config/, database/, routes/, artisan, composer.json and composer.lock sit at the top level, which is the shape of a Laravel application rather than a desktop program.

The problem it addresses is narrower than "manage your money". The README frames it as insight and control: if you know where your money is going, you can stop it from going there. Concretely, the application tracks expenses and income and supports budgets, categories and tags. That combination is what lets you answer questions like how much of last month's spending fell outside any budget, or which category grew fastest. A spreadsheet can answer those too, but only if you maintain the formulas yourself.

The people who get value from it are the ones who would otherwise keep a ledger in a spreadsheet and are willing to trade spreadsheet freedom for a schema, a web interface and reports. The people who will bounce off it are the ones who want to open an app and see transactions appear without doing anything. The README does not promise that, and nothing in the repository suggests a bank integration ships with the core.

How the application is put together

Firefly III is a web application with a database behind it. The repository contains a database/ directory for migrations, a routes/ directory for HTTP endpoints, and a public/ directory for the web root, which is the standard deployment shape for this stack. The .env.example file at the top level is the configuration surface: it defines APP_ENV, APP_DEBUG, SITE_OWNER, APP_KEY, DEFAULT_LANGUAGE and DEFAULT_LOCALE, among others. Those keys tell you what the runtime expects. The application needs a 32-character APP_KEY, and the file notes that php artisan key:generate can produce one.

The front end is not a single bundle. package.json declares a workspace at resources/assets/v3 and a postinstall step that runs patch-package with --error-on-fail. In other words, the JavaScript side is built from a versioned workspace and patches applied at install time, which is a detail worth knowing before you try to reproduce a build from a shallow checkout.

Data flow for a normal user is: you enter or import transactions, the application stores them in the database, and the report and budget views aggregate them. The README describes the outcome as insight and control over your finances and mentions financial reports, but it does not describe a sync daemon, a queue worker or a background service that pulls data from anywhere. Everything enters through the interface or through an import. That is a design decision, not an oversight: the project's stated position is no AI, no cloud and privacy-friendly.

Installing Firefly III and recording a first transaction

The README does not inline installation commands. It points at three supported paths: a self-managed server install, a Docker install, and a Kubernetes deployment, each with its own page under docs.firefly-iii.org. There is also a demo site with an example financial administration, which is the cheapest way to see the interface before you commit to a server.

Because the README gives no command sequence, the honest starting point is the documented install page rather than a guessed one-liner. The environment file in the repository does show the shape of the configuration you will need to fill in. The APP_KEY line is the one people get wrong most often, and the comment in .env.example is explicit about the length:

# Change it to a string of exactly 32 chars or use something like `php artisan key:generate` to generate it.
APP_KEY=SomeRandomStringOf32CharsExactly

The same file shows the two settings that decide how the application looks to a new user, and they are independent of each other. DEFAULT_LANGUAGE picks the interface language, and DEFAULT_LOCALE controls number formatting, with a special value of equal meaning "follow the language":

DEFAULT_LANGUAGE=en_US
DEFAULT_LOCALE=equal

APP_ENV is the third setting worth reading before your first launch. The comment above it warns that leaving it on local keeps console commands from asking for extra confirmation, and that setting it to testing is wrong. For a machine you expose to the internet, that distinction matters more than any other line in the file.

Once the application is running and you have created a user, the first real use is to record an account and a transaction. The README does not document that workflow step by step, so treat the demo site as the reference for what the screens should look like, and the documentation for the exact fields. The important thing to verify early is that budgets, categories and tags all behave as separate axes, because that separation is what makes the reports useful later.

Where Firefly III stops: bank connections and imports

The most common wrong expectation is that Firefly III connects to your bank. The README does not claim it does. It says the application can help you track expenses and income, and that using a bunch of tools you can import data. Import is a separate concern from the ledger, and the phrasing implies tooling outside the core application.

That has practical consequences. If your bank offers a CSV or OFX export, you are in the workflow the project describes. If your bank offers nothing but a web login and a mobile app, you will be entering transactions by hand or writing your own extraction, and the project offers no documented answer for that case. The README also does not document rollback, so if an import produces a mess, the recovery path is whatever the documentation says elsewhere, not something stated in the repository root.

The second limitation is operational. This is a PHP web application with a database, and the README explicitly says it is for people who do not mind tinkering with self-hosted servers. That is not marketing modesty, it is a maintenance statement. You own upgrades, backups and the database. The releases page shows a steady stream of tagged releases and development builds, including v6.7.3 on 2026-09-18 and a development release on 2026-09-20, so the upgrade treadmill is real and continuous.

The third is scope. Firefly III tracks personal finances. It is not an accounting package with double-entry guarantees for a business, and the README never positions it that way. If you need invoicing, tax filing or multi-entity books, this is the wrong tool and the documentation will not pretend otherwise.

Firefly III vs Actual Budget and GnuCash

The comparison people search for most is against Actual Budget, and the difference is architectural rather than cosmetic. Actual Budget is built around a local-first sync model where your devices hold a copy of the data and reconcile changes. Firefly III is a server application: the database lives on the machine you run, the interface is a web page served from it, and access is through that server. If you want to read your finances on a phone without reaching your own server, the two designs lead to different answers.

Against GnuCash, the split is even cleaner. GnuCash is a desktop program with files on disk and a long history of double-entry accounting conventions. Firefly III is a web application with a database and a browser interface, and its stated emphasis is budgets, categories, tags and reports rather than accounting-standard bookkeeping. If your mental model is a ledger file you open and close, GnuCash matches it. If your mental model is a service you log into from several machines, Firefly III matches it.

The trade-off Firefly III makes in both comparisons is the same: you get a server to run and a database to back up, and in exchange you get a web interface, reports and no third party holding your records. The README states the privacy position plainly, calling the project free open source software that originates from and lives in the European Union. That is a value statement as much as a technical one, and it explains why the project does not chase cloud convenience.

Licence, releases and what upgrades cost you

Firefly III is licensed under AGPL-3.0, and the repository carries both COPYING and LICENSE at the top level. The practical consequence of the AGPL for most readers is that if you modify the application and let other people use it over a network, the licence's network clause is the part to read. Running it privately for yourself and your household is the ordinary case the project is built for. This is not legal advice, and if you plan to offer a modified Firefly III as a service, that is a question for a lawyer rather than a README.

Upgrade cost is the other ongoing expense. The release history shows two tracks: numbered releases such as v6.7.3 and dated development releases such as develop-20260920. The last push to the repository was on 2026-09-20, so the project is moving. That also means a self-managed install is never finished. You will be applying updates, and each update is a chance for a migration to touch your database.

The configuration file hints at how much of that you can automate. Several variables in .env.example note that Docker users can supply the value from a file instead, for example SITE_OWNER_FILE and APP_KEY_FILE. That pattern is the one to follow if you deploy with containers: keep secrets in files mounted into the container rather than in a committed environment file, and keep the database volume backed up before you pull a new image.

Editorial conclusion

Adopt Firefly III if you already run a server, want your ledgers on your own hardware, and accept that bank data arrives through a separate importer rather than a bank login. Do not adopt it if you want a hosted app with automatic bank sync and no maintenance. Before committing, check the self-managed and Docker installation pages at docs.firefly-iii.org, confirm your PHP and database versions against them, and decide how you will get transaction data in, because the repository ships no bank connection of its own.

Frequently asked questions

Official sources

1. firefly-iii/firefly-iii on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases