"EU-native" is one of those phrases that costs nothing to write and a great deal to mean. It can be a badge — a flag icon and a reassuring sentence — or it can be a set of constraints that decide, concretely, what the system is allowed to do. This post is about treating it as the second thing, and being honest about the line between what is committed and what is deployed.
A constraint is something you can violate#
The test of whether "EU-native" is real is simple: name the thing it forbids. A badge forbids nothing. An architecture constraint forbids specific designs — it says this data may not sit there, this provider may not be added silently, this telemetry may not become un-exportable. If nothing is off the table, the claim is decoration.
For telemeter, the constraints are concrete:
- Regional storage is a first-class deployment choice, not an afterthought. Where production telemetry lives is a decision made on purpose, with EU residency as the intended target — including the unglamorous parts, like regional backups and restore drills.
- The processing chain is published, not implied. The providers that touch data, their purpose, their region, and any cross-border transfer are written down on the sub-processors page — including the ones that are not fully in-region. The email provider's account data and logs sit in the US today; that is disclosed as a gap, not hidden behind the badge.
- The interfaces at the boundary stay open. OpenTelemetry in, documented export paths out. The point of open interfaces is that leaving is possible — a residency promise you can't act on by moving your data is a weaker promise.
Saying "planned" out loud#
Here is the part a marketing page usually skips. Most of the EU-native posture is an architecture commitment, and some of it is not yet deployed. The production data store's region, the telemetry residency — those are planned and stated as planned. The EU-native page says, in as many words, that it does not claim GDPR compliance, certification, or a live EU telemetry region before that is verified against the deployed system.
That admission is not a hedge; it is the honest version of the claim. "EU-native by architecture, not certified" tells you exactly what you are getting: a system designed around residency and portability as constraints, with the compliance claims held back until there is a deployed system to check them against. The alternative — a compliance badge on a pre-launch product — is the thing this whole site is built to not do.
Why constrain early#
Residency and portability are cheap to design in and expensive to add later. Retrofitting "your data can live in the EU" onto a system that assumed it could put data anywhere is a migration; building the constraint in from the start is just a decision. The same is true of the sub-processor register: maintaining it from the first provider is a habit, while reconstructing it after the fact is an audit.
So the constraint comes first, and the badge — if it ever appears — comes last, once there is a deployed system that has actually earned it.