Self-hosted Sentry alternative for EU data residency

Why a self-hosted Sentry alternative for EU data residency keeps errors in the EU

A regulated EU team whose error reports, stack traces and user identifiers must stay in the EU needs to know one thing before choosing a tool: Sentry's EU region keeps accounts, tokens, DSN keys and audit logs in the US, and the region cannot be switched after creation. Self-hosted GlitchTip in an EU data center is the short answer, because events and account data then sit on servers the organization controls. This page covers the requirements that drive the decision, the options that meet them, how to deploy and operate the system, and the evidence an assessor will ask for. DeployOpen plans, implements and hardens that work inside the client's own infrastructure. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that.

Start the analysis with the transfer map, not the hosting label. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and the EDPB's guidelines treat remote access from a third country, even only displaying data for support, as a transfer. A US-hosted account store therefore matters even when event payloads sit in an EU region. The US CLOUD Act provision at 18 U.S.C. 2713 reaches data a US provider holds regardless of location, and the EDPB has said that where public authority powers go beyond what is necessary and proportionate, it cannot envision an effective technical supplementary measure. Map each data category (events, user context, DSN keys, audit logs and support access) to a location and a legal exposure, and ask counsel to review that map with the EDPB Recommendations 01/2020 in hand.

On the GlitchTip side, the deployment choices are concrete. GlitchTip's backend is a MIT-licensed Django application that requires PostgreSQL 14 or later, with Valkey or Redis 7 or later as an optional add-on. Use Docker Compose for a single server or the Helm chart for Kubernetes, and place an external managed database inside the EU boundary, as the installation documentation recommends for Helm. Because GlitchTip accepts Sentry client SDKs, applications usually need only a DSN change. Evidence for the assessor typically includes the data flow diagram, a sub-processor list for every hosting and support path, access reviews, and a record of DSN and token rotation. Confirm each hosting provider and remote support route in writing before go-live.

What GDPR and the transfer rules require for error tracking data

Error events often carry user identifiers, IP addresses, request data and stack context, so they count as personal data under GDPR. The cards below cover the rules that decide where that data may be stored, who may access it from outside the EU, and what happens when a foreign authority asks for it.

Transfers and Chapter V

Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. For error tracking, the question is not only where the primary database sits but also where backups, support access and subprocessors touch event payloads. Ask your provider to list every location where account data, DSN keys and events are stored or processed, and check each one against your transfer map.

Remote access counts as a transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when data is only displayed on a screen for support or administration. Storage in a cloud outside the EEA is also a transfer. A vendor engineer in another country who opens an event to debug a crash therefore creates a transfer, which is why access controls and support procedures belong in the residency review.

Fines for transfer breaches

Infringements of Articles 44 to 49 fall under the higher fine tier in Article 83(5)(c), with a ceiling of EUR 20 million or 4% of worldwide annual turnover, whichever is higher. The ceiling applies to the controller and the processor, so the choice of error tracking vendor is part of your compliance exposure. Treat the fine figure as a ceiling, not an expected penalty, and document the transfer assessment before data flows.

Schrems II and the Data Privacy Framework

The Court of Justice invalidated the EU-US Privacy Shield in Case C-311/18 (Schrems II) while keeping standard contractual clauses valid. Commission Implementing Decision (EU) 2023/1795 finds adequacy only for US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. Check whether your provider is certified under the framework, and record a fallback transfer mechanism and a plan in case the adequacy finding changes.

Third-country disclosure orders

Article 48 allows a foreign court or authority order requiring disclosure of personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty. The US CLOUD Act at 18 U.S.C. 2713 can still reach data a US provider holds in its possession, custody or control, wherever it is stored. EDPB Recommendations 01/2020 note that where a provider must access data in the clear and foreign powers exceed what is necessary, no effective technical measure may exist. Keeping data on infrastructure you operate in the EU reduces this exposure, and that is a question to put to every candidate provider.

Where Sentry's EU region stops short of full EU residency

Sentry's EU region does not keep every category of data in the EU. Account records, API tokens, DSN keys and audit logs remain in the United States, and the region chosen when an organization is created cannot be switched later. Event data is the part most teams picture when they choose an EU region, so this gap is easy to miss. Before selecting a region, list the data categories your compliance owner treats as personal or sensitive, then map each one to where Sentry stores it. DSN keys deserve particular attention because they are embedded in client applications and are visible to anyone who can load the page. Confirm the current data location statements directly with Sentry in writing, and keep the answer with your record of processing.

For a US-headquartered provider, the main question is legal reach as well as location. Under 18 U.S.C. 2713, added on 23 March 2018, electronic communication and remote computing service providers must preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. An EU region changes where the data is stored but does not by itself remove the provider's obligations under US law. EDPB Guidelines 05/2021 add that storage in a cloud outside the EEA is a transfer, and that complying with a third-country authority's request would also be a transfer, so controllers should assess that exposure before engaging such a provider. This does not establish that Sentry has received such a request. It is a reason to ask Sentry what it would do if one arrived.

Put these questions to Sentry in writing and file the answers: which data categories are stored in each region, where DSN keys, tokens and audit logs are held, from which countries support staff can access them, which sub-processors are involved, and what the contract says about government requests. Note also that transfers to US organizations rely on the Data Privacy Framework, and an appeal in Case C-703/25 P is pending, so the legal position could change after you decide. If the assessment shows that account and event data must stay under your control, self-hosted GlitchTip in an EU data center moves both under your own infrastructure and administration. Hosting location, backups and access rules then become decisions your team or implementation partner must document.

Which open-source options meet an EU residency constraint

This table compares self-hosted options for keeping error events and account data inside the EU, along with the licence, the database requirement and the feature gaps. Read each row for where data is stored, then check the trade-offs against the Sentry features your teams use. GlitchTip gives the most direct residency path for error tracking, while session replay or a wider observability stack needs a separate tool.

Option	Data control in your EU data center	Licence and requirements	Trade-offs
GlitchTip (self-hosted)	Events, accounts, DSN keys and alerts stay in the database and servers you choose.	Backend is MIT licensed. Requires PostgreSQL 14 or later; Valkey or Redis 7 is optional.	Covers errors, performance, uptime and logs. Confirm each Sentry feature you use before migrating.
Self-hosted Sentry	Runs in your infrastructure, so events and accounts stay wherever you deploy it.	Functional Source License, source-available rather than open source. Confirm current hardware and dependency needs with Sentry.	Closest to the full Sentry feature set, but heavier to operate and the licence terms need legal review.
Sentry SaaS EU region	Events are processed in the EU, but accounts, tokens, DSN keys and audit logs stay in the US.	Proprietary hosted service. The region cannot be changed after the account is created.	Lowest operating effort, but it does not keep all data in the EU on its own.
OpenReplay (self-hosted)	Session replay recordings stay on servers you run in the EU.	Confirm its licence and database requirements in the installation documentation.	Adds session replay alongside errors. Error tracking still needs GlitchTip or another tracker.
SigNoz (self-hosted)	Errors, traces, logs and metrics stay in one self-hosted stack in your EU site.	Open core: code outside the ee/ and cmd/enterprise/ directories is MIT. Enterprise code has a separate licence.	Broader observability scope, but more components to run and enterprise features need a licence check.
Support and backup access	Remote support from a third country counts as a transfer under EDPB Guidelines 05/2021, even when only a screen is shown.	Record where backups, logs and SDK traffic are stored, and who can reach them.	Ask any provider or implementation partner for written residency and support access terms.

Choosing a single-server or Kubernetes GlitchTip deployment in the EU

GlitchTip documents Docker Compose for a single server, which suits teams with modest event volumes and a small operations group. The all-in-one setup runs the web application, background work and database on one host. Its documented minimum is 256 MB of RAM, but the installation documentation recommends 512 MB on x86 or arm64, and disk needs depend on traffic and event size. Because everything sits on one machine, the EU location of that machine also determines where all event and account data lives.

Memory baseline: Start from the recommended 512 MB and treat the 256 MB minimum as a floor for testing, not production.
Disk sizing: Plan storage around your expected event size and retention, and monitor growth from the first week.
Backups: Schedule PostgreSQL backups to a second EU location, since a single host has no built-in redundancy.
Upgrades: Plan a maintenance window for each GlitchTip release, and test it on a copy first.
Single failure point: An outage of the host stops error ingestion, so decide whether your SDKs can tolerate dropped events.

Confirm with your EU hosting provider which data center locations are available, the storage and backup options they offer, and who in their organization can access the host.

How to deploy GlitchTip in an EU data center step by step

This sequence takes an EU-hosted GlitchTip instance from data center selection to a verified deployment where error events and account data stay inside infrastructure you control. Each step names the check that closes it, so the result can be shown to your DPO and security team.

Confirm EU data center and sub-processor locations
Your platform or security lead selects an EU data center or private cloud region and lists every provider that touches the hosts, database, backups, DNS, email relay and logs. Ask each provider in writing where it stores and accesses data, and whether any support or administrative access comes from outside the EEA. Record the answers in your records of processing. The step is done when every location and access path is written down and approved by your DPO, with no unresolved third-country entries.
Provision PostgreSQL 14 or later in the EU
The database team creates a PostgreSQL instance on version 14 or later in the same EU region as the application hosts. GlitchTip stores issues, events, projects and user accounts here, so it is the most important data store to place correctly. If you use an external managed database with the Helm chart, confirm the provider's region setting and that read replicas and automated snapshots stay in the EU. The step is done when a connection test from the planned GlitchTip host succeeds and the instance's region is recorded.
Deploy GlitchTip with Docker Compose or Helm
The platform engineer follows GlitchTip's installation documentation. For one server, deploy with Docker Compose using the all-in-one setup or separate web and worker services when you need to scale. For Kubernetes, install the Helm chart and point it at the external PostgreSQL instance. Add Valkey or Redis 7 or later only if your load requires it. Size the hosts at or above the documented minimum of 256 MB RAM, with 512 MB recommended on x86 or arm64, and plan disk for your expected event volume. The step is done when the web service responds on its internal address and the first admin account can sign in.
Restrict administrative and remote access to EU staff
The security team limits access to the hosts, the database and the GlitchTip admin interface to named staff who are based in the EU, using a VPN or bastion within the EU network and individual accounts rather than shared logins. Remote support sessions must also be restricted, because viewing data on a screen from a third country is itself a transfer under EDPB Guidelines 05/2021. Enable multi-factor authentication on administrator accounts. The step is done when an access review lists each permitted person and location, and a test login from outside the approved network is refused.
Point Sentry SDK DSNs at the new instance
Developers keep their existing Sentry client SDKs, since GlitchTip is compatible with them, and change each project's DSN to the endpoint of the EU instance. Start with a non-production service, send a deliberate test exception and confirm it appears under the correct project and environment. Then repeat the change for production services one by one. Keep the old DSN active for a short overlap if you are running both in parallel. The step is done when test events from every service appear in GlitchTip and no production service still sends events to the previous host.
Set backup and retention for EU data
The operations team configures scheduled PostgreSQL backups and stores them in an EU location with the same access controls as the live database. Decide how long events and logs are kept, document it in your records of processing, and configure cleanup so older data is removed on schedule. Test a restore into a separate EU environment and confirm that the restored instance returns the expected projects and events. Ask your backup provider to confirm in writing that copies are not replicated outside the EU. The step is done when a restore test succeeds and the retention settings are written down.
Verify that no data leaves the EU
The compliance and platform leads check the setup end to end. Review network egress rules to confirm the GlitchTip hosts and database can reach only approved EU destinations, check that uptime and email alert integrations route through EU endpoints where your provider offers them, and confirm that backups and logs are stored in the EU. Document the results as evidence for your assessor. DeployOpen can help prepare these controls and evidence, but independent auditors and certification bodies issue any formal assessment. The step is done when the egress review, storage locations and sub-processor list all match the step one record.

Evidence a DPO or auditor will ask for

A DPO or external auditor will want written proof of where data sits, who can reach it and how long it lives. The five items below are the documents and configuration records that usually answer those questions for a self-hosted GlitchTip deployment in an EU data center. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any opinion on it.

Record of processing and data location map

This is the Article 30 style record of what personal data enters GlitchTip (exception payloads, user identifiers, request URLs, breadcrumbs), why it is processed and where each store lives. Map the PostgreSQL database, any Valkey or Redis instance, backups and log output to a named EU data center and a named cloud account or rack. Check that no SDK sends events to a Sentry SaaS DSN, and that application hosts in other regions do not forward events to the EU instance through an intermediary you have not documented.

Transfer impact assessment notes

Even with EU hosting, remote support from a non-EU engineer or a non-EU sub-processor can count as a transfer under EDPB guidance. Record every access path, including screen sharing during support sessions, and the legal basis for each. Note that EU-US Data Privacy Framework adequacy applies only to US organizations on the DPF list, and that the appeal in Case C-703/25 P is pending, so the assessment should be revisited rather than treated as final.

Data processing agreements and sub-processor list

Collect a signed data processing agreement with each hosting provider, managed database operator and support firm that can reach the environment. Ask each for its current sub-processor list, the countries where that list stores or accesses data, and whether it has received government access requests. Compare these answers with the CLOUD Act reach described in 18 U.S.C. 2713 for any provider under US jurisdiction, because EU hosting does not remove that exposure on its own.

Access control and admin logs

Auditors will ask who can read event payloads, change project settings and create admin accounts, and how each change is recorded. Export the list of GlitchTip organization members and roles, the accounts with database or host access, and the SSO or break-glass procedure. Keep administrative and deployment logs for the same period as the event data, stored in the EU, and confirm they capture logins, role changes and configuration edits.

Backup and retention configuration

Document how long events, issues and uploaded data are kept in the PostgreSQL database, how often backups run, where copies are stored and how deletion requests propagate to backups. Set retention in the GlitchTip configuration, test a restore inside the EU, and record the result. Confirm the backup target is in the same EU jurisdiction as the primary data, and ask the hosting provider for its documented backup retention window, since it is not a default you can assume.

Questions buyers ask before replacing Sentry for EU residency

What does a move from Sentry to self-hosted GlitchTip cost?

The cost has three parts: the one-time engagement to plan, deploy and document the platform, the infrastructure that runs it, and the recurring time your team spends on upgrades, backups and on-call. Infrastructure is modest, since GlitchTip's installation documentation lists 256 MB RAM as the minimum for the all-in-one setup and recommends 512 MB RAM on x86 or arm64, with disk growing with traffic and event size. Your largest variables are the event volume, the size of the PostgreSQL database and whether you use an external managed database, which the Helm chart documentation recommends. For comparison only, GlitchTip's hosted plans are Free for up to 1,000 events per month, Small at $15 per month for 100,000 events and Medium at $50 per month for 500,000 events, according to the GlitchTip website. Ask for a written quote that lists each component separately.

How long does an EU residency migration from Sentry take?

The timeline depends on how many projects and teams you have, how many alert rules and integrations must be re-created by hand, how much Sentry history you need to keep, and how long you run both systems in parallel. Those are the factors we scope before work starts, and we do not publish a fixed duration. Since Sentry and GlitchTip both accept events through Sentry SDKs, the application-side change is usually a DSN update per project, which keeps the code work small. Confirm with your own engineers which services are in scope and which export needs your compliance team's sign-off.

What does our team need to provide for the engagement?

Expect to provide a named technical owner, access to the target EU cloud account or data center, a list of Sentry projects and their DSN keys, and the people who own each alert rule and integration. Your team also needs to decide where the database, backups and logs will live, and to confirm which data is personal data under your records of processing. Ask whether your Sentry data export and retention rules must be documented as evidence. These inputs are agreed in the written scope, so missing items show up as scope changes rather than surprises.

Can our own team run GlitchTip after the migration?

Yes, if your team can operate a Django application backed by PostgreSQL 14 or later, and optionally Valkey or Redis 7 or later, as documented in the GlitchTip installation guide. Day-to-day work includes database backups, upgrades to new releases such as v6.1.8, which was released on June 5, 2026 according to the GlitchTip backend releases, and monitoring of disk growth. Many teams keep operation in-house and buy a retainer for upgrades and testing, while others hand over the whole run. Ask us to document the runbook so either model works.

Does GlitchTip work with our existing Sentry SDKs?

GlitchTip states on its website that it is compatible with Sentry client SDKs and can receive error data from applications through Sentry's open-source SDKs. In practice, you keep the SDK in each application and point the DSN at your GlitchTip instance. GlitchTip covers error tracking, performance monitoring of slow requests and database calls, uptime monitoring and log search, according to the GlitchTip website. Features outside that list, such as some Sentry-specific integrations, must be checked against your own usage before you commit. Test your top three SDK versions in a staging project first.

How do a fixed-scope engagement and a written quote work?

Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. The scope typically lists the architecture, the projects to migrate, the parallel-run period, the backup and hardening controls, and the documentation you receive. Ask for the quote to separate one-time work from any retainer for upgrades, support or continuous testing. Compliance evidence is prepared by us, but audit reports and attestations come from independent auditors.

Does self-hosting in the EU fully resolve the transfer question?

Self-hosting in an EU data center keeps events, DSN keys, accounts and audit logs under your control, which removes the US-held account and token data that the Sentry EU region does not cover. Under EDPB Guidelines 05/2021, storage outside the EEA and remote access from a third country are transfers, so your team must also check any support access and vendor involvement. Confirm with your legal and privacy team how the Data Privacy Framework status of any provider is assessed, since the appeal in Case C-703/25 P is pending. DeployOpen prepares the technical controls and evidence, while the legal assessment stays with your organization and its counsel.

What changes for your team after the move

The most visible change is in your applications. Sentry's client SDKs stay in place, but each project's DSN must be pointed at your GlitchTip instance, so the DSN values move into the same configuration keys and secrets stores your teams already use. Plan this as a release change: every service, mobile build and front-end bundle that embeds a DSN needs a new build or a runtime configuration update, and you should confirm which of them read the DSN at build time. Alert rules, notification routes and integrations do not move automatically. Recreate each one by hand in GlitchTip, starting with the rules that page on-call staff, and test each route with a deliberate test error before you trust it.

Run both systems in parallel for a period you agree in advance with your incident and compliance owners. During that window, send events to Sentry and GlitchTip from the same services so you can compare grouping, release tagging and alert timing before you switch off the old path. Keep the Sentry project active until you have exported what you need and confirmed that your retention obligations are met. For any hosted contract you keep, check the switching terms: the EU Data Act's switching rights under Regulation (EU) 2023/2854 apply to data processing services, and Articles 25 and 29 set notice and transition rules for customers who move to another provider or to on-premises infrastructure. Ask your Sentry contact in writing how those rights are applied to your agreement, and record the answer in your processing register.

Ongoing operations now sit with you or with a provider you retain. Your team owns PostgreSQL backups and restore tests, the upgrade path for the GlitchTip release you deploy, TLS certificates, capacity planning as event volume grows, and on-call coverage for the platform itself. Confirm which of these your internal team will run and which a provider will carry under a written scope, and agree on who handles security patches and how quickly. Test a full restore into a separate environment before go-live, and repeat the test after each upgrade, so that the evidence you hand to auditors shows the platform can recover, not only that backups run.

How DeployOpen deploys GlitchTip under an EU residency constraint

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, including EU data centers and cloud accounts. For error tracking, that means GlitchTip running where your data-residency rules require, with accounts, DSN keys, events and audit logs under your control from day one.

How we scope

Written scope fixes the hosting location, EU data center or cloud region, before any installation starts.
We map every system that sends events, including client SDKs, CI pipelines and alert integrations, to confirm each data flow stays in the EU.
The scope lists which Sentry features are in or out of GlitchTip, so gaps are agreed in writing before work begins.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ask for the quote to itemize each component separately.

How we build

We deploy GlitchTip with Docker Compose on a single server or the Helm chart on Kubernetes, inside your EU environment.
We provision PostgreSQL 14 or later as a managed database in the EU region, with Valkey or Redis 7 as an optional add-on when scaling requires it.
We configure Sentry SDK DSNs to point at your instance and test error, performance and uptime paths before cutover.
We run security testing against the deployment and document the residency controls, access model and network boundaries we set up.

How we hand over

You receive architecture, data-flow and configuration documentation that your privacy and security teams can review directly.
We hand over runbooks for upgrades, backups and restores, and the procedure for rotating DSN keys and admin credentials.
Compliance evidence is prepared for your assessors, but DeployOpen does not issue audit reports, attestations or certifications.
Knowledge transfer sessions are included in the written scope so your engineers can operate the instance independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Ask whether the retainer covers GlitchTip version upgrades, such as moving between releases, and how security patches are scheduled.
Confirm with us how backups are tested, where they are stored and whether they remain in the EU under the same controls.
Your data stays in your own infrastructure throughout, so ownership of the instance and its records never passes to DeployOpen.