monetr: a self-hosted budget that plans around the bills you already have

A budget where the recurring bills come first

monetr is a budgeting application focused on planning for recurring expenses, and the project description puts the goal in plain terms: while making it absolutely clear how much you have left over to budget or use for other unplanned spending.

That is a different starting point from most budgeting tools. The recurring commitments, the rent, the subscriptions, the loan payments, are treated as the fixed frame, and the question the app answers is what is left. The lineage is stated too: it is based off of the now defunct Simple, with the project's website linked through an archive snapshot of the original service.

It is also completely free to self-host, and the install documentation lives on the project site rather than in a package registry, which is the norm for an application with a database and a web interface rather than a library.

The audience that fits is specific. A household with a steady income and a lot of subscriptions, or a freelancer with irregular income and fixed costs, is the case the design serves. A person who wants a spending tracker with a nice chart on their phone is looking for a different product, and nothing in the description suggests monetr is that.

The compose stack is Postgres, Valkey and one container

The repository ships a docker-compose.yaml that is the fastest way to see the shape of the system. The database service is Postgres 17, with a volume for the data directory and a healthcheck that runs pg_isready:

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: superSecretPasswordPleaseChangeMe
      POSTGRES_USER: postgres
      POSTGRES_DB: monetr
    volumes:
      - postgresData:/var/lib/postgresql/data
    healthcheck:
      test: [ "CMD", "pg_isready", "-U", "postgres" ]

The cache and queue service is Valkey 9 rather than Redis, with a valkey-cli ping healthcheck, and the application container is the published image, tagged with the release version and annotated for the release tooling:

  monetr:
    image: ghcr.io/monetr/monetr:1.19.0 # x-release-please-version
    healthcheck:
      test: [ "CMD", "/usr/bin/monetr", "status" ]
    restart: unless-stopped
    command:
      - serve
      # Setup the database and perform migrations.
      - --migrate
      # Since certificates will not have been created, make some.
      - --generate-certificates
    ports:
      - "4000:4000"

Three things in that command line are worth reading twice. The application applies its own migrations at startup, so there is no separate migration step to schedule. It generates its own certificates if they do not exist yet, and stores them with its configuration in the monetrData volume mounted at /etc/monetr. And the healthcheck runs the monetr binary's own status command rather than probing an HTTP path, which means the container is only reported healthy when the application itself says it is.

Sign-ups are open by default, and the compose file says so

The environment section of the compose file contains a comment that is worth reading before you point this at a public address.

MONETR_ALLOW_SIGN_UP defaults to true, and the comment explains the risk directly: after creating your own user, it is recommended to disable sign ups if your monetr instance is exposed to the public internet, otherwise strangers may be able to use your instance themselves.

That is a self-hosted application with multi-user sign-in enabled by default, and the file tells you the fix rather than leaving it to be discovered. The same block carries the Postgres credentials as environment variables, with the password that is the literal string superSecretPasswordPleaseChangeMe, which is a placeholder and not a secret.

This is the kind of detail that decides whether a self-hosted deployment is safe, and it is a reminder that the compose file is a development convenience. A real deployment needs a changed password, sign ups disabled after the first account, and certificates of your own, even though the application will generate working ones for you.

What monetr talks to: Plaid, Stripe, AWS and a secret store

The go.mod file is the shortest description of what the application actually does, because the dependency list is where the integrations live.

The banking side is Plaid, with plaid-go/v48 in the dependency list, and the contributing section confirms it in plain terms: to run monetr locally you need sandbox credentials for Plaid, obtained from the Plaid dashboard, and once you have a Client ID and a Client Secret you can start a local environment. The account syncing is therefore not optional plumbing, it is the product, and it is the part that needs a provider relationship.

Payments run through Stripe with stripe-go/v81. Storage and keys run on AWS, with the aws-sdk-go-v2 modules for KMS and S3. Secrets can come from HashiCorp Vault or OpenBoo, with vault/api and openbao/api in the list, and the token stack includes PASETO, JWT v5, a JWKS set and keyfunc.

The rest is the ordinary machinery of a Go service: the Echo web framework, uptrace/bun with the Postgres dialect and driver, the redis client, Prometheus metrics, a cron library, an rrule library for recurrence rules, cobra and viper for the command line and configuration, Sentry for error reporting, and a test stack with testify, httpexpect, miniredis and gofakeit.

The recurrence library is worth a note, because recurring expenses are the centre of the product and a monthly bill on the 31st is not the same as a monthly bill on the 28th.

Building monetr is a CMake project that pnpm drives

The build is unusual for a Go server, and understanding it explains the shape of the repository.

The root package.json is the entry point, and every script shells out to CMake. The monetr and release scripts run cmake --preset default and then build the build.monetr target, the test script configures the testing preset and runs ctest with --no-tests=error, and the develop script builds the development.monetr.up target while develop-docs builds development.documentation.up. There is a shutdown script that brings the development stack down, and a clean script that removes the build directory.

So the CTest suite is what runs the Go tests, and the interface is built with Node 24 and pnpm, with TypeScript 7.0.2 and biome for formatting and linting, and pnpm 12.11.2 pinned as the package manager.

The two commands the README gives are short:

make develop

which sets up everything needed to work on monetr, and make clean to tear it all down. The tree explains the rest: a server/ directory, an interface/ directory, emails/ for the transactional mail, docs/ for the documentation site that the develop-docs target serves, a Dockerfile, compose/ for the front end image, and air.toml, which is the live reload configuration for the Go service. The versions live in version.txt, and the release process is handled by release-please with a manifest and a config at the root, while renovate.json5 keeps the dependencies current.

The Go module itself declares Go 1.27.1, and the Dockerfile builds from a golang 1.27.1 trixie image and a node 24.21.0 trixie slim image, with pinned base image digests and a comment explaining why Node comes from the official image rather than apt.

The licence is the thing to read before you deploy

The README's licence section is thin. There is a FOSSA badge, and the licence itself is not the standard MIT text, the licence field on the repository is recorded as a custom licence that GitHub cannot classify, and the licence file in the repository is LICENSE.md. A SECURITY.md and a CODE_OF_CONDUCT.md are present, and there is a Discord community linked from the header.

For an application that handles bank account connections and a family budget, the terms are worth reading carefully, and this article cannot tell you what they say. The practical point is narrow and important: this is not a permissive licence you can assume, and the FOSSA badge in the header is a licence analysis service rather than a grant of rights.

On maintenance, the signals are healthy. The repository is not archived, the last push was on 2026-10-19, and the release history shows v1.19.0 on 2026-10-14, v1.18.1 on 2026-10-09 and v1.18.0 on 2026-10-07. That is a frequent release cadence for an application that has to keep up with banking APIs, and it is also the reason the compose file pins the image tag to a specific version instead of a floating tag.

The alternative, and the trade it makes for you

The realistic alternative to monetr is not another self-hosted budget, it is a spreadsheet or the budgeting tool your bank already gives you, and the difference in approach is where the decision sits.

A spreadsheet approach keeps the recurring expenses as a table of rows you maintain, and the answer to what is left over is a formula. You have no server to run, no database to back up, no bank credentials to hand to a third party, and no patch to apply when a dependency has a vulnerability. What you give up is the sync, the automatic detection of a new subscription, the rule engine, and the fact that the number is always current.

monetr takes the opposite side of that trade. It connects to your accounts through Plaid, keeps the balances and transactions current, evaluates the recurring expenses against them, and gives you a live figure. The cost of that is the self-hosting obligation and the trust boundary with a banking data provider, which is not a trivial thing to hand to a hobby project.

There is a middle option, which is to use monetr only as a planning tool and keep the accounts connected to a provider you already trust, rather than the one in the compose file. The application does not force a single Plaid configuration, and the sandbox credentials in the contributing section exist so that a local instance never touches a real account.

Editorial conclusion

Adopt monetr if you want a self-hosted budget that treats recurring expenses as the starting point rather than the afterthought, and you are comfortable running Postgres, Valkey and a container that talks to a banking data provider. Do not adopt it for a household that will not run its own server, and read LICENSE.md before you do, because the licence is a custom one rather than a standard open source licence. Verify first that the MONETR_ALLOW_SIGN_UP flag is turned off on any instance reachable from the internet, that the Postgres password in the compose file is changed, and that the Plaid credentials you obtain are sandbox credentials rather than live ones.

Frequently asked questions

Official sources

1. Issues
2. monetr/monetr on GitHub
3. Project website
4. README
5. Releases