57bcdf89c9
> Sentry's MCP token is still expired, so this came from the production
DB again.
## The bug
`EnableBankingSyncer::sync` loops a connection's accounts doing
transactions-then-balances. The transaction call was wrapped, but only
for `InaccessibleBankAccountException` and
`WrongTransactionsPeriodException`. A
`TransientBankingProviderException` — what EnableBanking's HTTP 400
`{"error":"ASPSP_ERROR"}` becomes, i.e. "the bank's connector failed" —
propagated out and abandoned the loop, so **every account behind the
failing one was skipped, along with its balance, cycle after cycle**.
Verified on a CaixaBank connection with three accounts:
| account | transactions | balance days | last balance |
|---|---|---|---|
| 1 | 618 | 231 | 2026-07-19 |
| 2 | 0 | 13 | **2026-06-12** |
| 3 | 0 | 13 | **2026-06-12** |
2026-06-12 is the connection's `last_synced_at` — the last time a run
completed. Account 1 kept importing for another five weeks; 2 and 3
never got another turn.
**That user has since deleted their account, so this ships as a latent
fix, not a rescue.** 84 of the 260 live EnableBanking connections have
two or more accounts.
## Two things I had wrong
I opened this from a different pair of connections and the product
review took both apart with data I hadn't gathered — request durations.
- **Openbank (4 accounts, 0/0 on two of them)**: I read it as
starvation. It fails in **567–1,358 ms**, less than a single account's
work (a healthy Openbank account is ~3.7s), so it is failing on the
*first* call. And all four live Openbank connections stopped syncing
within four minutes of each other on 2026-08-11 18:03–18:07. That is a
**bank-wide connector outage**, not a per-account fault. Its earlier
zero-attempt days were 429s on the daily PSU quota, at 10.7s / 14.4s /
20.7s in — a different failure this diff deliberately does not touch.
- **Renta 4 (0 transactions in 67 days)**: 62 of those days had **zero
attempts**, because the connection had dropped out of the scheduled
rotation — the bug #782 fixed. Genuine consecutive retries: five days.
The mechanism is real; my examples of it weren't. The CaixaBank
connection is.
## Deliberately conservative
The first version let a partial run report success. Both reviews pushed
back and they were right, so it no longer does — the failure is raised
once every account has had its turn. The connection keeps its Error
state, its retries and its unset `last_synced_at` exactly as today.
**The only thing that changes is that the accounts behind the failing
one get attempted at all.**
What recording it as a success would have cost, all verified in the
code:
- **An Active badge and a fresh "Last synced" over an account that had
stopped updating.** `manage-accounts.tsx:285` renders every synced
account as `Syncing`, hardcoded; there is no per-account sync state
anywhere in the product, and the new metadata key had no reader. That is
a quieter dead end than the one being fixed.
- **Permanent loss of the failing account's derived balance history.**
`calculateHistoricalBalances` is gated on the *connection's* first sync.
On a partial first run it no-ops for the failing account (no
transactions yet), and once `last_synced_at` is set it is never called
again — so when that account finally backfills a year, its daily
balances are never computed while its siblings have them.
- **A "618 new transactions" email.** Stamping
`bank_transactions_email_cutoff_at` on a partial first sync means the
failing account's eventual backfill all lands after the cutoff, which is
precisely what the cutoff exists to suppress.
- The failing account's in-cycle retries would have dropped from 3 to 1.
A provider that never answered is rethrown immediately rather than
tolerated: `statusCode` is null only on the `ConnectionException` path,
and carrying on there spends the client's 20s timeout per account
against the job's 120s. Prod: a 26-account connection already takes 62s
when everything works, and a 5-account one has peaked at 67s. Without
this guard the fix would have turned a provider timeout into a killed
job.
## Verification
`tests/Feature/OpenBanking`: 358 tests, 348 pass, and the **same 10
failures as clean main** (Inertia page-render tests hitting the SSR
`/render` endpoint, no local server). 4 new tests driven through the
existing `runSync()` helper so they assert the job-level outcome, each
verified to fail with only its own change reverted:
- the starvation case (remove the catch → fails),
- the unreachable-provider guard (remove it → fails),
- **a 429 still reaches the job** — the property I was most worried
about. 429s arrive as a raw `RequestException`, never as
`TransientBankingProviderException`, so the new catch cannot swallow one
and keep burning a per-consent daily quota account after account.
Confirmed against 30 days of prod logs: 821 rate-limit failures, every
one recorded as `RequestException`, zero as the wrapped type.
- and that a partial run still leaves the connection in Error with
`last_synced_at` untouched.
`pint`, `dry` and `crap` green — `sync` was already at complexity 13
before this and the new branches took it to 16, so `resolveWindow`,
`recordAccountTransactionFailure` and `syncBalances` are extracted and
it now sits under 10.
## Follow-ups, not done here
- **The real systemic problem is quota, not this.** 260 rate-limit
events across 26 connections and 24 users in 7 days. The default backoff
is one hour when the message doesn't say "daily", and the scheduler runs
every six — so the backoff expires long before the next cycle and
changes nothing. Trade Republic connections 429 on every single cycle,
which is why 11 users have transactions but no balance at all. That
wants a design, not a patch, and it is the biggest thing in this
subsystem.
- **No per-account sync state.** Until that exists, a connection can
only be all-good or all-bad, which is what forced the conservative
choice above.
- **No escalation for a connection that never succeeds.** Since #757
correctly stopped counting transient failures, "The bank provider is
temporarily unavailable. We will try syncing again later." is a
permanent state with no threshold, no copy change and no email.
- **`WrongTransactionsPeriodException` still skips the balance call.**
The bank refused a date range; `/balances` takes none. Same argument as
this fix, one line, left out to keep the diff to one behaviour.
- **`WiseSyncer`'s transaction call is still unwrapped** — the same bug
class in the file #788 touched. Lower stakes (one token, one host) but
worth closing.
## Auto-merge
Enabled. The behaviour change is a single `catch` that lets the loop
finish, with every other observable — status, timestamp, retries,
notifications, first-sync side effects — deliberately identical to
today. It is additive for the accounts that were being skipped and a
no-op for single-account connections, which are 7,980 of the ~12,500
runs in the last 14 days.
|
||
|---|---|---|
| .agents/skills | ||
| .claude | ||
| .cursor | ||
| .github | ||
| .opencode/skills | ||
| .pi | ||
| app | ||
| bootstrap | ||
| config | ||
| database | ||
| docker | ||
| docs | ||
| experiments | ||
| lang | ||
| public | ||
| resources | ||
| routes | ||
| screenshots | ||
| scripts | ||
| src/lib/crypto | ||
| storage | ||
| templates/coolify | ||
| tests | ||
| .crap-ignore.json | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.example | ||
| .env.production.example | ||
| .gitattributes | ||
| .gitignore | ||
| .jscpd.json | ||
| .mcp.json | ||
| .php-cs-fixer.dist.php | ||
| .php-version | ||
| .prettierignore | ||
| .prettierrc | ||
| .release-it.json | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| Dockerfile | ||
| Dockerfile.production | ||
| LICENSE.md | ||
| LOCALIZATION.md | ||
| ONBOARDING.md | ||
| README.md | ||
| artisan | ||
| autoresearch-dashboard.md | ||
| autoresearch.jsonl | ||
| autoresearch.md | ||
| autoresearch.sh | ||
| boost.json | ||
| bun.lock | ||
| chatgpt-app-submission.json | ||
| components.json | ||
| compose.yaml | ||
| composer.json | ||
| composer.lock | ||
| docker-compose.production.yml | ||
| eslint.config.js | ||
| falcode.json | ||
| opencode.json | ||
| package-lock.json | ||
| package.json | ||
| phpstan-baseline.neon | ||
| phpstan.neon | ||
| phpunit.xml | ||
| tsconfig.json | ||
| vite.config.ts | ||
| vitest.config.ts | ||
| vitest.setup.ts | ||
| whispermoney | ||
| worktree.sh | ||
README.md
Deutsch | Español | français | 日本語 | 한국어 | Português | Русский | 中文
Whisper Money
The most secure way to understand your finances.
Whisper Money is a privacy-first personal finance application that helps you track, categorize, and understand your spending—all while keeping your financial data encrypted and secure.
🎮 Try the Demo: Experience Whisper Money with our demo account - no registration required!
💬 Join our Community: Whether you're a user looking for help or a developer wanting to contribute, we'd love to have you in our Discord server! Share feedback, ask questions, discuss new features, or just hang out with fellow privacy enthusiasts.
Features
- 🔐 Privacy-first — Your data is never shared with third parties. You own it
- 🏦 Bank account management — Track multiple accounts in one place
- 📊 Transaction categorization — Automatic and manual categorization
- 🤖 Automation rules — Set up rules to auto-categorize transactions
- 📈 Financial insights — Understand your spending patterns
Tech Stack
- Backend: Laravel 12, PHP 8.4
- Frontend: React 19, Inertia.js v3, TypeScript
- Styling: Tailwind CSS v4
- Database: MySQL
- Cache/Queue: Redis
- Testing: Pest v4
Running Locally
Quick Start (Recommended)
The easiest way to get started is using our automated setup script:
bash <(curl -fsSL https://whisper.money/setup.sh)
After installation, just visit https://whisper.money.localhost in your browser.
Manual Setup
If you prefer to set up manually:
- Clone the repository:
git clone https://github.com/whisper-money/whisper-money.git
cd whisper-money
- Run the setup script:
whispermoney install
Available Commands
Important: You must run
whispermoney installbefore using any other command. If you skip the install step, commands likestartwill not work.
Once installed, you can use the whispermoney command for common tasks:
# Start all services
whispermoney start
# Stop all services
whispermoney stop
# Upgrade to latest version
whispermoney upgrade
# Interactive menu
whispermoney
Development Server
For active development with hot reloading:
composer run dev
This will concurrently start:
- PHP development server (via Portless HTTPS proxy)
- Queue worker
- Log viewer (Pail)
- Vite dev server
The application will be available at https://dev.whisper.money.localhost. In git worktrees, the branch name is automatically prepended (e.g. https://fix-ui.dev.whisper.money.localhost).
Running with Docker (Production Image)
For testing the production Docker image locally:
- Copy the production environment file:
cp .env.production.example .env
- Start the services:
docker compose -f docker-compose.production.yml up -d
The application will be available at http://localhost:8080.
To use a different port, set APP_PORT:
APP_PORT=3000 docker compose -f docker-compose.production.yml up -d
Deploying to Coolify
Whisper Money can be easily deployed to Coolify using our Docker Compose template.
Quick Deploy
- In Coolify, create a new resource and select Docker Compose
- Choose Empty Compose File as the source
- Paste the contents from our template: 👉 whisper-money.yaml
- Deploy!
The template includes:
- Whisper Money application container
- MySQL 8.0 database with health checks
- Persistent volumes for data and storage
- Auto-generated database credentials
Required Environment Variables
| Variable | Description |
|---|---|
RESEND_API_KEY |
Email service API key (for password resets, notifications) |
Note:
APP_KEYandAPP_URLare auto-configured. The container generates anAPP_KEYon first startup if not provided.
Optional Environment Variables
| Variable | Default | Description |
|---|---|---|
DRIP_EMAILS_ENABLED |
true |
Enable drip emails (welcome, onboarding, feedback) |
REGISTRATION_ENABLED |
true |
Set to false to close public sign-ups (the /register routes return a 403 and every registration CTA is hidden) while keeping /login open |
SUBSCRIPTIONS_ENABLED |
false |
Enable Stripe subscriptions |
STRIPE_KEY |
- | Stripe publishable key |
STRIPE_SECRET |
- | Stripe secret key |
STRIPE_WEBHOOK_SECRET |
- | Stripe webhook signing secret |
AI_PROVIDER |
gemini |
AI provider for every AI feature (gemini, ollama, openai, ...) |
AI Provider
Whisper Money's AI features (transaction categorization and automation-rule
suggestions) run on laravel/ai and default to
Google Gemini. The provider is configurable independently of the model, so
you can point the app at any text provider laravel/ai supports — gemini,
openai, anthropic, azure, groq, xai, deepseek, mistral, or a
self-hosted Ollama server. Ollama is the headline case
because it keeps AI processing fully local and private — data never leaves your
infrastructure — but the switch is generic.
Each provider needs its own credentials configured for laravel/ai (e.g.
GEMINI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, or OLLAMA_URL). An
unknown or non-text provider fails fast when the AI feature runs.
| Variable | Default | Description |
|---|---|---|
AI_PROVIDER |
gemini |
Provider for all AI features. Set once to switch everything. |
AI_SUGGESTIONS_PROVIDER |
AI_PROVIDER |
Override the provider for rule suggestions only. |
AI_CATEGORIZATION_PROVIDER |
AI_PROVIDER |
Override the provider for transaction categorization only. |
AI_REPORTS_PROVIDER |
AI_PROVIDER |
Override the provider for the stats-report summaries only. |
AI_SUGGESTIONS_MODEL |
gemini-flash-latest |
Model used for rule suggestions. |
AI_CATEGORIZATION_MODEL |
gemini-flash-latest |
Model used for transaction categorization. |
AI_REPORTS_MODEL |
gemini-flash-latest |
Model used for the stats-report summaries. |
AI_REPORTS_TIMEOUT |
30 |
Seconds before a report is posted without its AI summary. |
GEMINI_API_KEY |
- | Required when the provider is gemini. |
OLLAMA_URL |
http://localhost:11434 |
Ollama server URL (used when the provider is ollama). |
OLLAMA_API_KEY |
- | Optional; only needed behind an authenticating proxy. |
Example: fully local AI with Ollama
AI_PROVIDER=ollama
OLLAMA_URL=http://ollama.example.local:11434
AI_SUGGESTIONS_MODEL=gemma3:12b
AI_CATEGORIZATION_MODEL=gemma3:12b
Make sure the model is pulled on the Ollama server first (ollama pull gemma3:12b).
Any other provider follows the same pattern: set AI_PROVIDER, that provider's
credentials, and the *_MODEL vars to one of its models. Gemini remains the
default, so existing deployments are unaffected.
Star History
License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.