Keeping Datadog telemetry in the EU: what the EU1 site settles
If your logs carry user identifiers and your traces carry request attributes that count as personal data, the question is not only where bytes are stored. Datadog's EU1 site keeps your data in a separate regional service, and Datadog's documentation states that each site is completely independent and data cannot be shared across sites. That answers a location question. It does not by itself settle who administers the platform, who can access the data, which sub-processors touch it, or how your own processing records describe it. A self-hosted OpenTelemetry, Prometheus, Grafana and Loki stack running in your own EU cloud accounts or data centers can answer all of those questions, because you hold the control plane, the keys and the access logs. Which path fits depends on the data classes involved, so classify them first.
Start with an inventory of what leaves your services. Metrics labeled with customer IDs, log lines with email addresses or IP addresses, and span attributes such as query parameters are the usual sources of personal data in telemetry. Ask Datadog for its current data processing addendum, sub-processor list and the EU1 hosting details in writing, and check them against your records of processing. Confirm with Datadog which support and engineering access paths exist for EU1 data, and whether any telemetry types are replicated or processed outside the site. Those answers, not the site name, determine whether a hosted EU1 tenant is acceptable for each data class.
If the review shows that some telemetry must stay under your control, plan the self-hosted part as a separate pipeline. Send it through OpenTelemetry Collectors you operate, then into Prometheus for metrics, Loki for logs and an EU-hosted trace backend, with Grafana in front. Loki's recommended production object stores include Amazon S3, Google Cloud Storage and Azure Blob Storage, so choose the EU region for each and document it. Loki has no built-in authentication layer, so an authenticating reverse proxy must sit in front of it. Grafana's SAML and team sync features are available only in Grafana Enterprise and Grafana Cloud, so confirm your identity requirements before you choose a Grafana edition. Keep the Datadog tenant for data classes that the review clears, and document the split.
What EU residency requires from a telemetry platform
Telemetry often carries personal data in log lines, trace attributes and user identifiers, so where it is stored and who can reach it matter as much as the tool. The cards below list the decisions a residency requirement forces, and each one maps to a fact you can verify in a hosted product or in your own EU infrastructure.
Named EU storage location
Confirm which region and site hold each telemetry type: metrics, traces and logs can land in different places. Datadog's hosted service is split into separate regional sites, including EU1, so choosing the right site is a contract and configuration question you must verify. In a self-hosted stack, the storage location is your own: Loki's chunks and index sit in the object store you choose, so pin that bucket and its replicas to EU regions in writing.
No cross-site data sharing
Datadog's documentation states that each site is completely independent and data cannot be shared across sites. For a residency review, that means a team using one site cannot later query telemetry held in another without moving it. Map every system that sends telemetry, including shared dashboards, alert integrations and support access, to a single named site before go-live.
Operator and access control
Decide who operates the backend and who can read it. A hosted service means the vendor's staff and sub-processors are part of your data flow, which your DPO will need to document. A self-hosted stack moves that control to your team, but it also makes your team accountable for administrator access, key handling and audit logs on Prometheus, Grafana and Loki.
Retention you set yourself
Retention is a legal decision as well as a storage setting. Loki's retention is disabled by default, so logs are kept indefinitely until retention_enabled is set, which can conflict with a minimization obligation. Prometheus defaults to 15 days of local retention. Write the retention period for each telemetry type into your records of processing and configure it explicitly, then test that the compactor actually deletes data.
Authentication in front of every endpoint
Loki has no built-in authentication layer, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front of it. Prometheus and its exporters, Alertmanager and the Loki push path need the same treatment. Grafana's hardening guide also recommends requiring authentication for the metrics endpoint. Test each endpoint from outside the network to confirm nothing answers unauthenticated.
Where Datadog's EU1 site meets residency needs and where it does not
Datadog runs its hosted service in separate regional sites, and EU1 is the site that European customers can select for their data. Datadog's site documentation states that each site is completely independent and that data cannot be shared across sites. For residency, this gives you a defined location for stored telemetry and a clear boundary you can describe in data flow diagrams and records of processing. It answers the question of placement, which is the starting point for the questions in the other tabs.
- Regional hosting: EU1 is one of Datadog's listed sites, so an account assigned to it holds its telemetry in that hosted environment.
- Site independence: Datadog documents that sites are independent and that data is not shared between them, which supports a single-region position.
- A fixed boundary to record: The site assignment can be written into your data inventory and risk register as a documented control.
- Scope of the answer: The site addresses where stored data sits, which covers the location element of many residency requirements.
Confirm your organization's site assignment in writing, and check whether metadata, support data or any integration sends telemetry along a different path before you record EU1 as your residency answer.
A site choice answers where data is stored. It does not answer who operates the platform, who can reach the data from outside the region, or which subcontractors handle it during normal operation. Those questions belong in Datadog's contractual terms, its data processing documentation and its security materials, and the answers can change over time. Treat the site as one input to your assessment and collect the operational answers directly from Datadog so they are dated and attributable.
- Operating entity: Confirm which Datadog contracting entity is responsible for your account and which entities operate the EU1 infrastructure.
- Sub-processors: Ask for the current list of sub-processors that may process personal data in telemetry, including cloud hosting and infrastructure providers.
- Support access: Ask where support engineers are located, whether they can view customer data from outside the EU, and what approval a support session requires.
- Cross-border paths: Ask whether any feature, integration, AI-assisted workflow or support process sends data outside the region.
Record each answer in writing and map it to your transfer assessment and vendor review before you rely on EU1 for personal data.
The Datadog Agent is open source in part. Its user space components are published under Apache-2.0 and its eBPF code under GPL-2.0, according to the datadog-agent repository. The Datadog backend and user interface are not open source. That split matters for residency because the code that forms and filters telemetry on your hosts can be reviewed, while the systems that store, index and query that telemetry in EU1 stay under Datadog's control. Your options for verifying the backend are therefore those Datadog provides, not those a self-hosted stack would give you.
- Agent code is inspectable: You can review how the user space components collect and forward data, and pin versions in your build pipeline.
- Backend is closed: The storage, query and access layers in Datadog cannot be run, audited or modified by your team.
- Filtering happens early: Agent and collector configuration can drop or redact fields before data leaves your hosts, which limits what reaches the region.
- Verification has a limit: You can verify what leaves your network, but after arrival you depend on Datadog's documentation and attestations for how data is handled.
Check whether your residency control relies on Datadog's internal controls or on what your own pipeline sends, and record that dependency in your risk assessment.
Retention and deletion are configured per product in Datadog, and the rules that apply to logs, metrics and traces can differ. Residency is only part of the picture if telemetry that holds personal data stays longer than your policy allows, or if deletion requests do not reach copies held elsewhere. Export matters for the same reason: a residency position is weaker if you cannot move data out when the requirement or the vendor relationship changes. Confirm these points in Datadog's written terms rather than relying on default settings.
- Retention settings: Confirm the retention periods for each telemetry type in EU1 and which index or product settings control them.
- Deletion: Ask how deletion requests and account closure remove telemetry, including backups and copies held by sub-processors, and within what period.
- Export paths: Confirm which data can be exported in bulk and which is only reachable through the API, since this shapes any future exit plan.
- Secondary copies: Identify telemetry copied into other Datadog products or into your own storage, and confirm those copies fall under the same residency scope.
Compare Datadog's written retention and deletion terms for EU1 with the periods in your data protection policy before you accept the current configuration.
Which open-source options fit an EU self-hosted telemetry stack
This table compares the open-source components an EU telemetry stack would combine, showing how each keeps data under your control and where it adds work. Read each row for the residency fit, the trade-offs and what to confirm in your own environment before committing. The main takeaway is that residency comes from where you host the components, so the operating model matters as much as the license.
| Option | How it meets residency | Trade-offs | What to confirm |
|---|---|---|---|
| OpenTelemetry | Collector runs in your EU network, so telemetry can be routed to EU-hosted backends only | Collection layer only, not a backend, so you still need storage and query tools | Which exporters and processors your services need, and that no pipeline sends data to a non-EU endpoint |
| Prometheus (Apache-2.0) | Scrapes and stores metrics on servers you choose, inside your EU infrastructure | Local storage is not clustered or replicated, and default retention is 15 days | Retention sizing, a remote write target for longer history, and whether the OTLP receiver flag suits your pipeline |
| Grafana (AGPLv3) | Dashboards and alerting run on your hosts, with user data kept in your own database | SQLite is the default, so production needs MySQL or PostgreSQL and HA setup; SAML needs Enterprise | Database placement in the EU, and whether AGPLv3 terms fit your distribution and modification plans |
| Grafana Loki (AGPLv3) | Log chunks and index sit in object storage you operate in the EU region | Monolithic mode suits up to about 20 GB per day; simple scalable mode is deprecated before Loki 4.0 | Object store location, retention settings, and an authenticating reverse proxy, because Loki has no built-in login |
| Grafana Mimir (AGPLv3) | Long-term Prometheus metrics stored on your EU infrastructure | Adds an extra cluster to run, size and upgrade | Whether you need multi-year metric history and the staff to operate a horizontally scaled system |
| Jaeger (Apache-2.0) | Trace storage runs in your EU environment, graduated CNCF project since October 2019 | Trace search and storage need a separate backend choice and tuning | Storage backend, sampling policy, and whether trace attributes contain personal data to redact |
| SigNoz (MIT core) | Single application that you host in the EU, with traces, logs and metrics in one place | Enterprise directories are separately licensed, and SAML is absent from the free Community Edition | Which directories you would use, whether you need features only in enterprise code, and where ClickHouse storage lives |
How the EU stack keeps telemetry under your control
The core control point is that telemetry only leaves an application when your own collector sends it, and every hop after that stays in EU accounts or data centers you operate. Applications export OpenTelemetry traces, metrics and logs to an OpenTelemetry Collector or Grafana Alloy running in the same EU network. From there, metrics go to Prometheus, logs go to Loki and traces go to Jaeger, with Grafana in front for access. Place these collectors close to the sources, in the same cluster or subnet, so that personal data can be dropped, hashed or redacted by processors before anything is written to storage. Decide early which attributes, such as user identifiers, IP addresses, email fields and request bodies, must never reach a store, and confirm that your collector configuration removes them at that stage rather than relying on later cleanup.
Loki needs more deliberate access design than the other components. Loki has no built-in authentication layer, so you must place an authenticating reverse proxy such as OAuth2 Proxy or Pomerium in front of it, and that proxy becomes part of your personal data access boundary. Multi-tenancy is controlled by auth_enabled and the X-Scope-OrgID header, which identifies the tenant on every request. Treat the header as an identity decision, not a convenience: the proxy should set or verify it from the authenticated user's group, so that one team cannot query another team's logs by changing a header. Confirm this behavior in a test environment with two tenants before go-live, and document who can administer the proxy and the Grafana data sources that point at it.
Grafana sits in front of all three stores and holds the access rules that users actually touch, so its configuration is part of the residency evidence. Use MySQL or PostgreSQL rather than the default SQLite for production, and run the Grafana security hardening settings on the EU deployment. Check which identity features your Grafana edition provides, since SAML and SCIM are reserved for Grafana Enterprise and Grafana Cloud according to the authentication documentation, and plan an OAuth or LDAP integration if you run the open-source edition. Keep the entire data path, including backups and the object store that holds Loki chunks, under the same EU controls. Ask your own legal and security owners to confirm which personal data categories your telemetry carries, because the Datadog EU1 site is a separate hosted service and this design only settles residency if the whole path is yours.
How to deploy the EU stack and move telemetry without leaving the region
This sequence sets up a self-hosted Grafana, Prometheus and Loki stack inside your EU infrastructure, routes OpenTelemetry telemetry to it, and retires the Datadog export only after the new stack has been verified.
Classify telemetry and fix EU locations
Security, data protection and platform leads list which telemetry carries personal data, such as user identifiers in logs, request paths or session attributes, and which systems must stay under EU control. They also name the EU regions, data centers and object storage buckets that will hold metrics, logs and Grafana configuration. The step is done when every telemetry source has a classification and a named location, and the owner of each location is recorded. Ask your DPO and counsel to confirm the classification, because the legal basis for processing is your decision, not this page's.
Deploy Grafana on MySQL or PostgreSQL
The platform team installs Grafana from the packages or container images the installation docs list, then points its configuration database at MySQL 8.0 or later or PostgreSQL 12 or later. SQLite is only suitable for evaluation, because the docs state it does not scale for production. For high availability, they run two or more active-active Grafana servers behind a load balancer on the same database, and they check the high availability notes on duplicate alert notifications and Grafana Live limitations. Done means the instance restarts cleanly with its state held in the external database.
Deploy Prometheus with EU remote write
Operators run Prometheus on EU infrastructure with an explicit retention setting, because the default local retention is 15 days. Local storage is single-node and not replicated, so it is managed like any other single-node database. For longer history, they configure remote write to an EU-hosted long-term store such as Grafana Mimir, which is AGPL-3.0-only and built for Prometheus metrics. Alertmanager runs as a cluster, and Prometheus is pointed at every Alertmanager instance rather than a load balancer. Done means test series appear in the remote store and an alert reaches its receiver.
Deploy Loki on EU object storage with retention
Choose monolithic mode for smaller log volumes, which the docs size up to about 20 GB per day, or simple scalable mode for larger volumes, noting that the docs say simple scalable mode is deprecated and will be removed with Loki 4.0. Store chunks and the TSDB index in an EU object store from Loki's recommended list, such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and confirm the region with the provider. Set auth_enabled to true so each request carries an X-Scope-OrgID tenant ID, and set retention_enabled in the compactor, because retention is off by default. Done means a log line written under one tenant ID is not returned for another.
Add the authenticating proxy and harden Grafana
Loki has no built-in authentication, so the team places an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and maps each user or service to a tenant. In Grafana, they connect the identity provider using a supported method, and they confirm SAML or SCIM are available only in Grafana Enterprise or Grafana Cloud before promising them. They apply the security hardening settings, including secure and SameSite cookies, a Content Security Policy, hiding the version from unauthenticated users, authenticated access to the metrics endpoint and domain verification. Done means unauthenticated requests to Loki and Grafana are refused in a test.
Instrument applications with OpenTelemetry
Developers replace Datadog-specific libraries with OpenTelemetry SDKs or auto-instrumentation and send data to a standard OpenTelemetry Collector running in the EU. The Collector exports metrics to Prometheus, using its OTLP receiver at the documented path when enabled, and logs to Loki through its OTLP HTTP endpoint or through Grafana Alloy, the supported shipper. Traces go to Jaeger or another OpenTelemetry-compatible backend that the team has chosen and tested. Done means each service shows up in the new dashboards with the resource attributes that your alert rules depend on.
Dual-ship to Datadog and the new stack
During cutover, the Collector sends the same telemetry to Datadog over OTLP and to the EU stack in parallel. Teams compare dashboards, alert rules and log counts for an agreed period, and they check that personal data classified in step one is filtered or masked before it reaches any destination that is not approved for it. Datadog's EU1 site is still a Datadog-hosted service, so the parallel period is also when legal review confirms what the Datadog contract and site settle. Done means the sign-off record names each dashboard, alert and log source that has been checked.
Stop the Datadog export
After sign-off, the team removes the Datadog exporter from the Collector pipelines and disables any remaining Datadog Agent log or metric forwarding, then confirms that no personal data flows to Datadog from any source on the inventory. They keep the Datadog account and its archives available for the retention period required by the business and their legal advisers, and they record the date the export stopped. Done means the Collector configuration and the data flow diagram both show EU-only destinations, and the change is recorded in the audit trail.
Evidence auditors and data protection teams ask for
Residency claims only hold up when you can show where each store lives, how long data is kept, who can reach it and which versions run. The cards below list the records to assemble, and DeployOpen can prepare this evidence, while independent auditors and certification bodies are the ones who issue audit reports and attestations.
Data location records per store
Keep a register that names each store holding telemetry, including Prometheus local storage, Loki object storage buckets, Grafana's configuration database and any backup targets, with the EU region, the data center operator and the host or cluster it runs on. Auditors will compare this register against network diagrams and cloud account configuration. Confirm that replicas, snapshots and log shipper buffers are listed too, since they are common places where personal data is copied outside the intended region.
Retention configuration exports
Export the effective retention settings from each component and store them with the change history. In Prometheus, retention is set by time or size and defaults to 15 days. In Loki, retention is disabled by default and logs are kept indefinitely until retention_enabled is set, so an export that shows no retention rule is a finding in itself. Record which rules apply per tenant or per stream selector.
Access control and SSO configuration
Document how operators and users sign in to Grafana and how Loki tenants are separated. Grafana's authentication docs list LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth in all editions, but SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your policy requires SAML or SCIM, budget for Grafana Enterprise or choose an OAuth or LDAP path. Loki has no built-in authentication, so the reverse proxy configuration must be part of the evidence.
Sub-processor and transfer records
List every SaaS or hosted service that still receives telemetry, such as a commercial backend kept during dual-running, a hosted alerting relay or a support tool that sees log excerpts. For each, record the processing purpose, the data categories, the processing region and the contract terms covering transfers. Self-hosted components do not need a sub-processor entry, but an empty list must be confirmed against the actual egress rules, not assumed.
Hardening settings
Export the Grafana security configuration and the proxy settings in front of Prometheus, Loki and Grafana. Grafana's hardening guidance covers secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, authentication on the metrics endpoint and domain verification against DNS rebinding. Attach the evidence that each setting is applied, not only the intent in the runbook.
Version and patch records
Maintain a dated inventory of the running version of Prometheus, Grafana, Loki, OpenTelemetry Collector and Alloy, and the patch history for each. Prometheus minor releases stop receiving bug fixes after six weeks, while LTS lines receive fixes for one year, so the record should show which line you run and when it was last patched. Grafana patch releases come at least monthly, and each minor release is supported for 9 months. Auditors will ask for proof that these were applied on schedule.
Questions buyers ask before moving EU telemetry off Datadog
Does Datadog's EU1 site settle data residency on its own?
No. EU1 keeps telemetry in a regional Datadog site, and Datadog's documentation describes each site as completely independent, with data not shared across sites. That does not answer every residency question. It does not show who can access the data, where support staff operate, which subprocessors touch telemetry, or how your contract defines data location. Ask Datadog for its current data processing terms, subprocessor list and access model, then check your regulator's expectations with your legal and compliance team. Datadog's site documentation is the place to start. Self-hosting moves these answers into your own infrastructure, but you then own the controls Datadog currently runs for you.
What does moving EU telemetry off Datadog cost?
The cost comes from several components, and no single figure applies to every team. Prometheus is Apache-2.0 licensed, and Grafana, Loki and Jaeger are open source, so the software itself carries no license fee. You pay for compute and storage for each backend, for the staff who run and upgrade them, for implementation work, and for a period when Datadog and the new stack run side by side. Infrastructure, storage and operations recur every month. Implementation and migration are largely one-time. Data volume, retention length, metric cardinality and the number of environments push costs up. Ask any implementation partner for a quote built on a written scope that lists each deliverable, the environments covered and the length of the dual-running period.
How long does an EU self-hosted telemetry migration take?
Timelines depend on scope and on your team more than on the software. The main variables are how many services emit telemetry, whether instrumentation already uses OpenTelemetry, how many dashboards and monitors need rebuilding, and how quickly your security and data protection reviews approve EU hosting. A small proof of concept can be stood up faster than a production platform, because production needs high availability, backups, authentication and retention decisions. Loki's deployment mode also depends on daily log volume. No general duration applies, so agree the schedule in the written scope and tie milestones to cutover, dual running and decommissioning of Datadog agents.
Can our team run this stack without outside help?
Some teams can, particularly if they already operate Linux or Kubernetes services, have on-call coverage for infrastructure and have engineers who can own the upgrade path. Running the stack means operating Prometheus, which is a single-node database that is not clustered or replicated by default, keeping Alertmanager highly available, configuring Grafana with MySQL or PostgreSQL for production, and placing Loki behind an authenticating reverse proxy. Grafana supports each minor release for 9 months, so upgrades are recurring work. Assess these skills honestly. An outside team can plan, implement, harden, back up and document the stack, hand it over, and optionally stay on a retainer for upgrades and continuous support.
What do Grafana Cloud or Grafana Enterprise change for residency?
Grafana Cloud moves hosting to Grafana Labs, so it changes who operates the data and where it sits, which is the central residency question. Confirm the hosting region, subprocessors and contract terms in writing before treating it as EU-controlled. Grafana's pricing page lists a free tier, a Pro tier with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Grafana Enterprise is a commercial, non-AGPL edition of the software you would run yourself. It adds SAML, team sync, active sync and SCIM provisioning, which are not available in the open edition. A commercial license does not change where your data is stored, so self-hosting either edition keeps telemetry in your own infrastructure.
How do we handle personal data in traces and logs?
Decide what must never be collected before choosing a backend, because removing data after it lands is harder. List which span attributes, log fields and URL parameters can carry personal data, then filter, hash or drop them in the OpenTelemetry Collector before export, so the same rule applies to every backend during dual running. Set retention explicitly in Loki, because the compactor keeps logs indefinitely until retention is enabled. Restrict access as well, since Loki has no built-in authentication and needs an authenticating reverse proxy in front of it. Prometheus defaults to 15 days of local retention. Record these rules in your data protection impact assessment and confirm them with your data protection officer.
Does self-hosting make us compliant with an audit?
No. Self-hosting gives you control over where telemetry is stored and who can reach it, but it does not create compliance on its own. DeployOpen prepares systems, controls and evidence for compliance assessments. Independent auditors and certification bodies issue audit reports, attestations and certifications, not DeployOpen. Ask your assessor early which evidence they expect, such as access reviews, backup and restore tests, retention settings and change records. Build the stack so that this evidence is produced as part of normal operation, not assembled at audit time.
How DeployOpen builds an EU-resident telemetry stack
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including your EU cloud accounts, data centers or networks. For EU telemetry, that means starting from where personal data appears in logs, traces and metrics, then deploying the collection and storage path under your control.
How we scope
- The written scope names which services, hosts and log sources send telemetry, and where each signal is stored.
- Scope records which telemetry fields may contain personal data and how they will be masked or dropped at collection.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The quote follows from the written scope, so the reader can see which components and environments are covered.
How we build
- OpenTelemetry Collector pipelines are configured to route traces, metrics and logs to components inside your EU network.
- Prometheus, Grafana and Loki are deployed in your chosen environment with storage, retention and access controls set as agreed.
- Grafana authentication, Loki tenant headers and an authenticating reverse proxy in front of Loki are configured and tested.
- Security testing covers the telemetry endpoints and the access paths to dashboards and log queries before handover.
How we hand over
- Handover documentation describes data flows, data locations, retention settings and who holds administrative access.
- Dashboards, alert rules and provisioning files are stored as code so changes can be reviewed and rebuilt.
- Evidence for compliance assessments, such as configuration records and access settings, is prepared for your independent auditors.
- Operators receive runbooks for backups, upgrades and recovery of the stack, which DeployOpen does not certify on your behalf.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade plans follow the upstream release cycles for Prometheus, Grafana and Loki, which your team can confirm against each project's documentation.
- Periodic reviews check retention, storage growth and access changes against the agreed data residency requirements.
- Your legal and compliance teams remain responsible for confirming residency obligations with your own advisers and regulators.
