> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neochamber.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Data residency

> Component by component, where every byte of your data lives.

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](/operators/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](mailto:charles@usechamber.com), or about the
on-prem design-partner program.