Technical disclosure · Data location

Locality is selected per resource.

Korve offers locality controls, not a legal data-residency guarantee. Compute, databases, caches, storage, queues, and recovery copies have different placement models. A project region is not a promise that every related byte stays in one country or area.

Compute placement

Scale-to-zero applications run at the global edge and do not accept a compute region.
Always-on applications run in a selected supported compute region. Keep the application close to its database when request latency matters.
An application runtime choice does not automatically choose the location of its database, cache, storage, queue payloads, or recovery copies.

Stateful resources

Managed databases, caches, and object-storage buckets each use their own supported locality catalog. The live regions operation is the source of current accepted values.
New object-storage buckets route their objects to the selected storage area. Older storage created before area stores can remain in the platform default store.
Queue bodies are encrypted and stored in the selected data area. The delivery substrate receives an opaque pointer instead of the body.

Recovery placement

The primary managed database recovery repository requests best-effort placement near Western North America.
Optional managed recovery copies can request Eastern North America, Western Europe, Eastern Europe, Asia-Pacific, or Oceania.
Each copy records the requested area and its own status. Area placement is best effort and is not a data-residency guarantee.

Metadata outside a project region

Identity, organization membership, billing, source integration, support, control-plane state, audit evidence, and operational telemetry do not inherit a project's resource region. Global request routing can also process network metadata outside a selected stateful-resource area. Review each resource and recovery policy as a separate location decision.