Data residency - NeoChamber

In a sovereign deployment, every component below runs inside your cloud account, pinned to your chosen region. Nothing is shared with other operators, and there is no cross-operator control plane.

Component	What it holds	Where it runs
Console & APIs	The operator and customer consoles, ingest and query APIs	Your deployment, as code
Metrics store	All GPU/node telemetry at 15s resolution	Your account, your region
Log store	Per-node driver/dmesg/agent logs (30-day retention)	Your account, your region
Control data	Tenants, users, nodes, tokens (hashed), events, audit	Your account, your region — point-in-time recovery on, nightly exports to your own bucket
Agent binaries	Signed, checksum-verified releases	Your account’s artifact bucket
GPU servers	Your metal — agents connect outbound-443 only	Your datacenters

What we record about location

Every request an agent makes reaches the platform with an approximate location for that connection, and the latest one per node is kept (city-level at best) so the fleet map can place a site you have not placed yourself. Being precise about what that is:

It is the location of the machine’s network egress. For a datacenter that is usually the building; behind a VPN, corporate tunnel, or cloud NAT it can be another country entirely.
It is exactly why coordinates you set always outrank it, and why the two never look alike on the map.
It is visible only to your operator, and only rolled up to the site level.
Simulated demo nodes, and anything running off the platform, get no position at all.

See Sites and the map for how this renders.

Self-hosting

The platform is designed so that a competent stranger can stand the whole thing up from the repository docs in about an hour: all cloud resources as Terraform, the console as code, CI with a required cross-tenant test, and a rehearsed backup and restore path. Ask us for the walkthrough, or about the on-prem design-partner program.

⌘I