Data Residency

"Your source code is your corporate memory. Decide, consciously, which jurisdiction holds it."

Overview

Aura does not store your code on a vendor's servers. There is no managed cloud tier that ingests source in the default configuration. The Mothership runs on a machine you choose, in a network you operate, in a country you pick. The peers run on developer laptops and CI workers that you also choose. This architectural choice means data residency is not a feature Aura grants you — it is the consequence of where you install the software.

This page exists because that simple statement has complicated implications. Regulators care about the flags in your configuration file. Auditors care about network diagrams. Legal teams care about jurisdictional exposure and lawful-access regimes. The sections below walk each of those concerns through the Aura architecture.

Aura's developer, Naridon, Inc., is headquartered in Zürich, Switzerland. Switzerland has its own data-protection regime (revFADP) recognized as adequate under EU law, and it is outside the territorial scope of the US CLOUD Act. These facts matter when choosing a vendor, even if — as in Aura's case — the vendor never touches your data.

Threat Scope

Data residency concerns three distinct risks:

Jurisdictional lawful access. A government compels a service provider to disclose customer data under domestic law. Aura's response: there is no service provider to compel. Your data lives on your machines.
Cross-border data transfer compliance. EU law (GDPR, EU Data Act), UK law (UK DPA, UK GDPR), Swiss law (revFADP), and the post-Schrems II reality all place restrictions on where personal data may be sent. Source code routinely contains names, email addresses, and embedded credentials — making it personal data under GDPR for many projects.
Operational data locality. Latency, availability, and regional failover concerns that dictate the Mothership's physical placement.

This page focuses on (1) and (2). For (3), see bandwidth and performance.

Mechanism

Where code lives

At any given moment, your Aura-tracked code exists in these locations, and nowhere else:

On each peer machine, as files in the working directory and in ~/.aura/cache/ on that peer.
On the Mothership machine, as an append-only logic-node store and intent log.
In transit over TLS 1.3 between these machines during sync.

There is no backup to a Naridon-operated bucket. There is no telemetry pipeline exfiltrating AST deltas. There is no anonymized usage data uploaded for product analytics. A stock Aura install makes exactly zero network connections to any Naridon-operated endpoint.

The only outbound connections the Aura daemon makes, by default, are:

To peers in your own directory (provisioned via Mothership join).
To your own Mothership.

Optional, explicit features that may add outbound connections:

aura self-update — checks Naridon's release server for a new version. Opt-in by default; disabled in air-gapped profiles.
Let's Encrypt ACME enrollment — only if you configured your Mothership to use LE for TLS rather than self-signed or your own PKI.

Binding the Mothership to a jurisdiction

The Mothership binds to a specific network interface on a specific host. That host's physical location determines where the canonical copy of your logic nodes lives. To pin it in a specific jurisdiction, deploy the Mothership VM in a provider's region that physically sits in that country, and configure:

[mothership]
bind = "10.0.5.3:7443"
advertised_host = "aura.internal.example.ch"

[residency]
# Human-readable label; surfaced in status output
jurisdiction = "CH"
# Hard-block peers whose observed IP is outside this CIDR list
peer_cidr_allowlist = [
    "10.0.0.0/8",       # corporate VPN
    "192.168.0.0/16",   # office LAN
    "203.0.113.0/24",   # CI egress
]
# Fail closed if a peer advertises an IP outside the allowlist
enforce_cidr = true

When enforce_cidr = true, the Mothership refuses to register or accept sync from peers whose IP is not covered. This is a crude but effective geo-fence. Combine with VPN egress controls to guarantee that all peers ride a specific tunnel — and thus appear from a known CIDR — regardless of where the developer physically sits.

The Mothership signing key

The Mothership signing key (see cryptographic design) is the root of trust for your Aura deployment. It is generated on first start and stored at $MOTHERSHIP_DATA/identity/signing.key. Back this up to an encrypted store in the same jurisdiction. If the key is destroyed without a backup, you must re-enroll every peer. Treat the backup with the same care you would give a small certificate authority's root key.

Aura is open-source software, not a service. There is no data processing agreement to sign with Naridon because Naridon is never a data processor for your repository. The people involved in a GDPR analysis of an Aura deployment are:

Controller: your organization. You determine the purposes and means of processing.
Processor: also typically your organization, or whichever operator runs the Mothership on your behalf.
Sub-processor: whichever IaaS provider hosts your Mothership (AWS Frankfurt, Hetzner, OVH, etc.). Their DPA applies at the infrastructure layer, not at the Aura layer.

Naridon's role is limited to supplying software. Under the GDPR's definitions this is equivalent to selling a database engine — the vendor is not a processor of the data stored in it.

For Switzerland-resident entities, revFADP requirements align closely with GDPR and, in fact, impose a few additional obligations around profiling and breach notification. An Aura deployment on Swiss infrastructure satisfies the "data stays in Switzerland" expectation straightforwardly.

EU Data Act

The EU Data Act (Regulation 2023/2854) primarily addresses cloud-service portability and IoT data access. Two of its provisions touch Aura deployments:

Portability of data out of cloud services — not directly applicable because Aura is not a cloud service you subscribe to. If you self-host on a cloud provider, the Data Act's portability guarantees apply to your relationship with that cloud provider, not with Naridon.
Third-country access safeguards (Article 32) — relevant if a cloud operator hosting your Mothership is subject to a third-country government's lawful-access demands. Choose a cloud operator whose jurisdictional exposure is compatible with your compliance requirements.

Schrems II and international transfers

The CJEU's Schrems II decision (Case C-311/18) rendered the EU–US Privacy Shield invalid and imposed a contextual assessment on transfers to third countries. In practice, transferring personal data to US-owned cloud regions requires documented Transfer Impact Assessment (TIA) work plus Standard Contractual Clauses plus, often, supplementary technical measures.

Aura's design sidesteps most of this. If your Mothership and all peers sit in the EEA or Switzerland, no international transfer happens at the Aura layer. Transfers happen only if:

A peer connects from outside the EEA/CH (e.g., a contractor traveling).
Your Mothership is hosted on a cloud region outside the EEA/CH.
You enable aura self-update, which retrieves a release binary from Naridon's distribution server (Swiss-hosted; under adequacy).

The first case is handled by the CIDR allowlist. The second is a provisioning choice. The third is opt-in and does not transfer any repository data — only a binary download request.

The UK has its own adequacy arrangement with the EU and recognizes Switzerland as adequate. A deployment with a Mothership in the UK, CH, or EEA satisfies UK GDPR transfer requirements for all three origins. Hosting the Mothership in a non-adequate jurisdiction would require UK International Data Transfer Agreements; the CIDR allowlist mechanism can be used to constrain where peers may connect from.

Configuration

A fully locked-down residency configuration looks like this:

[mothership]
bind = "10.0.5.3:7443"
advertised_host = "aura.internal.example.ch"

[residency]
jurisdiction = "CH"
peer_cidr_allowlist = ["10.0.0.0/8", "192.168.0.0/16"]
enforce_cidr = true

[updates]
# Fully disable the self-update check
auto_check = false

[telemetry]
# There is no telemetry in the default build; this flag hard-locks it
enabled = false

To audit residency compliance at runtime:

aura status --residency

Emits a report of: Mothership bind address, observed jurisdictions of active peers, any peers outside the allowlist (which should be zero when enforce_cidr = true), the TLS certificate subject, and the self-update configuration.

Limitations

Residency is a deployment property, not a software property. Aura's code does not and cannot enforce a jurisdiction; it can only refuse connections outside a CIDR you configure. Mis-configuring the allowlist is a human error Aura cannot prevent.
Peers with VPN-routed IPs are opaque to the CIDR check. If a contractor in Singapore connects via the corporate VPN in Zürich, Aura sees a Zürich IP and permits the connection. This is usually the intended behavior, but it means Aura does not substitute for endpoint geolocation controls.
IaaS provider jurisdictional exposure is not Aura's problem. If your Mothership runs on a US-owned cloud region in Frankfurt, the US CLOUD Act applies to the operator regardless of where the server sits. Choose infrastructure consciously.
DNS still leaks. The Mothership's DNS name, if published externally, reveals that your organization uses Aura. Split-horizon DNS or internal-only resolution avoids this; fully air-gapped deployments should use IP addresses or /etc/hosts entries.