WYGIWYH: a self-hosted finance tracker built around one spending rule
A simple but powerful self-hosted finance tracker
At a glance
- What is it?
- WYGIWYH is a Django and Postgres expense tracker for people who reject budgeting apps but still want multi-currency accounts, custom transaction rules and a dollar-cost averaging log. Its opinion is baked into the data model, and that is both the reason to run it and the reason to skip it.
- Who is it for?
- Adopt WYGIWYH if you already run Docker and Postgres, you want the current month's income to cover the current month's spending, and you need multi-currency accounts plus a DCA log without a budgeting layer. Skip it if you want envelope budgeting, bank sync, or a tool your non-technical household members can administer without touching a compose file.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The spreadsheet problem WYGIWYH was written to replace
The README gives an origin story rather than a feature list: the author tracked money in a spreadsheet for years, and it stopped working once multiple currencies, accounts and investments entered the picture. The stated requirements are narrow and specific. Multi-currency income and expenses. No budgeting constraints. A web app, ideally usable on a phone. An API for automation. Custom transaction rules for things like credit card billing cycles. The project name expands to What You Get Is What You Have, and the operating principle is quoted in the README: use what you earn this month for this month, with savings tracked but treated as untouchable for future months. That is the audience. Someone who finds envelope budgeting and category limits annoying, holds money in more than one currency, and is willing to run a container to avoid a spreadsheet. Anyone whose mental model of personal finance is built on monthly category budgets will find the core assumption fights them, because the tool treats this month's income as the ceiling and savings as off limits by design.
What the Django and Postgres stack implies about the data model
WYGIWYH is a Python project, and the setup instructions confirm it is a Django application: the first account is created with python manage.py createsuperuser, either inside the running container or from the Unraid console. The Unraid section states that you must provision your own Postgres database at version 15 or up, which tells you the persistence layer is PostgreSQL rather than SQLite and that the application does not ship a database for you. The feature list maps onto that foundation in a way that is worth reading carefully. Accounts hold money and assets across banks, wallets and investments. Transactions record income and expenses against those accounts. Currencies are first class, and the README says you can create your own for crypto or rewards points, which means currency is not a fixed enum but a record you define. Rules modify transactions automatically, which is the mechanism behind the credit card billing cycle requirement. The DCA tracker is described as built in and aimed at recurring investments in crypto and stocks. Because every one of these is a database table behind a Django admin, the practical consequence is that the app expects you to think in terms of accounts, transactions, currencies and rules rather than in terms of a monthly plan.
Rules, custom currencies and the API as the automation surface
The README lists automation as a first class concern and backs it with three separate mechanisms. Rules adjust transactions automatically, which is how a credit card purchase made on the 28th can be attributed to the correct billing period without manual editing. Custom currencies let you define units that are not national currencies, so crypto holdings and rewards points live in the same ledger as your bank balance. The API is described as a way to synchronize transactions with other services, and the demo instance deliberately disables it along with rules, automatic exchange rates and import/export, which is a useful signal about which parts of the product are considered the heavy machinery. One caveat the README states plainly: features land on main only when ready, and running the latest code means building from source or using the :nightly tag, with the warning that nightly can contain undocumented breaking changes. If you depend on rules or the API, that warning matters more than it does for someone who only enters transactions by hand.
Getting it running with docker compose and the .env file
The documented path assumes Docker with docker-compose. You create a directory, create a docker-compose.yml, and the README directs you to paste the contents of docker-compose.prod.yml from the repository and edit it to suit. Then you create a .env file from .env.example and edit that. The application starts with docker compose up -d. The first admin account is created with docker compose exec -it web python manage.py createsuperuser, unless you set the ADMIN_EMAIL and ADMIN_PASSWORD environment variables, in which case the README says the manual step is not required. For local use the instructions are concrete: remove URL from the env file, set HTTPS_ENABLED to false, and leave DJANGO_ALLOWED_HOSTS at its default of localhost 127.0.0.1 [::1], after which the app is reachable at localhost:OUTBOUND_PORT. Two footnotes are easy to miss and will cost you an afternoon if you do. If you run behind Tailscale or a similar service, add the machine's given IP to DJANGO_ALLOWED_HOSTS. If you use any IP that is not localhost, add it to DJANGO_ALLOWED_HOSTS without the http:// prefix. On Unraid the process differs: install from the store, provision your own Postgres 15 or newer, open the container console from the Docker page and run python manage.py createsuperuser there. The demo at wygiwyh-demo.herculino.com uses demo@demo.com with password wygiwyhdemo, wipes any data you add within 24 hours, and disables most automation, so it is a UI preview rather than a test of the API or rules.
The nightly tag and the upgrade path you are actually signing up for
Release cadence is visible in the tags: 0.23.1 on 2026-09-06, 0.23.0 on 2026-08-16, 0.22.1 on 2026-07-10. That is a project moving in small increments roughly monthly, which is healthy for a self-hosted tool but also means you should pin a version rather than track a floating tag. The README's own warning is the strongest maintenance signal in the repository: features are added to main only when ready, and if you want the latest version you must build from source or use the :nightly tag, and there can be undocumented breaking changes. The Dockerfiles for building are in docker/prod. For a finance database, that is a real cost. You are running Postgres yourself, so backups are your responsibility, and the README does not describe a migration or rollback procedure. The practical reading is that the release tags are the supported surface and nightly is for people who can read a Django migration and recover from a bad one. On licensing, the repository is AGPL-3.0. If you run it for yourself, the network copyleft clause is unlikely to reach you. If you modify it and expose it to users over a network, the AGPL's source-availability condition is the part to read with your own counsel, because it is materially different from a permissive licence and this is not legal advice.
Where WYGIWYH is the wrong tool
The README is honest about the opinion, and the opinion is the limitation. WYGIWYH is explicitly not a budgeting app, and the author states a dislike of budgeting constraints. If your goal is to assign every unit of currency a job before the month starts, or to see category limits and progress bars, this tool will not give you that, and the no-budget stance is not a missing feature that a plugin will add. It is the design. The second limitation is operational. There is no bank sync described anywhere in the material. Transactions arrive through manual entry or through the API, and the API is something you have to wire up to whatever produces your data. That is a meaningful amount of work compared with a hosted app that connects to your bank, and it is work that never really ends, because bank formats change. The third is the deployment surface. You need Docker, a compose file, an .env file, and a Postgres 15 or newer instance that you provision and maintain. The Unraid path still requires you to bring your own database. Anyone who does not want to own a Postgres instance should not start here.
How it differs from Firefly III and plain spreadsheets
The obvious comparison in the self-hosted finance space is Firefly III, another self-hosted, web-based personal finance manager built on a PHP stack with its own database requirements. The difference in approach is the budgeting model. Firefly III is organized around budgets, categories and reports that assume you want to plan and constrain spending, which is precisely the framing WYGIWYH rejects. WYGIWYH replaces the budget with a rule about time: this month's income funds this month, and savings are walled off. It also treats the dollar-cost averaging tracker as a built-in feature rather than something you assemble from tags and reports, which matters if recurring crypto or stock purchases are a regular part of your ledger. Against a spreadsheet, the trade is the same one every self-hosted app makes. You give up the ability to reshape the model in a cell, and you get rules, multi-currency handling and an API that a spreadsheet only approximates with scripts. If your spreadsheet already has those and you are comfortable maintaining it, the case for migrating is weaker than the README's origin story suggests.
Editorial conclusion
Adopt WYGIWYH if you already run Docker and Postgres, you want the current month's income to cover the current month's spending, and you need multi-currency accounts plus a DCA log without a budgeting layer. Skip it if you want envelope budgeting, bank sync, or a tool your non-technical household members can administer without touching a compose file. Before committing, verify that your Postgres is version 15 or newer, that the ADMIN_EMAIL and ADMIN_PASSWORD variables create the first account the way you expect, and that your chosen image tag is a release tag rather than nightly, because the README states nightly can contain undocumented breaking changes.
Community notes