Data residency
OnTrackio is a multi-tenant cloud service, hosted in the European Union (Frankfurt) today. This page explains where your data physically lives, how it stays isolated from every other customer, and how regional residency is changing as the platform expands.
:::note Before you begin This is a conceptual page for security and compliance reviewers. It explains the posture; it doesn't change any setting. There is no separate residency screen inside the product, so this page is the canonical reference to cite in a security questionnaire or attach to an evidence pack. :::
Where your data lives today
Every customer workspace, and everything it holds, is hosted in AWS Frankfurt
(eu-central-1). There is no copy of your operational data outside the EU. The table
below maps each kind of data to where it sits and how it's protected.
| Data | Where it lives | At rest | In transit |
|---|---|---|---|
| Workspace records — hardware, software licences, requests, users, settings, audit log | Your dedicated PostgreSQL database in EU (Frankfurt) | AES-256 (database storage encryption) | TLS on every connection |
| Documents and uploads — invoices, branding assets, agent installers | EU (Frankfurt) object storage, under a path prefixed to your workspace | SSE-S3 (AES-256) | TLS via signed URLs |
| Platform metadata — your workspace name and its domains | A shared metadata database in EU (Frankfurt) | AES-256 | TLS |
| Outbound email, application logs | EU (Frankfurt) | provider-managed | TLS |
The full list of the vendors that process this data on the platform's behalf is on the subprocessors page.
:::tip One residency answer for every customer Residency does not depend on your plan. A small workspace and a large one are stored in the same region, encrypted the same way, and isolated by the same mechanism. The architecture is uniform on purpose, so there is no "compliance tier" to negotiate. :::
How your data is isolated from other customers
The platform's strongest isolation control is structural, not a setting an administrator has to switch on: each workspace runs in its own dedicated database. Your records are not co-mingled in shared tables with row filters; they live in a separate database that no other customer's request can address.
| Layer | What it means for isolation |
|---|---|
| Database per workspace | Each workspace has its own PostgreSQL database. There are no shared business tables across customers. |
| Hostname-bound connection | The active database is chosen from the verified hostname on each request. A request to one workspace can never resolve to another's database. |
| Shared metadata only | The shared database holds only your workspace name, its domains, and platform infrastructure tables. It holds no business records and no cross-workspace index of user emails or sign-in credentials. |
| Role-based access within a workspace | Inside a workspace, role-based access control scopes who can read or change what. |
Because the database is selected from the hostname and nothing else, a cross-customer query is not possible at the connection layer — it's not blocked by a check that could be misconfigured; there is no code path that reaches another workspace's data.
:::note Authentication never leaves your workspace Sign-in happens entirely inside your own workspace database — password, single sign-on, and multi-factor secrets all live there. The shared metadata database keeps no index of who can sign in to what, so one customer's directory can't leak into another's. :::
Encryption posture
Encryption applies in two places: data sitting in storage, and data moving over the network. Both are on by default for every workspace, with no configuration required.
| Surface | Protection |
|---|---|
| Database storage | AES-256 encryption at rest, managed by the cloud provider |
| Document and file storage | SSE-S3 (AES-256) at rest; transferred over TLS through time-limited signed URLs |
| Network connections | TLS for browser-to-platform traffic and for the platform's own connections to the database |
| Multi-factor secrets and sensitive settings | Additionally encrypted at the application layer before they reach the database |
| API tokens | Stored only as a hash; the full token is shown once at creation and never again |
| Agent signing keys | Stored only as a hash on the platform; the private key stays on the enrolled device |
Two of those rows matter for a reviewer's checklist. API tokens and agent keys are never recoverable from the platform — only a hash is kept — so a database disclosure can't hand an attacker a working credential. See API tokens and webhooks and what data is collected for how each is issued.
Backups and retention
Backups inherit the same region and the same encryption as the live data.
| Aspect | Posture |
|---|---|
| Database backups | Automated daily, encrypted, retained for 7 days, in the same region |
| Document storage | Versioned, so a deleted or overwritten file can be recovered |
| Audit log | Retained for at least 30 days; configurable to a longer window |
A backup is never written to a different region than the workspace it came from, so your residency guarantee covers your recovery points as well as your live data.
Regional residency: today and the roadmap
The honest current state is simple: the platform is EU-only today. Every workspace is in Frankfurt. The sections below describe where regional residency is heading, so a reviewer evaluating the platform for a multi-region organisation knows what's available now versus what's planned.
The intended model: residency follows the customer
The direction is that residency becomes a property of the customer, not a single global default. An organisation operating in more than one region will be able to keep each region's data in that region:
- A European organisation's data stays in the EU.
- A US organisation's data is stored in the US.
- A US-headquartered company with European operations subject to EU rules can hold its European data in the EU, separate from its US data.
This is framed as enabling your organisation's compliance, not as a statement about the platform's own certifications. The goal is to let you put your data where your regulators expect it.
Headquarters oversight across regions
In a multi-region organisation, a parent (headquarters) needs to see across its regional entities even when each entity's data physically stays in-region. The intended model keeps storage in-region while giving headquarters scoped, logged visibility into its entities.
:::warning Cross-region visibility is an international transfer Storing data in-region is the straightforward half. The moment headquarters in one country reads an entity's data held in another, data-protection law generally treats that access as an international transfer — even though the data never moved. That half needs legal rails (such as standard contractual clauses or an adequacy framework, plus a transfer assessment) and technical controls (scoped access and access logging) before it ships. It is roadmap, not a setting you can turn on today. :::
What this means for you right now
| If you are… | Today | On the roadmap |
|---|---|---|
| An EU organisation | Fully supported — your data is in the EU | No change needed |
| A US organisation | Supported on EU infrastructure today; US storage is planned | US residency |
| A multi-region group needing per-entity residency | Talk to us about timing | Per-region entities with headquarters oversight |
If regional residency is a procurement requirement for you, raise it early — the timeline depends on demand, and the EU posture above is what's contractually true today.
Limitations and trade-offs
Knowing the edges keeps the posture credible.
| Boundary | What it means |
|---|---|
| EU-only today | Every workspace is hosted in Frankfurt right now. Multi-region storage is roadmap, not a present capability. |
| Cloud-hosted service | OnTrackio is a managed multi-tenant cloud service. The residency and isolation guarantees here describe that hosted platform. |
| In-region backups, in-region recovery | Backups and document versions stay in the workspace's region; they don't provide a second-region copy for disaster recovery today. |
| Headquarters oversight needs legal rails | Cross-region visibility for a parent organisation is an international-transfer question, gated on the controls described above before it ships. |