When users encounter an application crash, developers need more context than a report that something went wrong. Sentry collects error events from instrumented applications, groups related failures and connects them with information useful for investigation and release tracking. It helps teams prioritize and diagnose recurring problems. Self-hosting involves the ingestion workers and data services behind the interface as well as the web application, so the deployment and recovery plan must cover that complete system.
Current guidance
Current upstream self-hosted documentation presents a minimal Docker Compose blueprint and explicitly limits dedicated support for self-hosted deployments. A community Kubernetes chart can be useful, but its existence does not make it the vendor’s supported equivalent of the old stable chart or of Sentry’s hosted service.
Self-hosting requires more than the web process: background processing and several stateful components participate in ingestion, queries and retention. Select a coherent application release and dependency set, and understand storage, networking and capacity requirements before translating Compose services into Kubernetes. Keep the public event ingestion endpoint distinct from administrative access where practical.
For migration, preserve organizations, projects, authentication configuration, DSNs and the authoritative data stores needed by the chosen release. Rehearse the documented version sequence and database migrations with backups; a container rollback may not reverse schema changes. Test a new event from an existing SDK, processing, search and notification delivery before cutover. Existing event history and attachments need an explicit retention or export decision rather than an assumption that a fresh chart can reconstruct them.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Open-source error tracking that helps developers monitor and fix crashes in real time. Iterate continuously. Boost efficiency. Improve the user experience.
What Does It Offer
Find out about exceptions right away
Set up Sentry in minutes with just a few lines of code. Get notifications via email, SMS, or chat as part of an existing workflow when errors occur or resurface.
Quickly find and fix production errors
Triage, reproduce and resolve errors with max efficiency and visibility. Exception handling with Sentry helps developers build better apps and iterate faster.
See the impact of each release
Integrate error tracking with your commit and deploy workflows. Aggregate events to see where bugs happen, how often, and who are affected before users even notice.
Error tracking built for the community
Sentry started as and remains a 100% open-source project, now delivered as a hosted service. Development aligns to security, observability, and production at scale.
Give users the power to help debug errors
Automatically prompt users for feedback so they know that you know things aren’t working.
A computer screen showing a modal window with the text “Everything is fine now,” indicating you are done debugging an error.
Let them know you resolved their issue
Reach out to let affected users know they’ve experienced an error and help is on the way.
Features
If bugs make it to production, jump into action before your users even notice a problem. Your customers (and your workflow) will thank you.
Sentry’s features help you identify and debug errors and give you all the insight to decide when to fix or rollback. When things go to hell, you’ll have help fighting fires. What more?
Error monitoring
- View actual code in stack traces, with source maps for JS, symbolication for iOS, and stack locals for Python bug tracking.
- See the error’s parameters and session information in the crash report.
- Filter noisy stack traces with the app, framework, and raw error views.
Why just debug errors?
Reproduce errors without user feedback. Sentry error monitoring includes each bug’s history of events and actions.
Crash reporting
Understand the context that contributed to errors with tags and relevant information about your software, environment, and users. You can also submit optional custom data to provide extra context for bug tracking that is unique to your application and business.
- “How many widgets were visible when the app crashed?”
- “Was their game running in 32 bit or 64-bit mode?”
- “Which clients’ users are experiencing this bug?”
- “What was the value of their shopping cart?”
- “Did the waxing gibbous cause the problem?”
Stay on top of user experience
- Link commit data to your error monitoring workflow so you can easily determine the cause of a bug and resolve with the release.
- Track problems by release version so you can focus on debugging live errors and get alerted if things regress in the future.
- Triage more efficiently by automatically assigning new issues to the author of the commit where the error originated.
Understand the bigger picture
- Use issue graphs to understand the frequency, scope, and impact of errors and prioritize what needs to be fixed.
- Get alerts via email, SMS, or chat when bugs make it into production without disrupting your development workflow.
- Get real-time insight immediately. Setup takes just a few minutes and typically requires only two lines of code.
Ask users for feedback
When frontend errors happen, Sentry can prompt users for feedback so you can compare their experiences to the data.
Sources & further reading
Spotted something that needs another look?
Help improve this page →