How we built EU-resident family-finance on GCP

Correction (30 Jul 2026): This post originally claimed we hold no master key — that household data is unrecoverable by us. That's the design goal, not the current state: a security review found our per-household data keys are wrapped with Cloud KMS in a way that is operator-recoverable. We're shipping audit-logging now and redesigning recovery around user-held codes. Leaving the post up with this note rather than quietly editing it.

Also updated: soft open moved from August to September 1, 2026.

Update (4 Aug 2026): A further code-level review found that our encryption claims were overstated. Field-level encryption covers exactly two columns — bank account numbers and transaction memos (AES-256-GCM). Other fields (payee, amount, date, category, budgets, goals) are plaintext by design. The per-household data key is KMS-wrapped and operator-recoverable by design, because families lose passphrases and still need their money back. We've corrected the body below. We never sell your data and never train on it — that part was always true.

A build-in-public note from the team behind nestbalm — a budgeting app for the whole household. We're pre-launch, building with families ahead of the September 1 soft open.

Most budgeting apps start with the dashboard. We started with a more boring question: if a family trusts us with every transaction, every shared account, and their kids' allowances, where does that data physically live — and who can actually read it?

For a household in Germany or the wider EU, that isn't a checkbox at the bottom of a settings page. It's the whole decision. German families are, rightly, among the most privacy-cautious in Europe, and "we take your privacy seriously" is not a sentence anyone believes anymore. So before we built a single feature, we committed to two lines and refused to break them for convenience:

Data stays in Europe — everything at rest and in processing, in European regions, with no transfer to the US.
Encrypted at rest and in transit — provider-managed encryption on European servers, with field-level encryption for the most sensitive columns.

Everything below follows from those two sentences.

Compute: stateless containers, European regions

We run the app on Cloud Run — stateless containers, pinned to European regions. Stateless is the point: no household data lives on the compute layer. It's just the code path between the family's device and the encrypted store, and it can be torn down and replaced without anything sensitive riding along. Region placement is enforced at the platform level, not left to a config someone can fat-finger later.

Data: one schema per household

Multi-tenant apps usually pick one of three isolation models. We went with the middle one, on purpose.

Shared tables with a tenant_id column is the cheapest to operate — and one careless query away from leaking one family's money data into another's. For this data, that blast radius is a non-starter.
A database per household is the strongest wall, but the operational cost climbs steeply as families join.
A schema per household — where we landed. Every household gets its own schema and its own tables, so isolation is enforced down at the query layer, without us running a separate database per family.

It isn't free. Migrations have to fan out across every schema, and you feel that overhead in tooling and deploys. We think it's the right tax to pay when the rows are somebody's household finances.

Encryption: what's actually encrypted

We want to be precise about what's encrypted and what isn't — because the fastest way to lose a skeptical reader is to overclaim on encryption.

What's encrypted at the field level: bank account numbers and transaction memos are separately encrypted with AES-256-GCM, each under a per-household data key wrapped in Cloud KMS. This means those two fields are protected beyond the provider's standard at-rest encryption.

What's not: payee, amount, posted date, category, budgets, and goals are stored in plaintext within the per-household schema. They rely on schema isolation and provider-managed at-rest encryption, not a separate key layer.

Key recovery is operator-recoverable by design. The per-household data key is wrapped through Cloud KMS in a way that allows us to unwrap it — because families lose passphrases and still need their money back. We're working toward giving families more direct custody over that key over time; where exactly that line sits at launch is something we'll state plainly in the product, not blur in a blog post.

If you're the kind of reader who's already drafting a comment about the difference between provider-managed and customer-held keys — good, that's the right question, and it's one we'd rather answer honestly than paper over.

Identity: fewer secrets to lose

Sign-in runs through established SSO / OAuth rather than us hand-rolling a password store on day one. The fewer credentials we store, the fewer we can ever lose. More sign-in options are on the roadmap; the principle stays the same — hold as little as we can get away with.

Residency in practice: the unglamorous enforcement

Saying "data in Europe" is easy. Making it structurally true is the actual work:

European regions for both compute and storage.
Placement constraints so a service can't quietly spill into a US region under load.
Encryption keys created and kept in European KMS.
Every third party in the path vetted for where it processes, not just whether it's convenient.

None of that is a headline feature. It's the plumbing that makes the headline honest.

The honest tradeoffs

Building in public means the caveats, too:

Staying EU-region-only rules out some cloud services and newer features that land in the US first. We've eaten that.
Schema-per-household adds real migration and operational overhead.
Field-level encryption on the most sensitive columns adds key-management complexity we have to carry — and the operator-recoverable key escrow is a deliberate tradeoff, not an accident.

Each of those is a genuine cost. We took them because the alternative — the convenient, US-cloud, one-big-key default — is exactly the thing families are right to be wary of.

Why we're publishing this before launch

nestbalm isn't fully open yet. We're building it with families, in the open, ahead of the September 1 soft launch — and the architecture above is a commitment we're making early precisely so we can be held to it.

If you manage money as a household in Europe and you have opinions on where these lines should sit, that's the feedback we actually want. There's a 3-minute survey at nestbalm.app; finishing it locks in 45 days of premium free at launch.

Data in Europe. Encrypted at rest and in transit. Made in Germany.

— The nestbalm team