Privacy Policy
- boodget is free, source-available software you run yourself. There is no boodget-operated service, website, or database that your financial data ever passes through.
- The people who write boodget's code never see, receive, or have access to your data. Everything you enter lives in the database of the specific instance you (or whoever installed it for you) are running.
- boodget itself doesn't add analytics, tracking, or telemetry, and doesn't phone home.
- A couple of features are opt-in and, only if you turn them on and configure them yourself, send data to a third party you choose (e.g. the Anthropic API for the AI Advisor, your own Paperless instance, or a browser push service). Off by default, and entirely under your control.
- Whoever installs and operates a boodget instance is responsible for securing it and for their own compliance obligations (backups, access control, data protection law, etc.) — not the boodget project.
1. What this document covers
boodget ("the software," "the project") is source-available, self-hosted personal finance software published at github.com/mribeiro/boodget. This Privacy Policy explains how the software itself handles data when it runs, and clarifies what the boodget project does and does not have visibility into.
This is not the privacy policy of a hosted product or online service operated by the boodget maintainers, because no such service exists. boodget is distributed as source code (and as a Docker image built from that source) for individuals and organizations to install and run on infrastructure of their own choosing — a home server, a personal VPS, a company's internal servers, or anywhere else. If you are using a boodget instance that someone else installed and manages (an employer, a family member, a friend), that operator is the one responsible for how your data is handled, backed up, and secured — refer to whatever privacy notice they give you, if any, in addition to this document.
2. Data controller
For any given boodget instance, the person or organization who deployed and operates that instance is the data controller — not the boodget project or its maintainers. The maintainers publish the source code but do not operate, monitor, or have network or database access to any installation they did not personally set up for their own use.
If you are installing boodget for yourself, you are both the controller and the data subject — you're simply keeping your own financial records on your own infrastructure. If you are installing boodget for others (e.g. a small business making it available to employees, or a developer offering it as a service to clients), you take on the legal responsibilities of a data controller/processor under whatever laws apply to you (such as GDPR, CCPA, or similar), and you should adapt this document — or write your own — to reflect your actual practices before offering it to your users.
3. What data boodget can store
Depending on how a given instance is used, the application's own database can hold:
- Account credentials (a username and a bcrypt-hashed password, or an OIDC identity if SSO is configured) and an optional profile picture.
- Financial data you choose to enter: account balances and monthly snapshots, expense and income templates, budget cycles, goals, loans, subscriptions, car expenses, and any free-text notes or "additional context" you write.
- Push notification subscription endpoints, if you opt into browser push notifications.
- Session cookies used to keep you signed in (httpOnly, 72-hour expiry) — no third-party tracking cookies are set.
All of this is stored in the SQLite database file of the specific instance you're using, at the location its operator configured. Nothing is synced to, mirrored to, or backed up by the boodget project — if the operator of your instance doesn't back it up, no one else has a copy.
4. Data boodget sends to third parties (only if you enable it)
By default, a boodget instance makes no outbound calls to third-party services about your financial data. A few optional, per-dossier features are the exception, and each only activates if explicitly configured:
- AI Advisor. If enabled for a dossier and an Anthropic API key is configured (either the operator's own environment-level key, or a key you enter yourself in Dossier Settings), a trimmed summary of that dossier's data is sent to Anthropic's Claude API to generate an analysis or answer a chat question. This only happens when you click "Analyze" or send a chat message, and only for dossiers where the feature is turned on. Anthropic's own privacy policy and API terms govern how they handle that request. You can disable this feature entirely per dossier at any time.
- Paperless integration. If you configure a Paperless-ngx URL and token in Dossier Settings, boodget will query your own Paperless instance to match receipts to expenses. This is a connection you configure to infrastructure you already control — no boodget-operated intermediary is involved.
- Push notifications. If you opt in, boodget uses the standard Web Push protocol (VAPID) to deliver notifications through your browser vendor's push service (e.g. Google's or Mozilla's), the same mechanism any website uses for browser push — this is inherent to how web push works, not a boodget-specific data share.
- Single sign-on (OIDC). If the operator has configured OIDC, authentication happens against the identity provider they've set up; boodget doesn't introduce a new data flow beyond that provider.
Outside of these opt-in cases, boodget does not transmit your data anywhere else. There is no analytics SDK, crash reporter, or telemetry beacon built into the application.
5. Data export and deletion
Every dossier can be exported to a JSON file at any time (excluding secrets like Paperless tokens and AI API keys, which are never exported) and deleted outright by whoever has access to it. Because boodget is self-hosted, there is no separate "request my data" process to go through with the project — you or your instance's operator already have direct access to the underlying database.
6. Security
boodget implements standard application-level protections (hashed passwords, session-based auth, rate limiting on login, HTTPS-friendly session cookies). However, the security of any given instance — the server it runs on, the network it's exposed to, TLS/HTTPS termination, firewall rules, backup encryption, and keeping the software up to date — is entirely the responsibility of whoever deploys it. The project provides the software "as is" (see the Terms and Conditions) and cannot guarantee the security of an installation it does not operate.
7. Children's privacy
boodget is a general-purpose personal finance tool and is not directed at children. It has no age-verification mechanism because it is self-hosted software, not a public service — it's the installing operator's responsibility to control who has access to their instance.
8. Changes to this policy
This document describes the software's default behavior as of the "Last updated" date above. Future versions of boodget may change what data is stored or which optional integrations exist; such changes will be reflected in this file in the project's repository. Since each instance runs whatever version its operator has deployed, an instance may not reflect the latest version of this policy until it is updated.
9. Contact
boodget is a source-available project, not a company. Questions about the software itself can be raised via GitHub Issues. Questions about how a specific instance handles your data should go to that instance's operator, not the project maintainers.