Data residency

Last updated: 2026-04-11 • ← Privacy

Backbuild runs on a globally distributed infrastructure that allows customer traffic to be served close to the end user. Where customers have specific residency requirements, data processing and storage can be pinned to defined geographic regions.

Primary processing locations

• Edge compute: the Cloudflare global network serves customer traffic from the edge location nearest the user. This network includes hundreds of points of presence worldwide.
• Core data store: customer data is stored in a managed Citus PostgreSQL cluster. The primary region is selected at contract time.
• Object storage: files and binary artifacts are stored in Cloudflare R2 in a region consistent with the customer's selected residency.
• Backups: backups are stored encrypted in object storage in a region consistent with the customer's selected residency, with geographically separated copies for disaster recovery where configured.

Default behavior

By default, request traffic is served at the edge location nearest the user for performance and availability. The core data store is located in a primary region that is chosen at contract time and is documented in the customer's order form. Cross-region replicas are used for resilience and are encrypted at rest.

EU data residency

Customers with EU residency requirements can use Cloudflare's Data Localization Suite (DLS) to keep personal data within the EU for processing and storage. When DLS is configured, request traffic is terminated and processed within EU data centers, and the core data store is pinned to an EU region. Contact the team during onboarding to configure DLS for your tenant.

Release artefact residency

Binary release artefacts distributed through Backbuild (desktop app updates, CLI binaries, LSP updates, and white-labeled variants of the same) are served from dedicated R2 buckets. Each product record carries a data_residency marker selected at product creation time:

• us (default): artefacts are stored in an R2 bucket located in ENAM (eastern North America). Downloads are served from the global Cloudflare edge but binary storage is physically located in ENAM.
• eu: artefacts are stored in an R2 bucket located in EEUR (eastern Europe). Downloads are served from the global Cloudflare edge but binary storage is physically located in the EU.

The release manifests (which name the artefacts, carry SHA-256 digests, and are signed with our Ed25519 release-signing key) are colocated with the artefacts in the same bucket, so both the binary and its integrity metadata remain within the selected region.

The signing-key material itself is stored in Cloudflare Workers Secrets, which is a globally distributed key-value store. The private key is referenced, not transmitted, during signing. Public keys are distributed through a chain registry served at /.well-known/release-pubkeys-registry.json; clients pin a root key and verify chain continuity on rotation.

Edge cache responses include an x-bb-residency header that confirms which bucket served the object. This is informational for troubleshooting; it does not change routing behaviour.

To configure EU residency for a product, contact the onboarding team or set the product's residency via the API when you call the product-upsert endpoint. Residency can be changed later; the team performs a one-time migration of existing artefacts between buckets on request, with a short coordinated downtime window.

US data residency

All processing and storage can be pinned to US regions on request. This is typically selected by customers with US-only operations or where customer contracts require US residency.

International transfers

Where personal data is transferred outside the EEA, UK, or Switzerland, Backbuild relies on the appropriate transfer mechanism:

• Standard Contractual Clauses (SCCs): the current EU Commission SCCs (2021/914) are included in the Data Processing Agreement for transfers subject to GDPR.
• UK International Data Transfer Addendum (UK IDTA): included for transfers subject to UK data protection law.
• Swiss addenda: additional clauses address transfers subject to the Swiss Federal Act on Data Protection.

A Transfer Impact Assessment methodology is followed for transfers that require one. Results are made available to customers under NDA on request.

Specific residency requirements

Customers with specific residency requirements (for example, a requirement to restrict processing to a single region, to exclude particular jurisdictions, or to use dedicated infrastructure) should contact the team to discuss options. Not all combinations are available on all subscription plans.