# EU-native by architecture, and what that actually constrains

> 23 Jul 2026 · Telemeter · 3 min read

"EU-native" is easy to put on a landing page and hard to mean. Treating it as an architecture constraint instead of a badge changes what you're allowed to build.

"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](/legal/sub-processors) — 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](/eu-native) 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.

[Read on telemeter.ai](https://telemeter.ai/blog/eu-native-and-what-it-constrains) · [Every tool and doc, machine-readable](https://telemeter.ai/llms.txt)