Sentry SaaS vs self-hosted Sentry: which fits your team
Keep Sentry SaaS if your team has little appetite for operating an error tracking stack and is comfortable with where Sentry hosts your events. Self-host Sentry only when you have a firm requirement to keep data in-house and people who can run it. The self-hosted edition is source-available under the Functional Source License, which sets its own terms for how your organization may use and redistribute the software, so have counsel review those terms before you deploy. Self-hosting also means you own every upgrade, the database, the workers and the on-call rota when ingestion stalls.
GlitchTip is the simpler choice when your need is error tracking, basic performance monitoring and uptime checks rather than the full Sentry feature set. Its backend is MIT licensed, and it accepts data from Sentry client SDKs, so applications keep their existing instrumentation. It needs PostgreSQL 14 or later, runs on Docker Compose for a single server, and has a Helm chart for Kubernetes. The installation documentation lists 256 MB of RAM as the minimum for the all-in-one setup and 512 MB as the recommendation, with disk depending on traffic and event size. Check the GlitchTip installation documentation and list the Sentry features your teams actually use before you choose.
The decision turns on four things: event volume, data location, license terms, and who carries upgrades and on-call. Pull the event counts for recent months from your Sentry usage pages to size any self-hosted option and to judge whether a hosted plan fits. Write down which regions, accounts and logs must stay under your control, because that determines whether SaaS is acceptable at all. Ask counsel to confirm that your planned use of the Functional Source License is permitted. Finally, name the engineer or team who will apply upgrades, maintain the database and answer pages, and confirm that they have the time to do it.
When self-hosted Sentry beats Sentry SaaS and when it does not
This table compares when self-hosted Sentry fits better than Sentry SaaS and when it does not, scenario by scenario. Read each row by its driving condition, such as data location rules, license terms, event volume and available platform staff. The main takeaway: self-hosting makes most sense when a specific constraint, such as where data must live, requires it.
| Scenario | Better fit | Condition that drives it |
|---|---|---|
| Small team, low event volume, no data location rule | Sentry SaaS, or GlitchTip if open-source licensing is the goal | Self-hosting adds servers, database upkeep and upgrades that the team must staff. Confirm current plan limits with Sentry before deciding. |
| Regulated team that must keep events on its own servers | Self-hosted error tracking in your own environment | The data location requirement decides it. Confirm with your assessor whether the SaaS region and account data stores meet the rule. |
| Team already running a self-hosted Sentry install | Self-hosted Sentry until a planned change | Existing hardware, trained staff and a working upgrade routine lower the cost of staying. Re-read the Functional Source License terms for your use before expanding. |
| High event volume with no platform staff | Sentry SaaS | Storage growth, scaling and upgrades require ongoing platform skills. A hosted plan moves that operations work to the vendor. |
| Procurement requires an OSI-approved open-source license | GlitchTip or another open-source option | The Functional Source License is source-available, so self-hosted Sentry may not satisfy a license rule that specifies open source. Confirm the requirement with legal. |
| Organization needs a specific SSO or admin control | Sentry SaaS or self-hosted Sentry, depending on the feature | Feature availability differs between hosted plans and the self-hosted package. Ask Sentry which controls each option includes before choosing. |
| Team unsure of its sizing and staffing | Pilot both before committing | Run a parallel pilot on a non-production project and record event volume, storage growth and staff hours before choosing a path. |
What running Sentry yourself asks of your team
Self-hosting Sentry moves the infrastructure and operating work from Sentry's staff to yours. Before you choose it over the SaaS service, confirm the current hardware and dependency requirements in Sentry's self-hosted documentation, because this page does not state figures for them. Plan for the compute capacity your chosen deployment needs, whether that is a single server or Kubernetes capacity, along with the data services the install relies on, such as PostgreSQL, Redis and the event storage and processing components bundled with it. Ask your platform team who will size, patch and replace these components, and how that work fits into existing on-call rotations.
Upgrades are the recurring task most likely to surprise a team. Each new self-hosted release can change service dependencies, database migrations and configuration, so the upgrade path needs a staging environment, a tested rollback and a window agreed with the teams whose error reporting depends on it. Backups must cover the database and any file-based event storage, and a restore should be tested, not assumed. Monitoring the install itself is also yours to build: queue depth, ingest errors, disk growth and certificate expiry all need alerts, or the first sign of trouble will be missing events in production.
Sentry positions its self-hosted package for lower event volumes than the SaaS service. Confirm that positioning in the current documentation, then measure your own event volume per month and its peak rate during releases. If your volume sits near or above what the self-hosted package is designed for, the operating load above grows quickly and the SaaS service may be the simpler option. Ask Sentry directly how your expected volume maps to supported self-hosted sizing before you commit engineering time to the install.
How Sentry SaaS and self-hosted Sentry compare on features
This table compares the main Sentry capabilities as documented for the hosted SaaS product and for the self-hosted edition under the Functional Source License. Treat each row as a question to verify, since the SaaS feature list changes and self-hosted availability can differ by feature and version. Confirm every self-hosted row against the current Sentry feature list before you assume parity.
| Capability | Sentry SaaS | Self-hosted Sentry (FSL) |
|---|---|---|
| Error grouping and issue tracking | Documented in the SaaS product, including issue grouping, assignment and triage | Confirm grouping, assignment and triage behavior in your specific self-hosted version |
| Release tracking | Documented in the SaaS product for linking errors to releases and commits | Confirm release and commit integrations for your version and source code host |
| Performance and tracing | Documented in the SaaS product as performance monitoring and distributed tracing | Confirm which performance and tracing features, and sampling options, ship in the self-hosted build |
| Session replay | Documented in the SaaS product as a feature | Confirm whether replay is included and which additional services it requires in your deployment |
| Alerts and integrations | Documented in the SaaS product with a range of notification and ticketing integrations | Confirm that each integration you need is available and maintained in the self-hosted build |
| SSO and access controls | Check which SSO options and role settings your SaaS plan includes in the current pricing and feature documentation | Confirm which SSO protocols, role controls and license conditions apply to the self-hosted edition |
| Data retention controls | Retention and data handling are governed by Sentry's SaaS settings and plan terms; confirm them for your plan | Retention depends on your own storage, cleanup jobs and the edition's settings; confirm the options you can control |
| Hosting location | Hosted by Sentry in the regions it offers; confirm the region available to your organization and where account data sits | Runs in your own data center or cloud account, so you choose the location and manage backups |
| Licensing | Commercial subscription from Sentry | Source-available under the Functional Source License; confirm the license terms that apply to your use before deployment |
What the Functional Source License allows and limits
Self-hosted Sentry is source-available, not open source in the sense the Open Source Initiative uses. Its code is published under the Functional Source License (FSL), which lets you read, run and modify the software, but it limits what you may do with it. The practical question is not whether you can install Sentry on your own servers, but whether your intended use falls inside the license's permitted purposes. Start by mapping each planned use (internal error tracking for your own staff, development and test environments, changes you make to the code, and any copies you give to others) against the license text. Record the result so the decision is traceable when Sentry or your auditors ask about it.
The restrictions that matter most usually concern competing uses. Offering the software to third parties in a product or service that competes with Sentry is typically the limit that catches managed service providers, implementation partners and SaaS vendors that embed error tracking for customers. Hosting Sentry for clients, redistributing a modified build or bundling it into a product therefore needs a specific answer from counsel before work starts. Also confirm the change-date and conversion terms directly with Sentry, in writing. Those terms determine when the restrictions end and which version they apply to, and the license text alone may not settle them for your version.
For comparison, GlitchTip's backend is published under the MIT license, a standard permissive open-source license, so its terms do not depend on a competing-use test. This is a difference in license category, not a verdict on Sentry, which publishes the code and offers its own supported self-hosted edition. If your organization needs an OSI-approved license for the error tracking backend, confirm that requirement early, and confirm separately the licenses of the Sentry client SDKs your applications use. Ask counsel to review both licenses against your planned use and keep the signed-off interpretation with your architecture records.
Where Sentry data lives under each option
The six cards separate the controls that move when Sentry data is hosted by the vendor or run on your own servers. Each card names the condition under which the difference matters, so you can test it against your residency, access and audit requirements before choosing a deployment model.
Data location under Sentry SaaS
With Sentry SaaS, the vendor hosts event data, account records and configuration in regions it operates, and the region is chosen when the organization is set up. Your team does not operate the database, storage or backups, so the question is what the vendor documents about where each data type is kept. Confirm the region of every data type in writing, including support access and any sub-processors, before a residency rule is applied to it.
Data location under self-hosted Sentry
Self-hosted Sentry runs on servers you choose, in your own data center or cloud account, so events, attachments, the database and backups stay where you place them. This matters when a residency rule or contract requires that error data never leave a named country or network. Check the location of every backup copy, log stream and container image registry the deployment uses, since each one can carry event content.
Identity and access control
In SaaS, the vendor operates the administrative plane, so your access controls cover your own users and tokens, while vendor staff access is governed by the vendor's policies. Self-hosting puts admin accounts, SSO integration, database roles and host access under your control. This matters when you must restrict vendor access or show who can read stack traces that may contain personal data. List every path into the database and who holds it.
Audit evidence you must produce
Hosted vendors typically provide their own assurance documents, but those cover the vendor's operation, not your configuration. With self-hosting, evidence of how the instance is deployed, patched, backed up and accessed becomes yours to collect, including configuration files, access logs, change records and restore tests. This matters for an internal audit that asks for proof of each control. Agree the evidence list before go-live.
Compliance readiness and assessments
Independent auditors assess controls against whichever framework applies to you. DeployOpen does not issue audit reports, attestations or certifications. Ask Sentry which assurance reports it holds for its SaaS service, then decide which controls the self-hosted scope takes over from the vendor. DeployOpen prepares systems, control descriptions and evidence for those assessments. This matters when a regulator or customer audit asks which party owns each control.
Upgrades and vendor dependency
SaaS updates arrive without action from your team, while self-hosted Sentry upgrades, security patches and database migrations are scheduled and tested by you. The self-hosted edition is source-available under the Functional Source License, so confirm that its terms fit how you intend to run it before you depend on it. This matters when a team needs a fixed upgrade window or cannot accept vendor-driven changes.
What self-hosted Sentry costs beyond the license
The cost comparison starts with a point most teams miss: Sentry SaaS and self-hosted Sentry are both paid for, just in different places. With SaaS, the recurring cost is the subscription, which is tied to event volume, retention and plan features. With self-hosted Sentry, the license may be free to download under the Functional Source License, but you pay for the servers or cluster, the storage, the data services behind them, backups, and the engineering time to install and upgrade the stack. Your on-call rota also absorbs the work when the stack fails at 2 a.m. Before comparing totals, ask Sentry for a written scope and a quote for the exact event volume and retention you need, and ask your own platform team to estimate the same components for the self-hosted option.
Separate one-time setup from recurring operation. One-time costs include sizing the environment, deploying the services, connecting SSO, configuring backups and restore tests, and migrating projects and DSN keys. Recurring costs include compute and storage that grow with event volume and retention length, regular upgrades (which self-hosted Sentry's multi-service architecture makes non-trivial), patching the underlying operating system and data services, and monitoring the monitoring system itself. Team size changes the picture: a small team may not have spare engineers to cover upgrades, so an outside support retainer or a fixed-scope installation with documented runbooks may be the cost that decides the question. Confirm in writing who carries each of these tasks.
Three drivers move the numbers most: event volume, retention length and the number of people who depend on the stack. Higher volume increases storage, ingestion capacity and the size of the database and queue tier. Longer retention keeps more data on disk and makes backup windows and restore tests longer. A larger team raises the value of SSO, role management and audit trails, and makes uptime more important. When you compare options, use the same event volume and retention period for each quote, include on-call time and upgrade effort as line items, and ask each vendor and partner which costs are excluded. Make sure any hardware sizing and component requirements come from the current official self-hosting documentation rather than from memory.
How a move between Sentry SaaS and self-hosted Sentry works
The sequence checks license fit and capacity before any change, then moves projects, alerts and SDK traffic in stages so that errors are never unmonitored during the switch. It ends with a self-hosted instance that receives production events and a retired SaaS project with its history archived.
Confirm the license fit first
Legal and engineering leads read the Functional Source License that governs the self-hosted edition and decide whether the intended use is permitted. The license restricts certain uses, including offering a competing hosted service, so the review covers more than cost. The output is a written decision, approved by the person accountable for license obligations, that names the use case and the products covered. Do not start the installation until that record exists.
Size the environment from an inventory
Engineering leads list every SaaS project, its event volume and retention settings, the SDKs and languages in use, the integrations and alert rules attached to each project, and who needs single sign-on access. They then compare that load with the volume and hardware guidance in Sentry's self-hosted documentation, which positions the self-hosted package for lower volumes. Ask the vendor to confirm supported limits in writing for your load. The output is a sizing sheet that shows whether the self-hosted package fits or whether another option needs evaluation.
Stand up a non-production instance
Platform engineers install self-hosted Sentry in a staging network by following the vendor's installation steps. They set TLS, backups, single sign-on and access controls before any team uses the instance. They then confirm that database, file storage and mail settings persist through a restart and that a backup restores cleanly onto a separate host. The output is a staging instance where an administrator signs in through single sign-on and a restore test has passed.
Point test DSNs at the new instance
Developers create a test project on the self-hosted instance for each service and set its DSN in staging configuration, so SDKs send errors there and not to the SaaS project. They trigger known exceptions and check that stack traces, source maps, release tags and breadcrumbs appear as expected. They also confirm that issue grouping for the same test cases matches the SaaS project, and they log each difference. The step closes when every staging service reports to the new instance and the differences are documented.
Rebuild projects, teams, alerts and integrations
Administrators recreate the project structure, team membership, alert rules, notification routes and integrations on the new instance, using the inventory from the sizing step as the checklist. Check the data export guide to see which SaaS items can be pulled through the web API and which must be rebuilt by hand. Effort grows with each project and integration, so the inventory count sets the workload. The output is a checklist in which every project and alert has an owner and a matching entry on the new instance.
Run both systems in parallel
Teams configure production services to send events to both the SaaS project and the self-hosted project. Confirm first that the SDK version in use supports sending to more than one DSN, or that a forwarding layer is in place. For an agreed period, they compare event counts, issue grouping, alert timing and notification delivery, and log each gap. On-call staff confirm that they receive alerts from the self-hosted instance. The output is a parallel-run report signed off by the service owners.
Cut over and retire the SaaS project
After the parallel-run report is accepted, teams remove the SaaS DSN from production configuration, so the self-hosted instance becomes the only destination for new events. Administrators export the history they need from SaaS before the cutover, then keep the SaaS project read-only for the retention period the business requires before deletion. Confirm the contract terms for ending the subscription or changing the plan. The output is a dated cutover record, an archived export and a closed or downgraded SaaS subscription.
Questions about self-hosted Sentry cost, effort and support
How much effort does self-hosting Sentry take compared with SaaS?
The effort recurs, because your team operates every service the self-hosted package runs. Sentry's self-hosted edition is a multi-service stack with its own data stores, so the team carries installation, version upgrades, database and storage maintenance, backups, TLS certificates, monitoring of the stack itself and capacity planning as event volume grows. With SaaS, Sentry runs all of that and bills you for the plan. Ask Sentry for the current list of services, the supported upgrade path and the minimum hardware for your expected event volume, then price your own staff time against each of those tasks. The self-hosted package is positioned for lower event volumes, so confirm where that line sits for your traffic before you plan capacity.
Can a small team run self-hosted Sentry without outside help?
A small team can run it alone only if it already operates PostgreSQL, container platforms and an on-call rotation well, and has one person who owns upgrades. Check three things: how many engineers can troubleshoot the stack at night, whether a backup restore has ever been tested end to end, and how many Sentry version upgrades the team can absorb each year. Outside help often covers the gaps. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, under a fixed scope agreed in writing, with ongoing support available as a retainer. Ask Sentry which versions it supports and how often it publishes upgrades before you decide.
What must our team supply for a self-hosted Sentry project?
Your team supplies the inputs that a fixed-scope quote depends on:
- Infrastructure: the cloud account, data center or air-gapped network where the stack will run, plus network routes to the applications that send events.
- Event profile: expected events per month, typical payload size, retention period, and the number of projects and SDK integrations.
- Identity and access: how users sign in today, and who will hold administrator roles.
- Operations: a named on-call owner, backup targets and a date for the first restore test.
- Integrations: the alert channels and ticketing tools that must be rebuilt.
Also name the engineers who will change SDK configuration in the applications, and a single approver for the cutover decision.
How long does moving from Sentry SaaS to self-hosting take?
The duration follows the scope, so the dependable answer comes from a written plan built on an inventory of your Sentry estate. The main drivers are the number of projects and teams, how many alert rules and integrations must be rebuilt by hand, how much history you need to carry over, whether the target environment already exists, and how much compliance evidence the move must produce. Running both systems in parallel adds time, because both receive events during the overlap and someone must compare them. Ask Sentry for the current self-hosted installation and upgrade documentation, then ask for a scope that lists each project, integration and data export so that each milestone maps to a deliverable.
Does the Functional Source License allow our intended use?
Sentry's self-hosted edition is source-available under the Functional Source License. That is a source-available license, not an open-source license under the OSI definition, so its terms decide what you may do even though the code can be read. Confirm three points in writing: whether your internal use is permitted, whether you may run it for clients, subsidiaries or other business units, and whether a commercial agreement is needed at your scale. Have counsel read the current license text and Sentry's own terms, because terms can change between versions. If the answer is unclear, an MIT-licensed error tracker such as GlitchTip avoids this question. This is general information, not legal advice.
When is GlitchTip the better fit than self-hosted Sentry?
GlitchTip fits better when you need error tracking, performance monitoring, uptime checks and log search, and your applications already use Sentry SDKs. Its backend is MIT licensed, requires PostgreSQL 14 or later, and its installation documentation recommends 512 MB of RAM. You can run it as a single service or as separate web and worker services when you scale, using Docker Compose on one server or the Helm chart on Kubernetes. Choose self-hosted Sentry only if you depend on features GlitchTip does not cover, and verify that against each feature you use today. Review the GlitchTip installation documentation for current requirements before you decide.
What does self-hosted GlitchTip cost compared with its hosted plans?
GlitchTip's website lists hosted plans by event volume: Free for up to 1,000 events per month, Small at $15 per month for 100,000 events, Medium at $50 per month for 500,000 events and Large at $250 per month for 3 million events, with a BAA available on request. Self-hosting removes the subscription but not the bill. The MIT-licensed backend has no license fee, so you pay for the server, PostgreSQL (managed or self-run), optional Valkey or Redis, backups, storage and staff time for upgrades and on-call. Event volume, retention period and uptime requirements drive those costs. Ask DeployOpen for a quote built from a written scope, and confirm current hosted prices on the GlitchTip website, since they can change.
How DeployOpen works on this
DeployOpen starts by writing down what your team needs from error tracking, then tests whether self-hosted Sentry or self-hosted GlitchTip fits that scope inside your own infrastructure. We plan, implement, harden, document and support the chosen platform, and we do not issue audit reports or certifications ourselves.
How we scope
- Inventory which Sentry SaaS projects, SDKs, environments and integrations are in use today
- Define the hardware, database and network footprint for self-hosted Sentry or GlitchTip in your environment
- Agree the written scope, deliverables and timeline before any work starts, since engagements are fixed-scope
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network, with Docker Compose or Helm
- Configure PostgreSQL, backups, access controls and SSO under the scope you agreed in writing
- Test SDK compatibility and event ingestion in a parallel environment before any DSN is moved
How we hand over
- Provide runbooks for installation, upgrades, backup restores and incident response on the error tracker
- Document the alert rules, integrations and project structure that must be re-created by hand
- Deliver evidence of configuration and testing that your internal assessors or external auditors can review
How we support
- Offer ongoing support, version upgrades and continuous testing as a retainer after handover
- Review new platform releases and advise on upgrade timing against your own change process
- Confirm with your team which support hours, response expectations and retention periods you need in writing
