Self-hosted New Relic alternative for EU data residency

Is a self-hosted New Relic alternative needed for EU data residency?

An EU region is sometimes enough for a regulated EU organization and sometimes not, and the answer depends on whether telemetry leaves the EU, who can compel access to it, and where it is physically stored. Telemetry that carries personal data, such as user identifiers in trace attributes, IP addresses in logs or account details in error payloads, falls under the GDPR. Under EDPB Guidelines 05/2021, remote access from a third country, even only displaying data on a screen for support, counts as a transfer, so the question is not only where the data is stored but also who in another country can see it. New Relic offers US, EU and Japan regions, but it does not move existing account data between them, so the region chosen at account setup is the one that governs that data. Confirm with New Relic in writing which region your account uses, where support staff access originates, and what happens to data if you later change regions.

A regional choice does not settle foreign access. The US CLOUD Act provision at 18 U.S.C. 2713 applies to providers regardless of where the data sits, and the EDPB Recommendations 01/2020 state that where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Your legal team should therefore document the transfer assessment for any vendor option, and treat the Data Privacy Framework as a condition to verify rather than a fixed guarantee, since its adequacy decision is under appeal (Case C-703/25 P). If your risk analysis rules out third-country exposure, the short answer is to keep telemetry in your own data center or cloud account and run an OpenTelemetry pipeline into self-hosted SigNoz or Grafana with Prometheus. SigNoz publishes an EU-hosted cloud option, but a self-hosted deployment is the only option here where you control the infrastructure, access paths and retention settings.

What EU data residency requires for telemetry

Telemetry often carries personal data such as user identifiers, IP addresses and session details, so where it is stored and who can reach it are GDPR questions, not only IT ones. The cards below are requirements to test against any hosted provider, including an EU region, before you decide whether a self-hosted stack is needed.

Transfers include remote access

GDPR Article 44 applies to every transfer of personal data to a third country, including onward transfers, and infringements of Articles 44 to 49 can carry fines of up to EUR 20 million or 4% of worldwide annual turnover. The EDPB guidelines treat storage in a cloud outside the EEA, and remote access from a third country even only to display data for support, as transfers. Ask your provider which staff in which countries can open telemetry, including support engineers, and whether any sub-processor stores copies outside the EEA.

Region choice does not move data

A provider's EU region is only a residency answer for data created in that region. New Relic documents US, EU and Japan regions but does not move existing account data between them, so a region change usually means a new account and a re-ingest. Confirm in writing where backups, logs, traces and support copies are kept, and whether a region migration would require re-instrumenting your services.

US reach under the CLOUD Act

18 U.S.C. 2713 requires providers subject to US law to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. An EU data center operated by a US company can therefore still be reachable by a US order. Ask whether the provider has a documented process for government requests, whether it notifies customers, and which legal entity holds your contract.

Third-country access and Article 48

GDPR Article 48 allows a foreign court order to be recognized or enforced in the EU only when it rests on an international agreement, such as a mutual legal assistance treaty. Where a processor must give a third-country authority data in the clear, the EDPB Recommendations 01/2020 state that it cannot see an effective technical supplementary measure. Document this assessment before you engage a provider, and record whether encryption keys are held by you or by the provider.

Schrems II and the DPF status

The Court of Justice invalidated the EU-US Privacy Shield in Case C-311/18 (Schrems II) on 16 July 2020, while holding that standard contractual clauses remained valid. Commission Implementing Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Contract clauses and certification may not settle the question if that appeal succeeds, so ask whether your contract has a fallback transfer mechanism.

Exit rights under the Data Act

Regulation (EU) 2023/2854 applies from 12 September 2025 and gives customers the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Article 32 also requires providers to prevent third-country governmental access to non-personal data held in the Union where it would conflict with Union or national law. Use these rights to write an exit plan into the contract, including export formats for telemetry and retention.

Where New Relic's EU region meets the constraint and where it may not

The region choice is the first decision, and it must be made before any telemetry is sent. The supplied facts show that New Relic offers US, EU and Japan regions and supports native OTLP ingest, so OpenTelemetry exporters can point at an EU endpoint from the start. The gap is that existing account data does not move between regions. If you already run a US account with production telemetry, moving that history into the EU is a migration project in its own right, with a parallel period, rebuilt dashboards and alert conditions and a decision on what to keep in the old account. Confirm with New Relic which data types, retention periods and account settings are tied to a region, and whether any historical export path is available for the data you need to keep.

A regional endpoint answers only where the data is stored and processed. It does not answer who can reach it. Under the EDPB Guidelines 05/2021, remote access from a third country, even only displaying data on a screen for support, counts as a transfer, so the support and engineering access model matters as much as the storage location. Ask New Relic in writing where its support staff and subprocessors access customer data from, which subprocessors touch telemetry in the EU region, and how it responds to a request from a non-EU public authority. The CLOUD Act at 18 U.S.C. 2713 reaches US-headquartered providers regardless of where data sits, so the EU region does not remove that exposure on its own. Record the answers in your transfer impact assessment and in your DPA review rather than assuming them.

When an EU region is enough and when telemetry must stay in your own data center

A hosted EU region is most likely sufficient when telemetry carries little personal data, or when any personal data stays in the EU with contractual and transfer safeguards that your counsel has accepted. In this case the architecture change is mostly about configuration: choosing the region before any data arrives, and keeping the OTLP endpoint and support access inside the EU. New Relic offers an EU region, but it does not move existing account data between regions, so the choice must be made at account setup.

Data classification: list which span attributes, log fields and user identifiers could identify a person, and remove or hash the ones you do not need.
Region at setup: decide the region before the first OTLP export, because existing account data does not move later.
Transfer safeguards: where any transfer remains, the standard contractual clauses in Commission Implementing Decision (EU) 2021/914 are the usual basis, and counsel should review the executed terms.
Vendor access paths: confirm where support staff can view data, since remote display from a third country counts as a transfer.

Check with your counsel and the vendor's data processing documentation before treating an EU region as the end of the residency question.

Which open-source options keep telemetry under your control

This table compares SigNoz, Grafana with Prometheus and Jaeger, and Zabbix on where telemetry is stored, who controls access, and what each license requires. Read each row as a checklist of what your team must still build, confirm or decide, because a self-hosted option only keeps data in your environment if you run it there. The main takeaway is that residency is set by your deployment, not by the license.

Option	How it keeps data in your environment	Residency and access trade-offs	Licensing notes
SigNoz (self-hosted)	The OpenTelemetry Collector receives telemetry and writes it to ClickHouse, all inside your own cluster, with Docker or Kubernetes Helm installs.	You choose the host location and admins. Confirm where backups and ClickHouse replicas sit, and who holds database credentials.	MIT outside the ee/ and cmd/enterprise/ directories. Confirm which features you need sit outside those enterprise paths.
SigNoz Community Edition	Free self-hosted build with APM, tracing, logs, infrastructure monitoring and alerting, all stored on your servers.	Lacks SAML, SOC 2 and HIPAA compliance, anomaly detection and prebuilt integrations. Support is community Slack only, so confirm your own assessor's expectations.	Free to run. Confirm whether SSO without SAML meets your identity requirements.
SigNoz Cloud (for comparison)	Hosted in US, EU or India data centers, so telemetry leaves your own infrastructure.	Data residency is set by the chosen region. Ask whether any support access or subprocessors sit outside the EU.	Commercial plans. Confirm current terms with SigNoz before relying on them for EU residency.
Grafana with Prometheus	Prometheus scrapes or receives OTLP metrics on your hosts. Grafana reads them from your own database and dashboards.	Grafana production needs MySQL or PostgreSQL, and high availability needs two or more active-active servers. SAML is only in Enterprise or Cloud.	Grafana is AGPL-3.0-only since Grafana 8.0. Prometheus is Apache-2.0. Confirm AGPL obligations with your legal team.
Jaeger for traces	Stores distributed traces in a backend you operate, fed by OpenTelemetry instrumentation.	Choose the storage backend yourself and confirm it keeps trace data in the approved region. Jaeger v2 is built on OpenTelemetry Collector components.	Apache-2.0 and a graduated CNCF project since October 2019.
Grafana Mimir for scale	Long-term, horizontally scalable storage for Prometheus metrics in your own object storage.	Adds components you operate. Confirm object storage location and retention rules meet your residency policy.	AGPL-3.0-only, the same as Grafana.
Zabbix (infrastructure-led needs)	Self-hosted server, proxies and agents collect host and network data inside your network.	Suited to infrastructure data more than APM traces. Confirm it covers your residency scope without a separate tracing store.	AGPL-3.0 from Zabbix 7.0. Versions up to 6.4 remain GPL-2.0. Support subscriptions are optional.

How to deploy SigNoz or Grafana with Prometheus under EU control

This sequence moves telemetry from a hosted New Relic account to a self-hosted backend in a region and data center you choose, with access, configuration and cutover checked at each stage.

Inventory telemetry and map each data region
Your platform and security owners list every telemetry source (APM agents, OTLP exporters, infrastructure hosts, logs and browser data), the personal data each one can carry, and the country or data center where it is processed and stored. Compare this map with your transfer analysis, including whether any support staff or processor outside the EEA can view data on screen, since the EDPB treats that as a transfer. The output is a signed-off register that names the target location for every data class. Confirm with your legal and privacy team before you pick a hosting region.
Route OTLP through a self-hosted OpenTelemetry Collector
Platform engineers point applications at an OpenTelemetry Collector running inside your network instead of at New Relic's OTLP endpoint. The Collector applies redaction, filtering and sampling rules, then exports to SigNoz or to Prometheus and Jaeger. Keep the New Relic exporter in a separate pipeline so both paths can run at once. You know this step is done when a test trace and metric appear in the self-hosted backend with the expected resource attributes and no personal fields that policy forbids.
Choose the SigNoz or Grafana deployment model
Architects select Docker Standalone, Docker Swarm or Kubernetes with Helm for SigNoz, as documented in its self-host install guides, or a Grafana deployment with Prometheus for metrics. For Grafana in production and high availability, plan a MySQL 8.0 or later or PostgreSQL 12 or later database, because the Grafana installation docs say SQLite does not scale for production. Confirm storage, retention and ClickHouse sizing with your own load tests, since no sizing figures for your workload are established here. The decision is recorded with the region, database and backup owner named.
Configure SSO, access and provisioning
Identity engineers connect the backend to your identity provider. For SigNoz, SSO is available on every plan including Community Edition, but SAML needs Teams or Enterprise. For Grafana, check the authentication docs before you commit: SAML, team sync, active sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, so the open-source edition relies on LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy or JWT. Store data sources, dashboards and alert rules as YAML or JSON provisioning files in Git. Apply the Grafana security hardening settings (secure and SameSite cookies, a Content Security Policy, Trusted Types, hidden version, authenticated metrics endpoint and domain verification) and verify each with a test login.
Run both backends in parallel and compare
For a set period agreed in your plan, the same OpenTelemetry stream feeds New Relic and the self-hosted backend. Engineers compare trace completeness, metric values, log coverage and alert firing on the same incidents. Track which dashboards and alert conditions still depend on NRQL and need rebuilding. Confirm that each Grafana alert is set so it does not send duplicate notifications when running in high availability, as the Grafana HA docs warn. The step closes with a written gap list that the owners accept.
Cut over and restrict access paths
After the gap list is closed, platform owners remove the New Relic exporter from production pipelines, keep the archived export for records under your retention policy, and disable any remote support paths that could show EU data to staff outside approved locations. Review network policies so only the Collector, the backend and approved administrators reach the databases and ClickHouse nodes. Test backups and a restore into a second instance. The step is done when access logs show no traffic to the old endpoint and the restore test passes.
Operate, patch and document the EU controls
Operations staff apply Grafana patch releases, which Grafana says arrive at least monthly, and SigNoz upgrades on the cadence in its release notes. They keep the data register, transfer assessment, access reviews and restore test results current so that auditors can inspect them. Costs recur through infrastructure, storage, database operations and staff time, and grow with retention and ingest volume. DeployOpen can plan, implement and document this sequence under a fixed-scope agreement, but independent auditors and certification bodies decide compliance outcomes.

What auditors and regulators ask to see for telemetry residency

Residency claims about telemetry are only as strong as the records behind them. The four items below connect the data itself, the legal basis for any transfer, the locations and access paths of every backend, and the pipeline that moves the data. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient.

Data map of telemetry fields

A data map lists every telemetry field that can carry personal data, such as user identifiers in trace attributes, IP addresses in access logs, email addresses in error messages, or session identifiers in browser data. For each field, record the source, the signal type, the retention period and the systems it reaches. Check whether scrubbing or attribute filtering happens in the Collector before export, because a field that is removed at the edge is treated differently from one stored in ClickHouse or Prometheus. Ask engineering teams to review sample payloads, not only the schema.

Transfer assessment and contracts

Where any copy of telemetry leaves the EEA, including remote access from a third country, the GDPR transfer rules apply. Keep the transfer assessment, the data processing agreement and the standard contractual clauses that cover each vendor and sub-processor in the telemetry path. Record whether the vendor's support staff can view data from outside the EEA. Our reading of the EDPB guidance is that a remote view counts as a transfer, so support access belongs in the assessment, not only storage locations. Have counsel confirm the analysis.

Backend and backup location register

Maintain a register that names each backend, storage volume, replica and backup target, with its physical location, the legal entity that operates it and the people or service accounts that can read it. For a self-hosted stack, this covers the Prometheus or ClickHouse storage nodes, object storage used for long-term retention, backup copies and any disaster recovery site. Include administrative access paths, such as jump hosts and vendor remote sessions. Auditors often find the backup copy that was not on the original diagram, so trace it from the source to the last copy.

Collector configuration and access logs

The OpenTelemetry Collector configuration shows where telemetry is routed, which exporters are active and which processors remove or hash fields. Version-control these files and keep the change history, since a changed exporter endpoint is a transfer event. Pair the configuration with access logs for the query layer, the admin console and the storage nodes, showing who queried which data and when. Confirm log retention and whether the logs themselves contain personal data, because they are part of the evidence set too.

Questions EU teams ask before a self-hosted monitoring move

How much does a self-hosted monitoring stack cost compared with New Relic?

The honest comparison is by cost component, not a single number. New Relic bills by GB ingested regardless of data type, includes 100 GB ingested per month free, and charges per user type across Basic, Core and Full platform users, according to New Relic's pricing and billing documentation. A self-hosted stack replaces those fees with compute, storage sized to your retention, backup, networking, and the staff time to run upgrades and on-call. The one-time costs are instrumentation changes and rebuilding dashboards and alerts. The recurring costs scale with telemetry volume and retention, so ask any partner to model both against your actual ingest and retention periods before comparing totals.

How long does a migration to a self-hosted monitoring stack take?

Duration depends mainly on how many services already send telemetry through OpenTelemetry, how many dashboards and alert conditions must be rebuilt, and how long you run both backends in parallel before cutover. Services already on OTLP can be pointed at a self-hosted Collector with a configuration change, while services using proprietary agents need re-instrumentation. Alert rebuilds and parallel running usually take the most calendar time because they need owner sign-off. Ask for a written scope with the list of services, dashboards and alerts in it, since fixed-scope work is agreed in writing before it starts.

What does the work need from our own engineering and security teams?

Your team provides access to the environments, a list of owners for each service, the current New Relic configuration, and decisions on retention, data masking and who may see which telemetry. Platform engineers need to approve where the Collector, storage and backends run, and security teams need to review access control, encryption and network paths. Expect owners of critical services to validate that traces, metrics and alerts match what they relied on before. Without those inputs, the migration stalls at the decision points rather than at the technical work.

Can we run a self-hosted monitoring migration in-house?

Yes, if your team already runs Kubernetes or similar infrastructure, operates a time-series database and has capacity for on-call on its own monitoring. The stack components, including the OpenTelemetry Collector, Prometheus, Grafana, Jaeger and SigNoz, are open source, so the license cost is zero, but the operations burden shifts to you. Teams without that experience usually find upgrades, high availability and storage scaling the hardest parts. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your infrastructure, and that work can be scoped alone or alongside your own staff.

Is an EU region of New Relic enough for our data residency requirement?

An EU region can satisfy some requirements, but it depends on your legal analysis, not on the region name alone. New Relic offers US, EU and Japan regions and does not move existing account data between them, so the region is chosen when the account is set up. Under GDPR, remote access from a third country and storage outside the EEA are transfers, and the EDPB Guidelines 05/2021 address this in detail. Whether a US-operated provider's region meets your needs also depends on third-country access laws such as the US CLOUD Act provision at 18 U.S.C. 2713. Take this question to your data protection officer and counsel before deciding.

What happens to our existing New Relic data when we move?

New Relic does not move existing account data between regions, and telemetry already stored there stays under its retention settings until it expires. The usual approach is to run both backends in parallel, keep New Relic for historical lookups during the retention period, and send new telemetry to the self-hosted stack. If you need to keep historical data, New Relic's NerdGraph historical data export is a separate project with its own requirements. Under the EU Data Act, customers have the right to switch from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027 (Articles 25, 29 and 50). Confirm the terms of your own contract with the vendor.

Do we need to keep telemetry in our own data center to meet EU requirements?

Not always, but telemetry that contains personal data or sensitive operational details needs a documented decision. The options range from a provider-hosted EU region, to a self-hosted stack in an EU cloud account, to a fully on-premises deployment. The more sensitive the data and the more third-country access exposure your provider has, the more likely you will choose your own infrastructure. Options such as SigNoz Cloud also offer EU data centers, while SigNoz Enterprise can be self-hosted with enterprise support. Your legal and security teams should map each data type to a location and a control before choosing the architecture.

How the Data Act switching right affects an exit from a hosted region

The EU Data Act switching rights give customers of data processing services a route out of a hosted provider, and they matter when you move telemetry from a hosted region to infrastructure you control. The Data Act has applied since 12 September 2025. It gives customers the right to switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027 (Articles 25, 29 and 50 of Regulation (EU) 2023/2854). These rules are written for data processing services in general, not for observability tools specifically, so whether your New Relic agreement, or a SaaS contract with another vendor, falls within scope is a question for your legal team.

Before you rely on the right, confirm three things in your contract and order documents: whether the agreement is a data processing service under the Act, what notice period and transition terms it sets out, and whether any switching or egress fees apply before or after the 2027 ban. Also check how historical data can be exported, because a switching right does not guarantee that dashboards, alert conditions or retained telemetry arrive in a usable format. Ask the vendor in writing for its switching procedure and the export formats it supports. The full text of the Act is available from EUR-Lex, and it is worth reading Article 32 alongside the switching articles, since it concerns third-country governmental access to non-personal data held in the Union.

Plan the exit as an engineering project with its own timeline, not as a contract event. Running OpenTelemetry Collectors in parallel with your current backend gives you a stable source of data during the transition, so the switching notice period does not force a rushed cutover. Treat the two-month notice and 30-day transition as the contractual minimums, then schedule the rebuild of dashboards and alert rules inside that window. Confirm the dates with the vendor and with counsel, and record them in your migration plan, since the Act's terms apply to the contract you actually signed.

How DeployOpen deploys self-hosted observability under EU residency constraints

DeployOpen plans and implements self-hosted observability inside your own cloud accounts, data centers or air-gapped networks, so telemetry stays where your residency obligations require. We start by fixing where each signal is processed and stored, then build, test, document and hand over the stack in writing agreed before work begins.

How we scope

We map which telemetry carries personal data, where each signal is produced and which staff or vendors can reach it.
The written scope names the backend options, such as SigNoz, Grafana with Prometheus, or Jaeger, and the hosting location for each.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.

How we build

We deploy the OpenTelemetry Collector, storage and query layers in your environment, with the database and retention settings confirmed by your team.
We configure authentication, network paths and access controls so remote administration does not create an unplanned transfer outside the EEA.
We test ingestion, dashboards, alerts and failover, and verify the stack against your residency and retention requirements before cutover.

How we hand over

You receive architecture diagrams, data flow maps, configuration as code, runbooks and the backup and upgrade procedures for the deployed stack.
Residency evidence such as data location records and access lists is prepared for your compliance team and independent assessors, who decide what they accept.
Knowledge transfer sessions walk your operators through alerting, scaling and troubleshooting, so your team can run the platform after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped separately from the original project.
Retainers can cover tracking of supported release lines and patch application, so your team plans upgrades against published schedules.
Periodic security testing of the observability stack and its access paths can be added to a retainer, with findings reported to your team.