How do I self-host Sentry, and what are the operational requirements vs using sentry.io?
Application Observability

How do I self-host Sentry, and what are the operational requirements vs using sentry.io?

10 min read

Most teams look at self-hosting Sentry when they hit governance, data residency, or cost predictability questions. That’s valid. But running Sentry yourself is closer to running a small SaaS product than installing a single binary. You’re taking on databases, message brokers, search, upgrades, observability, and on-call for the monitoring tool that’s supposed to keep your app healthy.

This explainer walks through what self-hosting Sentry actually involves, how it compares to using sentry.io, and how to decide which path fits your team.

Note: For the most current, step-by-step self-host docs and exact resource requirements, always cross-check with Sentry’s official docs and GitHub repositories. This article is meant to frame the tradeoffs, not replace those install guides.


Quick Answer: You can self-host Sentry using the open-source stack (containers + Postgres + Redis + Kafka + ClickHouse, etc.), but you’re responsible for operating and securing that cluster. Using sentry.io offloads infrastructure, scaling, upgrades, and most security/compliance work so your team can focus on instrumenting SDKs and fixing issues instead of running monitoring as an internal product.

The Quick Overview

  • What It Is: Self-hosted Sentry is the on-premise / self-managed deployment of Sentry’s application monitoring platform, typically run via Docker and Kubernetes with multiple backing services (databases, queues, search). Using sentry.io means you consume Sentry as a fully managed, multi-tenant SaaS hosted on Google Cloud Platform.
  • Who It Is For: Self-host is for organizations with strict data residency, air-gapped environments, or deep platform/SRE capacity. sentry.io fits most teams that want production-grade monitoring without owning the operational load.
  • Core Problem Solved: Both options give you the same core outcome: capture errors, transactions, and replays from your code and turn them into actionable issues. The difference is who runs, upgrades, and scales the underlying Sentry stack—and who gets woken up when it breaks.

How It Works

At a high level, Sentry works the same way whether self-hosted or SaaS:

  1. You install Sentry SDKs in your services (frontend, backend, mobile, workers).
  2. SDKs capture events: errors/exceptions, transactions/spans (for Tracing), Session Replays, logs, and profiling data.
  3. Events are sent to Sentry, enriched with context (release version, environment, user, request data, etc.), grouped into issues, and surfaced via alerts, dashboards, and integrations.

The difference is where that “Sentry” endpoint lives and who owns the infrastructure:

  • Self-hosted Sentry:
    You deploy Sentry’s services (web, workers, cron, relay, symbolicator, Snuba/ClickHouse, Postgres, Redis, Kafka, etc.) on your own infrastructure—typically Kubernetes or Docker Compose. You provide storage, scaling, monitoring, backups, and security controls.

  • sentry.io (SaaS):
    Sentry is hosted on Google Cloud Platform, with multi-tenant architecture, TLS for data in transit, AES-256 for data at rest, annual third-party penetration testing, and data residency choice between United States and Germany. You configure projects, quotas, alerts, and workflows; Sentry runs the rest.

1. Self‑Hosted Sentry: Architecture & Phases

  1. Install & Bootstrap

    • Clone the self-hosted repo and configure environment variables.
    • Spin up the core services using Docker (or Helm charts if you’re going Kubernetes).
    • Run migrations for Postgres, initialize ClickHouse, seed configuration.
    • Configure DNS (e.g., sentry.mycompany.com) and TLS termination via a reverse proxy/ingress.
  2. Integrate SDKs & Start Sending Events

    • Point SDKs to your self-hosted endpoint instead of https://sentry.io.
    • Configure DSNs for each project.
    • Verify errors, transactions, and Session Replays are flowing and being grouped into issues.
    • Set up alerts, Ownership Rules, and integrations (Slack, Teams, GitHub, GitLab, etc.), noting they now talk to your own Sentry instance.
  3. Operate, Scale, and Upgrade

    • Monitor the Sentry stack (CPU, memory, disk, queue lag, ClickHouse performance).
    • Scale workers and storage as event volume grows.
    • Plan and execute upgrades regularly, reading release notes for breaking changes.
    • Own backups, disaster recovery, and security hardening.

2. sentry.io: Architecture & Phases

  1. Sign Up & Create Projects

    • Create an organization on sentry.io.
    • Add projects per service (e.g., frontend-web, orders-api, mobile-ios).
    • Choose data region (US or Germany) based on your compliance requirements.
  2. Install SDKs & Configure Sampling

    • Install language/framework-specific SDKs.
    • Enable tracing with traces_sample_rate or dynamic sampling rules to control transaction volume.
    • Add Session Replay, logs, and profiling if you want deeper context.
  3. Use Sentry as a Monitoring Workflow

    • Use Issues, Discover, Dashboards, and Performance views to triage errors and slow transactions.
    • Configure Ownership Rules and Suspect Commits so issues route to the right team and developer.
    • Integrate with code hosts and tools (GitHub, GitLab, Bitbucket, Linear, Jira): push an issue to Linear from Sentry, resolve it there, and have the status sync back.
    • Scale quotas, set lookback windows, and add Seer (AI debugging) as an add-on when you’re ready.

Features & Benefits Breakdown

From a product standpoint, self-host and SaaS share similar features on paper; the real gap is in operations, reliability, and governance.

Core FeatureWhat It DoesPrimary Benefit
Error Monitoring & Issue GroupingCaptures exceptions from your code and groups them into issues with stack traces, tags, and breadcrumbs.See exactly where code is failing in production and prioritize the most common/impactful errors.
Tracing & Performance (Transactions & Spans)Captures transactions across services and records spans to show where time is spent.Trace slow requests through frontend → backend → downstream services to pinpoint poor-performing code, not just slow endpoints.
Session Replay, Logs & ProfilingRecords user sessions, connects logs, and samples profiling data for hotspots.Tie “what the user saw” to “what the code did” to “what the CPU burned,” so you can debug quickly with full context.

On sentry.io, you also get:

  • Managed scaling and storage for large volumes (hundreds of millions to billions of events per month).
  • Advanced governance on higher plans (SAML + SCIM on Business+, organization audit log, enterprise support options).
  • Seer as an add-on that uses your Sentry context (stack traces, spans, commits, logs, profiling) to do root cause analysis and propose fixes, even opening pull requests.

On self-host, you can get much of the same core functionality, but:

  • Some advanced SaaS features may either lag or not be available in the open-source distribution.
  • You own the operational complexity: no hidden “someone else” running Kafka for you.

Ideal Use Cases

  • Best for highly regulated, on-prem, or air‑gapped environments:
    Because self-hosted Sentry lets you keep all telemetry inside your own perimeter. If your policies forbid sending production telemetry to third-party clouds—even with encryption and SOC 2 / ISO 27001 certifications—self-host might be your only path.

  • Best for teams optimizing for speed over infrastructure ownership:
    Because sentry.io removes the need to hire or repurpose SREs to run Sentry itself. You get encryption (TLS, AES‑256 at rest), hosting on Google Cloud Platform, data residency in US or Germany, annual independent penetration testing, and operational maturity without building it all in-house.

Limitations & Considerations

Self‑Hosted Sentry

  • Operational Overhead:
    You’re running a distributed system with multiple stateful services. Expect:

    • Capacity planning (CPU, RAM, IOPS, storage growth for Postgres/ClickHouse).
    • Monitoring/alerting on the Sentry stack itself.
    • Regular upgrade projects and occasional migrations.
    • On-call when Sentry is slow or down, which usually happens when you need it most.
  • Feature & Scale Gaps:

    • The open-source deployment may not always match sentry.io feature parity or performance at very high scale.
    • You’ll need to test high-volume scenarios, retention, and backup/restore yourself.

sentry.io (SaaS)

  • Data Residency Bound to Available Regions:
    • You can choose between hosting in the United States or Germany. If you require a specific country or full on-prem, that’s a constraint.
  • Multi‑Tenant Model:
    • While data is logically isolated and encrypted with AES-256 at rest and protected via TLS in transit, some organizations will still prefer their own isolated infrastructure and controls.

Pricing & Plans

Self-host and SaaS differ fundamentally in how you “pay” for Sentry:

  • Self‑Hosted Sentry:

    • There’s no per-event fee from Sentry itself for the open-source stack.
    • You do pay for:
      • Infrastructure (servers/VMs, storage, network).
      • Engineering time to install, monitor, secure, and upgrade.
      • Potential downtime cost when Sentry is unavailable during an incident.
    • In practice, many organizations underestimate the internal cost until they’re running at serious volume.
  • sentry.io (SaaS):

    • You can get started for free.
    • Pricing depends on the number of monthly events, transactions, replays, and attachments that you send to Sentry.
    • Plans also differ by features like number of dashboards (e.g., 10 on Developer, 20 on Team, unlimited on Business+), governance controls, and support.
    • You can:
      • Define quotas for each data type.
      • Add pay-as-you-go budget for overages.
      • Reserve volume ahead of time for discounts (the “pay ahead, save money… when you use more, you pay less” model).
    • Seer (AI debugging) is purchased separately as an add-on priced per active contributor.

Plan-style guidance (high level; always check current pricing page for specifics):

  • Self‑Hosted / OSS path: Best for organizations where infrastructure is already centralized, and there’s an existing platform/SRE team comfortable running complex stateful services.
  • SaaS “Developer / Team / Business+” plans on sentry.io:
    Best for teams that want:
    • Predictable pricing based on event volume.
    • Built-in security/compliance posture (SOC 2 Type II, ISO 27001, HIPAA attestation).
    • Governance features (SAML + SCIM on Business+, audit logs, enterprise support) without building them themselves.

Frequently Asked Questions

Do I get the same features self-hosted as I do on sentry.io?

Short Answer: You get the core experience—capturing errors, tracing, issues, and basic workflows—but not everything that exists on sentry.io is guaranteed in self-host, and SaaS features may arrive earlier or exclusively.

Details:
The open-source Sentry stack is powerful: it supports error monitoring, tracing, performance, Session Replay, and the standard debugging workflow we talk about (events → issues → context → fix). However:

  • New capabilities are built and iterated quickly on sentry.io.
  • Some features depend on internal SaaS infrastructure, scale, or commercial offerings (like Seer licensing).
  • Governance features like SAML + SCIM, enterprise support options, and some workflow integrations are tied to specific sentry.io plans.

If you choose self-host, plan for periodic “feature gap” assessments so you’re not assuming parity that isn’t there.

How do I decide between self-hosting Sentry and using sentry.io?

Short Answer: If your primary constraint is regulation or air‑gapped environments, self-host is often required. Otherwise, sentry.io is usually the better default because it removes a large operational burden.

Details:
Ask your team these questions:

  1. Data & Compliance

    • Do your policies absolutely require all telemetry to stay on-prem or in your own cloud account?
    • If not, can you use a SaaS hosted on Google Cloud Platform with TLS, AES-256 encryption at rest, SOC 2 Type II, ISO 27001, and HIPAA attestation, with data residency in US or Germany?
  2. Operational Capacity

    • Do you already run multi-service stateful stacks (Postgres + Kafka + ClickHouse) with strong SRE coverage?
    • Are you willing to be on call for your monitoring system, including upgrades and disaster recovery?
  3. Time-to-Value

    • Do you want Sentry running in hours (SaaS + SDKs) or are you fine with a multi-day or multi-week project to stand up and harden self-host?
  4. Total Cost

    • Include infrastructure, engineering salary, and risk of downtime for self-host.
    • Compare that with sentry.io’s per-event pricing plus the benefit of offloading infrastructure to Sentry.

If you don’t have a hard requirement forcing self-host, sentry.io is typically the more efficient choice in practice.

Summary

Self-hosting Sentry gives you control: your infrastructure, your security stack, your retention policies. But it also makes Sentry another production service you have to run, scale, secure, and upgrade—complete with backing databases, queues, search engines, and on-call.

Using sentry.io lets you skip the infrastructure and jump straight to the point: install SDKs, capture errors and performance data, trace through services, tie issues to commits, and push fixes—backed by Sentry’s hosted platform on Google Cloud Platform, encryption in transit and at rest, independent penetration testing, and compliance certifications.

If you’re not mandated to keep everything on-prem, offloading Sentry’s operational requirements to Sentry itself usually means you ship fixes faster and spend more time in code—and less time nursing your monitoring stack.

Next Step

Get Started