Developer Tools guide
Self-Hosted Sentry: Capacity and Recovery Before the Install Script
Decide whether Sentry data locality justifies a multi-service stack, 16 GB recommended memory, tested recovery, and on-call ownership.
Published and reviewed by OpenAlt · October 1, 2026
OpenAlt’s verdict: self-hosted Sentry is justified when data locality or control is a concrete requirement with a named owner; otherwise, Cloud is the faster path. You exchange a quicker start for capacity planning, backups, recovery proof, upgrades, and on-call responsibility. Treat sentry self hosted as a service to operate, not a one-line sentry setup. Official self-hosted guidance
Table of Contents
- Self-Host Only for a Concrete Locality or Control Reason
- Separate the Install Minimum from the Production Recommendation
- Pin a Release Tag and Use the Official Installer
- Plan Ingress, TLS, Email, Retention, and SDK Endpoints
- Protect PostgreSQL, Analytics and Event Stores, Filestore, and Configuration
- Prove an Isolated Restore Before Calling Recovery Ready
- Upgrade from Release Notes with Capacity Headroom and Rollback
- Decide with a Cloud-versus-Self-Host Checklist
- FAQ
1. Self-Host Only for a Concrete Locality or Control Reason
Self-host only when data locality or control is a documented requirement assigned to a named owner. If it remains a preference, Cloud is the faster option according to the official guidance. The owner must accept responsibility for availability, backups, upgrades, capacity, and recovery.
Before installation, record:
- The locality or control requirement.
- The systems and data covered.
- The owner for operations and recovery.
- The condition that would make Cloud acceptable later.
“We can run containers” describes capability, not need. The owner also needs authority to schedule maintenance, approve capacity changes, and lead recovery exercises.
2. Separate the Install Minimum from the Production Recommendation
The published minimum is 2 CPU and 4 GB of RAM; the published recommendation is 4 CPU, 16 GB of RAM, and 20 GB of disk. Use the minimum to validate feasibility, not to promise production comfort. Treat the recommendation as a starting envelope, then add headroom for workload, growth, maintenance, and recovery. Published requirements
Plan against four markers:
- Minimum: feasibility and initial validation.
- Recommendation: baseline for serious evaluation.
- Headroom: reserved capacity for growth and restore work.
- Evidence: measurements from event volume, retention, and attachments.
Record current usage, expected growth, disk pressure, and the threshold for resizing or reconsidering the deployment.
3. Pin a Release Tag and Use the Official Installer
Use the official Compose distribution and pin a release tag. The supported path and release-tag approach are documented upstream; copied Compose fragments may omit assumptions needed later. Keep local overrides small, reviewed, and easy to compare with the upstream release. Self-hosted distribution Release guidance
A disciplined sentry docker compose workflow should:
- Select a specific release tag.
- Preserve the tag and configuration with deployment records.
- Keep secrets and endpoint settings separate from examples.
- Record each local override and its operational reason.
- Compare changes with the next official release.
This provides traceability during incidents: the team can identify the running release, configuration, and local adjustments.
4. Plan Ingress, TLS, Email, Retention, and SDK Endpoints
Design the public path before starting containers. Assign owners and explicit decisions for ingress, TLS, email, retention, and the SDK endpoint. The self-host CLI documentation identifies SENTRY_HOST/URL and self-host authentication as configuration concerns, so record them with certificates and client settings. Self-host CLI documentation
Resolve these items before onboarding applications:
- Ingress and TLS: public hostname, certificate path, and renewal owner.
- Email: notification requirements and delivery maintenance.
- Retention: intended period and capacity consequences.
- SDK endpoint: one canonical application endpoint.
- Authentication: how operators access and authenticate.
A reachable interface is not automatically a usable service. Put endpoint, authentication, email, and retention decisions in the runbook so another operator can reproduce them.
5. Protect PostgreSQL, Analytics and Event Stores, Filestore, and Configuration
Back up durable data and configuration as one recovery plan. Restoring only the application shell does not prove service recovery. The backup guidance identifies three main data stores for consideration: PostgreSQL, analytics/event stores, and filestore. Preserve configuration separately, and assess Redis as often optional. Backup guidance
| Asset | Preserve | Recovery proof |
|---|---|---|
| PostgreSQL | Scheduled backup and recovery instructions | Login and project state available |
| Analytics/event stores | Protection and retention assumptions | New ingestion is usable |
| Filestore | Attachments and storage mapping | An attachment can be retrieved |
| Configuration | Endpoints, authentication, secrets process | Deployment can be reproduced |
| Redis | Explicitly assess whether it is optional | Consequence of exclusion documented |
Every durable component and configuration input needed to rebuild the service needs a named preservation and restoration path.
6. Prove an Isolated Restore Before Calling Recovery Ready
An isolated restore is the proof point. Rebuild outside the primary runtime and verify login, projects, ingestion, and attachments before calling recovery ready. Backups are inputs, not evidence. Capture the exercise in a repeatable, time-bounded runbook. Backup guidance
Use this sequence:
- Prepare an isolated environment with the intended release tag.
- Restore PostgreSQL, analytics/event stores, filestore, and configuration.
- Verify operator login and expected project visibility.
- Send a controlled event through the documented SDK endpoint.
- Confirm ingestion, event visibility, and attachment retrieval.
- Record elapsed time, manual steps, errors, and unresolved assumptions.
The test must show that the service can be used, not merely that files can be copied. Repeat it after material changes to storage, authentication, endpoints, or recovery procedures.
7. Upgrade from Release Notes with Capacity Headroom and Rollback
Upgrade from release notes with capacity headroom and a rollback path. Preserve a recoverable backup, confirm capacity is not already tight, define a stop condition, and keep the previous release tag until validation is complete. Repository guidance
Before upgrading:
- Review release notes for configuration or storage implications.
- Confirm backup freshness and restore instructions.
- Check CPU, memory, and disk headroom.
- Define validation for login, projects, ingestion, and attachments.
- Name the people who can stop the change or authorize rollback.
Afterward, record the resulting tag, configuration differences, validation outcome, and new capacity signals. Do not discard the previous recovery path until the upgraded service passes the agreed checks.
8. Decide with a Cloud-versus-Self-Host Checklist
Choose Cloud when there is no concrete self-host need or willing owner. Choose self-host when locality or control is explicit and the team accepts the lifecycle. Compare both options using data location, capacity, backups, restore time, upgrade labor, incident response, and on-call cost. Official guidance calls Cloud faster when the concrete need is absent. Official self-hosted guidance
- Locality or control requirement is specific and documented.
- A named owner accepts ongoing responsibility.
- Capacity is sized beyond the published minimum.
- Ingress, TLS, email, retention, and SDK endpoint decisions are recorded.
- PostgreSQL, analytics/event stores, filestore, and configuration are covered.
- An isolated restore proves login, projects, ingestion, and attachments.
- Upgrade, rollback, and release-tag procedures are written.
- On-call cost is included in the service decision.
For adjacent planning, OpenAlt’s monitoring resources, SLA and downtime calculator, RTO/RPO impact calculator, and Grafana Docker Compose guide connect this choice to broader operational planning.
FAQ
Should the 2 CPU and 4 GB minimum be treated as production sizing?
No. It is the published minimum. The published recommendation is 4 CPU, 16 GB of RAM, and 20 GB of disk. Use the minimum for feasibility and the recommendation as a baseline, then add headroom for workload, retention, growth, and recovery. Published requirements
When is self-hosting the wrong choice?
Self-hosting is the wrong choice when locality or control is not concrete, no owner accepts the lifecycle, or the team cannot fund backups, restores, upgrades, and on-call work. Official guidance presents Cloud as faster without a concrete self-host need. Official guidance
What must a recovery test prove?
It must prove usable service behavior: operator login, expected projects, controlled event ingestion, and attachment retrieval. Run it in isolation, record elapsed time and manual work, and update the runbook when steps fail. Successful backup creation alone is insufficient evidence.
Is Redis always part of the backup set?
No. The backup guidance describes Redis as often optional, but the decision must be explicit for the deployment. Document the consequence of excluding it, preserve required data stores and configuration, and validate login, projects, ingestion, and attachments. Backup guidance