What is data residency for a secrets vault?

Data residency is the requirement, set by law, contract or company policy, that certain data be stored, and sometimes processed, only in a specific country or region, which for a secrets vault means its database, backups and logs must live on infrastructure in that place.

What it actually constrains

Residency is about location, and the details matter more than the word:

• Storage versus processing. Many platforms can pin where data is stored more easily than where it is processed. Cloudflare's D1 database, for example, offers jurisdictions such as eu that control "where the database itself runs and persists data", while "Workers may still access the database constrained to a jurisdiction from anywhere in the world" (Cloudflare).
• Hints versus guarantees. The same documentation separates jurisdictions from location hints: "Providing a location hint does not guarantee that D1 runs in your preferred location."
• Copies. Backups, replicas, logs and support exports all count. A database in one region with backups in another doesn't meet most residency rules.

Residency is also not the same as confidentiality. Data stored in the right country can still be read by the provider, the operator or anyone with access to the account. If the concern is who can read the values, encryption on the client side answers it; location doesn't.

Common mistakes

• Checking the database and forgetting the rest: backups, log shipping, error tracking, email providers.
• Assuming a region setting is a guarantee. Read whether it is a constraint or a preference.
• Treating encrypted data as out of scope. Some rules apply to encrypted data too. Ask whoever set the requirement.
• Forgetting metadata. Names, email addresses and audit logs are personal or business data even when values are encrypted.

Residency with Crunu

When you host Crunu yourself, which is available on the Enterprise plan, you choose where it runs: your own server with Docker, Cloudflare Workers with D1, Vercel with Postgres on Neon, or Google Cloud Run with Cloud SQL or Neon. The database, and so the location of the data, is whatever you set up on that platform. Crunu's deploy script for Cloudflare accepts a location hint for a new D1 database and uses an existing database if one with the given name already exists, so if you need a jurisdiction rather than a hint, create the database yourself first.

Two facts shape what residency means here. The server stores only ciphertext of values, so no copy of the database reveals them wherever it sits. And the server does see metadata in plain form: names of organizations, projects, environments and machines, people's email addresses, the audit log and the sizes and times of versions. That metadata is what residency rules for a Crunu server mostly concern. Backups made with crunu-server export carry the same mix and should follow the same location rules.

You can move a self-hosted server between platforms with one archive, which also means moving between regions; the server's address stays the same, because sign-in, links and agents are tied to it. If where the data sits is a hard requirement, self-hosting on the Enterprise plan is how Crunu lets you decide it. The options are compared in self-hosted secrets manager: options and trade-offs, with commands on the self-hosting page.

Sources

• Cloudflare D1: Data location, checked October 30, 2026.