How we built EU-resident family-finance on GCP | ivmanto.com

Articles

Published on July 3, 2026<br>How we built EU-resident family-finance on GCP<br>Family money is the most sensitive data we hold. Here's how we built nestbalm on GCP — data in Europe, a schema per household, and a key per family.

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.

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.

Keys stay close to the family — each household's data is encrypted under its own key, not one master key we can sweep across everyone at once.

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: a key per household

"Keys stay close to the family" is a promise, so we want to be precise about what it means today and what it doesn't — because the fastest way to lose a skeptical reader is to overclaim on encryption.

Today, each household's data is encrypted with its own key, managed in Cloud KMS using envelope encryption. Practically, that means there is no single master key that unlocks every family at once — compromising one household's key doesn't cascade to the next. The direction we're building toward is 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...