Actual Budget: a local-first finance app you can self-host or run offline

What Actual Budget solves, and who it is actually for

Most budgeting apps keep your transaction history on someone else's server and charge a subscription for access to it. Actual Budget takes the opposite position. The repository describes it as "a local-first personal finance tool", and the package.json description calls it "A local-first personal finance system". That phrase does real work: the app is designed so the data lives with you, and synchronization exists to move changes between your own devices rather than to park them in a vendor account.

The intended user is someone who already understands envelope budgeting or is willing to learn it. The README points new users at an Envelope budgeting page and a Starting Fresh guide, and it points people coming from other apps at a Migration guide. That is the shape of the audience: people who want a budget they own, and who are prepared to read a few pages of documentation before entering numbers.

The repository is not archived and the last push was on 2026-09-20, so the codebase is moving. Version numbers follow a calendar-ish scheme, with v26.9.0 released on 2026-09-01. The project is written in TypeScript and licensed MIT, which matters if you plan to fork it or embed parts of it.

How the packages and the sync server fit together

The README splits the app into three packages: loot-core, described as "The core application that runs on any platform"; desktop-client, the desktop UI; and desktop-electron, the desktop app. The repository layout shows a packages/ directory plus separate Dockerfile and sync-server.Dockerfile files at the top level, which is consistent with a core that can be embedded in a browser build, an Electron shell or a server process.

The synchronization element is the part worth understanding before you install anything. The README says the app "has a synchronization element so that all your changes can move between devices without any heavy lifting". In practice that means you can run the app purely locally, or you can run a sync server and point multiple clients at it. The package.json exposes scripts named start:server and start:server-monitor, which run the @actual-app/sync-server workspace, so the sync server is a first-class part of the repository rather than an afterthought.

The development setup is split too. There is a start:browser script that runs the browser frontend alongside a plugins service, and a start:desktop script that rebuilds Electron and the plugins service before launching the desktop pieces. If you only want to use the app, none of this matters. If you want to build from source, it tells you the project expects a multi-process dev environment rather than a single command.

Installing Actual Budget: four documented paths

The README lists four ways to deploy Actual. One-click deployment via PikaPods, which it prices at roughly $2.00 per month and recommends for non-technical users. Managed hosting via Fly.io, at roughly $1.50 per month. Self-hosting with a Docker image. And local-only apps, downloadable for Windows, Mac and Linux, which run on your own device.

The README does not print the Docker command itself; it links to installation instructions in the community documentation. So the honest first step is to pick a path from the README and follow the linked page rather than copying a command from the repository root.

If you want to run the development container from the repository, the docker-compose.yml at the top level defines a single service. Note the comment at the top of that file: it builds the development container, not a production deployment.

services:
  actual-development:
    build: .
    image: actual-development
    environment:
      - HTTPS
    ports:
      - '3001:3001'
    volumes:
      - '.:/app'
    restart: 'no'

That service maps port 3001 and mounts the repository into /app. The Dockerfile it builds from uses node:24-bookworm, installs openssl, and sets the container command to sh ./bin/docker-start. Those are development defaults, and the file header says so explicitly.

For a first real use, the fastest path for a non-technical user is the desktop download, and the fastest path for someone with a server is the Docker image described in the docs. Once the app is open, the README's own next step is to read the Envelope budgeting page, then either the Starting Fresh guide or the Migration guide depending on whether you are starting from nothing or moving from another app.

Where Actual Budget is the wrong tool

The sync server is the main operational cost, and the README does not pretend otherwise. If you self-host, you are now responsible for a service that holds your financial history. The README does not document backup, restore or rollback procedures for that server, and it does not document an upgrade procedure for a self-hosted instance. Those gaps are in the README, not in the product necessarily, but a reader deciding whether to adopt should treat them as unanswered until they check the linked documentation.

Local-first also means there is no vendor to call. If your sync server is misconfigured, the README gives you a Discord community and a documentation site, not a support contract. For a household that wants a budgeting app and nothing else, that is a real mismatch.

The Dockerfile in the repository is explicitly labelled a development container, and the compose file says it "creates and stands up the development docker container". Anyone who copies the top-level docker-compose.yml expecting a hardened production deployment will get a container that mounts the whole working directory and restarts never. Use the documented Docker install path instead.

Finally, the README is thin on the sync protocol itself. It says synchronization exists; it does not describe conflict resolution or what happens when two devices edit the same transaction offline. If your workflow involves multiple people editing the same budget from different places, that is the question to answer before adopting, and the README will not answer it for you.

Actual Budget compared with a hosted budgeting service

The obvious alternative is a hosted subscription budgeting service, where the vendor runs the database and you log in through a browser. The difference is not just where the bytes sit. With a hosted service, upgrades, backups and mobile sync are the vendor's problem, and the trade is that you cannot run the app without their servers and you generally cannot read or fork the code.

Actual Budget inverts each of those. The code is MIT licensed and lives in a public repository, the README offers a Docker image and downloadable desktop builds, and the sync server is a component you can run yourself. The cost is that the operational work moves to you, and the README's own recommendation for non-technical users is to pay PikaPods about $2.00 per month rather than self-host. That recommendation is telling: the project knows that self-hosting is the harder path.

A second comparison point is the desktop-only camp of personal finance apps that never sync at all. Actual sits between the two. It can be used as a local-only desktop app, and it can also be given a sync server so several devices share one budget. That middle position is the actual product decision here, and it is why the README spends its installation section on deployment choices rather than features.

Licence, maintenance and the cost of keeping it running

The licence is MIT, declared in package.json and present as LICENSE.txt at the repository root. In practical terms that is a permissive licence: you can read the source, modify it and redistribute it, subject to the licence text itself. This article is not legal advice, and anyone planning to redistribute a modified build should read LICENSE.txt rather than a summary of it.

On maintenance, the facts are concrete. The repository is not archived. The last push was on 2026-09-20. The most recent release listed is v26.9.0 on 2026-09-01, preceded by v26.8.1 on 2026-08-07 and v26.8.0 on 2026-08-02. That is a steady release cadence over the two months before the last push.

Upgrade cost depends entirely on which of the four deployment paths you chose. A desktop download is replaced by downloading a newer build. A managed host handles the upgrade for you. A self-hosted Docker instance is yours to update, and the README does not spell out the procedure, so budget time for reading the Docker install documentation before you commit. The repository also carries an upcoming-release-notes/ directory and a CONTRIBUTING.md, which suggests release notes are written before releases ship rather than reconstructed afterwards.

Editorial conclusion

Adopt Actual Budget if you want your budget data on hardware you control and you are comfortable with Docker, a sync server, or a plain desktop download; the MIT licence and the four documented deployment paths make it easy to try before committing. Do not adopt it if you need a vendor-held web account with no server to run, or if you expect the README to walk you through rollback and upgrade procedures, because it does not. Verify first which deployment path matches your skill level, then read the envelope budgeting and migration pages in the community documentation before you move years of transactions into it.

Frequently asked questions

Official sources

1. actualbudget/actual on GitHub
2. License: MIT
3. Project website
4. README
5. Releases