firefly-pico is a mobile first front end for Firefly III, not a fork of it

A companion, not a replacement

Firefly-Pico is described as a mobile optimised, highly responsive web application built as a companion to Firefly III, and the word companion does a lot of work in that sentence. Firefly III is the application that owns your financial data, the accounts, the transactions, the tags, the rules and the reports, and Firefly-Pico is a different way of talking to it. The repository makes that structure visible, with a `back/` directory for the Laravel side that handles the API and the authentication, and a `front/` directory for the Nuxt side that renders the interface. The stated goals are speed and ease of use, so that you can log an expense, organise tags and keep track of your finances while out, and the emphasis throughout is on keeping control of the data, which in practice means the Firefly III instance is one you host. The project is free and open source, and the documentation is published as a static site with a separate installation page for Docker.

The Assistant is the feature that changes the daily workflow

The headline feature is the Assistant, described in the feature list as making the recording of an expense feel like magic, and the repository includes a short animated demonstration of it. The reason it matters is that the bottleneck in personal finance software is not the report, it is the three seconds it takes to enter a coffee, and anything that shortens the entry path changes whether people keep using the tool at all. The rest of the feature list is the supporting cast for that goal. There are templates that auto-complete the fields of the transaction form, so a recurring payment is a saved shape rather than a retyped one. There is a dashboard for keeping an eye on what matters, and the interface is described as clean and minimalistic with subtle animations and a dark theme, which is a small thing that matters a lot for an app you open in a dark bar at night. The list also mentions a lot of tweaks and settings, which is the sort of phrase that means the settings screen has grown over time.

Three ways it extends the Firefly data model

Beyond the entry flow, the project extends Firefly III's own data in three specific ways, and these are the parts that make it more than a skin. The first is icons for all resources, which the documentation describes as expanding Firefly data with icons for every resource, so accounts, tags, categories and the rest can carry a visual identity rather than being identified by text alone. The second is sub-tags, an option on tags themselves, so a tag like travel can be split into flights and trains without inventing a flat list of a hundred tags. The third is the templates already mentioned. Taken together, they suggest a project that treats Firefly III as the system of record and adds the ergonomics a personal finance tool needs, which is a coherent division of labour, and it is also why the project describes the result as a companion rather than a competitor. The practical consequence for an adopter is that these features live in the Pico database and configuration rather than in Firefly III, so a migration back to the stock interface loses the presentation but not the data.

Four compose files for four deployment shapes

The repository ships four Compose files, and the names describe the deployment options more clearly than any documentation would. There is `docker-compose.pico.yml`, the plain application on its own, and `docker-compose.pico-simple.yml`, a simplified variant of the same. Then there is `docker-compose.pico+firefly.yml`, which adds a Firefly III instance alongside, and `docker-compose.pico+firefly+importer.yml`, which adds an importer on top of that. So the choice is whether you already run Firefly III and only want the new interface, or you want the stack to bring one up, and the importer variant exists for people moving existing data across. The images are published to Docker Hub under `cioraneanu/firefly-pico`, and the README carries the version badge for the image and a pull count, both pointing at the tags page. The presence of a separate documentation site with a Docker installation page tells you the project expects people to run this as a service on a small server or a home NAS, which is the same audience Firefly III itself attracts.

Alpine, PHP 8.2, nginx, redis and supervisor in one image

The Dockerfile is worth reading because it shows how the two halves are assembled into one container. The base image is Alpine 3.22, and the package list is the runtime inventory of the application: nginx as the web server, nodejs and npm for the front end build, redis, supervisor as the process manager, and a long set of PHP 8.2 packages covering the extensions the Laravel side needs, from the pdo drivers for MySQL, Postgres and SQLite through the XML, mbstring, zip and tokenizer extensions, plus pcntl and posix. The PHP binary is then symlinked to the standard name so the scripts do not have to know about the versioned package. A separate build stage pulls the Composer binary from the `composer:2.2` image. The result is a single image with two application halves, which is a deliberate choice for a self hosted personal tool, since one container is one thing to update and one thing to back up, at the cost of not being able to scale the front end independently of the back end.

The build bakes the version into both halves

The build stages in the Dockerfile are conventional and careful, and one detail matters if you build your own images. The backend is installed with Composer in two steps, first the dependencies with the scripts and the autoloader disabled, then the source with the autoloader dumped in optimised mode, and the example environment file is moved into place before `php artisan key:generate` runs, so the application key exists at build time. Then the version is written in. The build takes an `APP_VERSION` argument, echoes it into a `VERSION` file in the application root, and creates a tar backup of the whole tree owned by the `www-data` user, which is the mechanism behind the restore or rollback path. The front end is built in the same image with `npm ci --ignore-scripts` and the version passed into the Nuxt build through the `NUXT_PUBLIC_VERSION` variable. The result is that both halves of the application agree on the version string, which is the sort of consistency that shows up as a support question when it is missing and saves one when it is there.

AGPL-3.0, and the state of the project

The licence is the AGPL-3.0, and for a self hosted web application that is a decision with teeth. The network use clause of that licence is what matters here, because a web application is used over a network by definition, so a modified version offered that way carries the copyleft obligation, unlike a desktop tool that is merely distributed. If you intend to run Firefly-Pico exactly as published on infrastructure you control, the licence is not a practical obstacle, and if you intend to change it and keep the result to yourself, the position is more delicate and worth a legal opinion rather than a paragraph in a review. On the state of the project, the releases are 1.12.0 on 2026-07-31, 1.11.0 on 2026-06-20 and 1.10.0 on 2026-02-06, so it is shipping regularly, and the last push to the repository was on 2026-10-14. The tree also carries an `AGENTS.md` and a `.claude/` directory, which tells you the project keeps agent instructions in the repository, and a `docs/` directory that holds the images used in the readme and the documentation site.

Editorial conclusion

firefly-pico suits a self hosting Firefly III user who finds the stock interface slow on a phone, since the whole point of the project is a form that takes seconds to fill in on a small screen with a PWA install and dark theme. It is a poor fit if you want a replacement for Firefly III, because the data model, the rules and the reports still live in Firefly III and this is a client for it, and it is a poor fit if you plan to modify the source and keep the changes private, since the AGPL-3.0 licence attaches network use obligations to modified versions. Before you deploy it, check three things: which of the four compose files matches your setup, whether you already run Firefly III or whether you want the plus Firefly variant that starts one for you, and the version you pin, with 1.12.0 published on 2026-07-31 and the last push to the repository on 2026-10-14.

Frequently asked questions

Official sources

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