Firefly III

Last reviewed Aug 26, 2026 · 784 words

Firefly III is a ledger with budgets attached, and Actual is a budget with a ledger attached; pick by which half you will open every day. If you want to know where every euro went across 6 accounts, 3 currencies, a mortgage, and a shared credit card, and you want reports you could show an accountant, Firefly is the more capable tool by a distance. If you want the envelope method and a fast "can I afford this" answer, Actual Budget gets there in a fraction of the clicks. Firefly has been in development since 2016, has 24,415 stars, is AGPL-3.0 PHP, and runs in 512 MB; the cost is a learning curve the catalogue politely calls "steeper".

The model is accounts, not categories

Every transaction in Firefly moves money between two accounts: a withdrawal goes from an asset account to an expense account, a deposit from a revenue account to an asset, a transfer between two assets. Expense accounts are usually shops ("Lidl"), not categories ("Groceries"); categories, budgets, tags, and bills are labels layered on top. This is where newcomers stall, because the first week feels like bookkeeping rather than budgeting. It pays off the moment you ask a question Actual cannot answer cleanly, such as "how much did I spend at this one shop across two cards and a joint account", or when you need a net worth figure that includes a liability account amortising correctly.

Two containers, and the importer is the second one

The core image is fireflyiii/core on port 8080; give it a database (MariaDB or Postgres for anything you care about, SQLite for a trial) and an APP_KEY that is exactly 32 characters, because a wrong length fails at boot with an unhelpful message. Importing is a separate application, fireflyiii/data-importer, that talks to Firefly through its API with a personal access token:

services:
  firefly:
    image: fireflyiii/core:latest
    environment:
      - APP_KEY=CHANGEME_to_exactly_32_characters
      - DB_CONNECTION=pgsql
      - DB_HOST=db
      - DB_DATABASE=firefly
      - DB_USERNAME=firefly
      - DB_PASSWORD=change-this
    volumes:
      - ./upload:/var/www/html/storage/upload
    ports: ["8080:8080"]
  importer:
    image: fireflyiii/data-importer:latest
    environment:
      - FIREFLY_III_URL=http://firefly:8080
    ports: ["8081:8080"]

Keeping the importer separate looks like bureaucracy until you realise it is the component that talks to banks, and so the one you can leave switched off.

Bank sync is a country question

The importer takes CSV and camt.053 files from any bank, and live connections through GoCardless Bank Account Data (free for personal use, covers most European banks under PSD2) and Salt Edge. For the US there is no first-party connector; people bridge through third-party aggregators or settle for downloading CSVs monthly. Whatever the source, the importer's configuration file remembers your column mapping and account matching, so the second import is a two-click job, and running the importer on a schedule against a GoCardless connection gives you something close to Mint's automatic feed without handing anyone your bank password. The finance category notes which tools have this for which regions.

Rules do the categorising

The rules engine is the feature that makes the fear of manual entry overblown. A rule is a trigger ("description contains SPOTIFY", "amount more than 500", "destination account is Landlord") and one or more actions (set category, set budget, add tag, rename description, link to a bill). Rules run on import and can be replayed over history, so after a month of tuning most transactions arrive categorised and you review exceptions. Combined with bills (recurring expected charges that mark themselves paid when a matching transaction appears) and piggy banks (savings targets inside an asset account), it covers the YNAB feature list people worry about losing; the YNAB alternatives page goes through the mapping.

Backups are two things

Back up the database and the upload volume, which holds attachments. Firefly also has a full JSON export in the UI and the API can pull everything, but a database dump is what you restore from. Recurring transactions and rules live in the database too, so a restore is complete. Updates are frequent and safe, migrations run on boot, and the changelog is worth 2 minutes.

What I'd do

Postgres, the two-container layout above, behind a reverse proxy with the importer exposed only on the LAN. Spend the first evening creating asset accounts and 20 rules rather than entering history, then import 3 months of CSVs and watch the rules do the work. If after 2 weeks you find you only ever open the budget page, move to Actual and keep the Firefly database as an archive; if you keep opening the reports, you have found your tool.