Which Sentry plan do I need for US/Germany data residency + PII scrubbing, and how do I configure it before rollout?

Most teams land on Sentry because production is already noisy enough. If you’re rolling Sentry out for a regulated or privacy‑sensitive environment, two questions usually show up early: “Which plan lets me choose US or Germany data residency?” and “How do I make sure we’re not storing PII before this hits production?”

Quick Answer: Data residency (US vs Germany) is available for Sentry’s hosted product across plans; you choose the region at the organization level and Sentry stores service data in that region. PII scrubbing is available to all plans via SDK configuration and server‑side Data Scrubber settings, which you should lock in before sending real user traffic.

The Quick Overview

What It Is: Sentry is a developer‑first application monitoring platform for errors, performance, replays, logs, and profiling, with built‑in controls for data residency and PII scrubbing.
Who It Is For: Engineering teams who need production debugging context (stack traces, spans, replays) while staying within internal and external privacy/compliance requirements.
Core Problem Solved: Connect what users experienced to what changed in code—without leaking sensitive data or violating data residency constraints.

How It Works

At a high level, you:

Pick your data region (US or Germany) at the organization level.
Sentry is hosted on Google Cloud Platform with multi‑tenant architecture and lets you choose a storage region (United States or Germany). Once set for an org, Sentry stores service data in that region.
Configure SDKs to avoid sending PII in the first place.
You wire up Sentry SDKs in your services and frontends, and use SDK‑level hooks (beforeSend, beforeBreadcrumb, integrations) to strip or hash PII before it leaves your environment.
Enable and tune Sentry’s server‑side Data Scrubber.
Sentry’s default Data Scrubber automatically removes values that appear to be sensitive information. You can add custom scrub rules, turn off IP address storage, and test in a non‑production project before rollout.

From there, Sentry captures events (errors/exceptions, transactions, replays, logs, profiling samples), enriches them with environment and release details, and groups them into issues. You get debugging context that’s safe enough to share with the rest of your org.

1. Which Sentry plans support US/Germany data residency?

Data residency: what you actually get

Sentry’s hosted service is:

Hosted on Google Cloud Platform using multi‑tenant architecture.
Available in two regions:
- United States
- Germany

Per Sentry’s documentation:

Sentry’s service is hosted in the United States and Germany – choose whichever makes sense for you. Sentry will store Service Data in the region selected by Customer through its configuration of the Service.

In practice:

Data residency is an organization‑level choice at setup (or via sales for some Enterprise migrations), not a “feature flag” per issue or project.
Once selected, service data for that org is stored in the chosen region.

Which plan do you need?

For the specific question “Which Sentry plan do I need for US/Germany data residency + PII scrubbing?” the key points are:

Data residency (US vs DE) is available on hosted Sentry across paid tiers – Developer, Team, Business, and Enterprise.
PII scrubbing features (data scrubbing, IP disabling) are available across plans and configurable at the organization/project level.
Enterprise becomes relevant if you also need:
- SAML‑based SSO + SCIM for automated account provisioning (governance, not directly data residency).
- A technical account manager and Enterprise support during rollout or audits.
- Contractual artifacts (BAA for HIPAA‑eligible plans, custom security review).

If your requirement is:

“We must store data in the EU/Germany” → choose the Germany region when creating your Sentry org (any paid hosted plan).
“We must store data in the US only” → choose the US region for that org.
“We need strong governance and vendor oversight in addition to data residency” → typically Business or Enterprise, with Enterprise if you need SAML + SCIM, BAA, or deeper security/compliance review.

When in doubt, loop your legal and security teams in early—they’ll care not just about where data lives, but about your PII strategy and contractual controls.

2. PII scrubbing in Sentry: what’s built‑in vs what you configure

Sentry’s stance is simple: don’t send PII if you don’t need it for debugging. To support that, you have three layers of protection:

Data Scrubber (server‑side, on by default)
- Sentry offers server‑side filtering as a default setting.
- The Data Scrubber automatically removes values that appear to be sensitive (think passwords, auth tokens, common secrets).
- You can customize which keys and values get scrubbed.
SDK‑level scrubbing (in your code)
- Every SDK supports hooks like beforeSend, beforeBreadcrumb, or equivalent.
- You can remove, mask, or hash fields, or drop entire events before they are sent to Sentry.
IP address control & event removal
- You can disable IP address storage, which is especially important when you’re using the Browser JavaScript SDK and care about PII and regional privacy laws.
- Users can remove events via bulk deletion and permanently remove data related to a given tag if something sensitive slips through.

All of this is plan‑agnostic. The main difference by plan is your usage quotas and governance, not your ability to scrub.

3. How to configure Sentry for US/DE data residency and PII scrubbing before rollout

Here’s the rollout order I recommend when I work with teams.

Step 1: Choose your Sentry region and org setup

Decide on region with stakeholders.
- If you’re bound by data residency requirements (e.g., EU user data), Germany is usually the choice.
- If not sure, your legal team will have opinions; ask them.
Create the Sentry organization in the correct region.
- During onboarding or with sales, select United States or Germany as your data region.
- Treat this as sticky: you shouldn’t plan to bounce regions later as a casual configuration change.
Align projects to that org.
- Make sure apps that must share data or dashboards are in the same org and region.
- If you have distinct requirements (e.g., EU products vs global), use separate orgs per region.

Step 2: Decide what data you actually need for debugging

Before touching settings, write down:

What fields are required for debugging (service names, environment, release, feature flags, non‑identifying user context).
What you do not want to ever store (full names, email addresses, raw IP addresses, PHI, payment details, secrets).

Some common patterns:

Use user IDs or pseudonymous identifiers instead of emails.
Use coarse location metadata (e.g., country code derived on your side) instead of IP.
Avoid sending raw payloads from requests that might contain free‑text PII.

This defines your scrubbing requirements.

Step 3: Configure SDK‑level scrubbing

You want to drop or mask sensitive data before it leaves your infra.

Examples (conceptual, not full snippets):

Browser/Frontend SDKs (JavaScript, React, etc.):
- Use beforeSend to:
  - Remove user.email, user.username, or other direct identifiers.
  - Strip sensitive fields from request data, custom contexts, and breadcrumbs.
- Ensure you’re not manually attaching bodies or headers that contain secrets.
Backend SDKs (Node, Python, Java, .NET, etc.):
- Implement equivalent hooks (beforeSend, beforeBreadcrumb, middleware) to:
  - Drop authentication tokens.
  - Truncate or hash free‑text fields that might include PII.
  - Exclude request payloads for sensitive endpoints (auth, billing, healthcare).
Mobile SDKs (iOS, Android, React Native, Flutter):
- Avoid logging or attaching anything that can directly identify users unless you have a clear legal basis and need it for debugging.
- Apply the same hook‑based scrubbing.

Key principle: Sentry should never be your only copy of sensitive data. If you need to correlate issues with users, do it via non‑PII IDs and your own application database.

Step 4: Configure Data Scrubbing in Sentry (server‑side)

Now layer on Sentry’s server‑side scrubbing:

Enable/confirm the default Data Scrubber.
- In Sentry settings, the Data Scrubber is enabled by default. Keep it that way.
- This automatically removes values that appear to be sensitive information.
Add custom scrub rules.
- Add keywords and field names you know can contain PII or secrets (e.g., ssn, token, session_id, phone, etc.).
- Configure global org‑level rules so they apply across projects.
Strip or anonymize user IP addresses.
- Disable IP address storage in Project Settings—this is particularly important when using the Browser JavaScript SDK and dealing with PII concerns.
- If you need geo‑level metrics, consider doing coarse geolocation on your side and sending only non‑identifying codes (like country).
Test scrubbing in a non‑production project.
- Create a “sandbox” project in the same org/region.
- Send test events that contain obvious PII in placeholders (e.g., "email": "pii-test@example.com").
- Verify in Sentry that:
  - The PII fields are scrubbed or masked.
  - No unexpected fields slipped through.
  - IP addresses show up as scrubbed or anonymized if you disabled them.

If you see anything you’re not happy with, tighten SDK hooks first, then add stricter Data Scrubber rules.

Step 5: Governance & incident response

Before go‑live, decide how you’ll handle mistakes:

Who owns Sentry configuration?
Typically the platform/infra team or an appointed “Sentry admin” group.
What happens if PII or PHI shows up?
- Use Sentry’s bulk event deletion to remove events within an issue.
- Permanently remove data related to a given tag if that tag includes sensitive content.
- Follow your internal incident handling process.
If you’re in a regulated environment (HIPAA, etc.):
- Make sure your subscription is for an eligible plan and that you’ve executed a BAA with Sentry before submitting any PHI.
- If you haven’t, do not submit PHI to Sentry. Configure scrubbing so PHI is dropped before events are sent.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Regional Data Residency	Stores service data in the US or Germany region you select for your organization.	Helps align with data residency and sovereignty requirements without adding custom infra.
Data Scrubber (Server‑Side)	Automatically removes values that appear to be sensitive; supports custom scrub rules.	Reduces risk when something slips through SDK filters; enforces consistent scrubbing across projects.
SDK‑Level Scrubbing Hooks	Lets you modify or drop events before they’re sent (`beforeSend`, etc.).	Ensures PII and PHI never leave your environment, tailored to your data model and codebase.
IP Address Controls	Allows disabling IP address storage at the project level.	Mitigates PII exposure from IPs, especially in browser and mobile contexts.
Event & Tag Deletion	Supports bulk deletion of events and permanent removal of data related to a given tag.	Gives you a remediation path if sensitive data is logged by mistake.
Security & Compliance Controls	Provides TLS transport, AES‑256 encryption at rest and in transit, SOC 2 Type II, ISO 27001, HIPAA attestation, and SAML/SCIM (Business+).	Helps security and compliance teams sign off on Sentry as a production‑grade monitoring vendor.

Ideal Use Cases

Best for teams rolling out Sentry in privacy‑sensitive or regulated environments:
Because you can choose US or Germany for data residency, control PII at the SDK and server level, and back it with security certifications and governance features.
Best for organizations consolidating debugging data without centralizing PII:
Because Sentry gives you code‑level context (stack traces, spans, replays, logs, profiling) while letting you scrub identifiers, disable IPs, and delete events if needed.

Limitations & Considerations

Data residency is at org level, not per‑event:
You can’t route some events to US and others to Germany within a single organization. If you need mixed regions, design your org/project structure up front.
Sentry doesn’t decide what you log; you do:
The Data Scrubber helps, but if your application logs raw PHI or PII into exceptions, Sentry will receive it unless you scrub it in SDK hooks. You still need good logging hygiene in your code.
BAA/PHI constraints:
Sentry makes a BAA available for customers with subscriptions to eligible plans. Unless your current subscription is to an eligible plan and you have a signed BAA, you must not submit PHI to Sentry.

Pricing & Plans

Plan specifics evolve, but the key dimensions for this question are:

Data region (US / Germany): available for hosted Sentry organizations; selected as part of org configuration.
PII scrubbing controls: available across plans via SDK configuration and server‑side Data Scrubber.
Governance and security add‑ons:
- Business / Enterprise: SAML‑based SSO, SCIM for automated account provisioning, expanded audit logs, and support SLAs.
- Enterprise: technical account manager, deeper onboarding, and support for complex compliance scenarios (including BAA on eligible subscriptions).

Typical alignment:

Developer / Team: Best for small to mid‑sized teams that need US/DE data residency and PII scrubbing but don’t require SAML/SCIM or Enterprise support.
Business / Enterprise: Best for larger organizations with strict governance, SSO/SCIM requirements, regulated workloads, and a need for contractual assurances (e.g., BAA, formal security reviews).

For current plan details and pricing, check Sentry’s pricing page or talk to Sales—plan names stay simple, but quota and feature limits change over time.

Frequently Asked Questions

Do I need a specific Sentry plan to get US or Germany data residency?

Short Answer: No specific “data residency plan” is required; you select the US or Germany region when configuring your Sentry organization, and Sentry stores service data in that region.

Details:
Sentry is hosted on Google Cloud Platform with multi‑tenant architecture and runs in both the United States and Germany. During org setup (or in coordination with Sentry for Enterprise), you choose which region your org uses. Sentry will store service data in that region per your configuration. This choice is orthogonal to most feature gates—data scrubbing, SDK hooks, and IP controls are available across plans. Higher‑tier plans mainly add governance features like SAML, SCIM, and Enterprise support rather than “unlocking” data residency.

Is PII scrubbing only available on higher‑tier plans?

Short Answer: No. PII scrubbing (Data Scrubber, custom scrub rules, IP disabling) and SDK‑level scrubbing are available across hosted plans.

Details:
Sentry recommends you don’t send PII, and backs that with:

A Data Scrubber that’s enabled by default and automatically removes values that appear sensitive.
Configurable scrubbing rules so you can target specific keys or patterns.
The ability to disable IP address storage, especially important for browser SDKs.
SDK‑level hooks to drop or sanitize data before it ever reaches Sentry.
The ability to bulk delete events and permanently remove data for a given tag as a remediation path.

None of these are limited to one premium tier. What does change by tier is governance (SSO/SCIM, audit logs), support, and usage quotas. If you’re handling PHI, you also need to be on an eligible plan with a signed BAA before sending any PHI.

Summary

For the question “Which Sentry plan do I need for US/Germany data residency + PII scrubbing, and how do I configure it before rollout?” the practical answer is:

Region choice (US or Germany) is an org‑level configuration, available across hosted plans.
PII scrubbing is a combination of your SDK configuration and Sentry’s Data Scrubber, also available across plans.
You choose a higher tier (Business or Enterprise) not to “unlock” data residency, but to satisfy governance: SAML/SCIM, BAAs for eligible workloads, audit requirements, and support expectations.

If you set the org region correctly, strip PII at the SDK level, keep the Data Scrubber enabled with custom rules, disable IP addresses where necessary, and define an incident playbook for accidental PII, you can roll Sentry out confidently—even in strict environments.

Next Step

Get Sentry configured in the right region, wire up SDK‑level scrubbing, and test your Data Scrubber settings in a sandbox project before your first production deploy.

Get Started