Problem Statement
I am using Sentry in a self-hosted environment with a microfrontend architecture where applications are independently built, deployed, and composed at runtime (e.g. module federation or dynamic CDN-based loading).
Each microfrontend produces its own JavaScript bundles with hidden source maps containing valid debugId values.
At runtime, Sentry events frequently contain stack traces that span multiple microfrontends. For example, an error originating in one microfrontend may include frames from shared or dynamically loaded code belonging to another microfrontend.
The issue is that source map resolution in self-hosted Sentry is scoped to the project/release that received the event. Even though debugId correctly identifies the originating bundle, Sentry only resolves source maps within the same project context.
This results in partially or fully minified stack traces when frames originate from other microfrontends, even when the correct source maps exist in other projects within the same self-hosted Sentry instance.
Core limitation
There is currently no mechanism in self-hosted Sentry to resolve source maps across projects using debugId, even when:
- The
debugId uniquely identifies the correct bundle
- The source map exists in another project in the same self-hosted instance
- The runtime composition of microfrontends is dynamic and not known at build time
Why this is a problem
In microfrontend architectures:
- Bundles are independently deployed and versioned
- Runtime composition is dynamic and not centrally known
- A single bundle may execute in multiple unrelated application contexts
- New consuming applications may appear after deployment
Because of this, it is not possible to predefine or maintain a complete mapping of which Sentry projects should receive a given microfrontend’s source maps (to use option from #85226)
As a result, strict project-scoped source map resolution does not scale for self-hosted microfrontend environments.
Solution Brainstorm
Introduce support in self-hosted Sentry for cross-project or instance-wide source map resolution based on debugId.
1. Instance-wide debugId lookup
Allow Sentry to resolve source maps across all projects in the self-hosted instance using debugId, instead of limiting resolution to the event’s project.
2. Cross-project artifact resolution scope
Introduce a configurable scope that allows source map lookup across a defined set of projects within the same self-hosted installation.
3. Global source map registry (instance-level)
Treat source maps as instance-level artifacts rather than project-scoped assets, enabling reuse across microfrontends.
4. Explicit resolution mode configuration
Provide a setting such as:
- project-only (current behavior)
- instance-wide lookup
- configured project list
Why this matters
This limitation becomes especially important in self-hosted environments because:
- Organizations often host multiple microfrontends under a single Sentry instance
- Cross-team ownership boundaries are stricter
- There is no external SaaS artifact coordination layer
- Microfrontend adoption increases runtime composition complexity over time
Without cross-project resolution, debugging distributed frontend systems becomes fragmented and incomplete.
Product Area
Issues - Source Maps
Problem Statement
I am using Sentry in a self-hosted environment with a microfrontend architecture where applications are independently built, deployed, and composed at runtime (e.g. module federation or dynamic CDN-based loading).
Each microfrontend produces its own JavaScript bundles with hidden source maps containing valid
debugIdvalues.At runtime, Sentry events frequently contain stack traces that span multiple microfrontends. For example, an error originating in one microfrontend may include frames from shared or dynamically loaded code belonging to another microfrontend.
The issue is that source map resolution in self-hosted Sentry is scoped to the project/release that received the event. Even though
debugIdcorrectly identifies the originating bundle, Sentry only resolves source maps within the same project context.This results in partially or fully minified stack traces when frames originate from other microfrontends, even when the correct source maps exist in other projects within the same self-hosted Sentry instance.
Core limitation
There is currently no mechanism in self-hosted Sentry to resolve source maps across projects using
debugId, even when:debugIduniquely identifies the correct bundleWhy this is a problem
In microfrontend architectures:
Because of this, it is not possible to predefine or maintain a complete mapping of which Sentry projects should receive a given microfrontend’s source maps (to use option from #85226)
As a result, strict project-scoped source map resolution does not scale for self-hosted microfrontend environments.
Solution Brainstorm
Introduce support in self-hosted Sentry for cross-project or instance-wide source map resolution based on
debugId.1. Instance-wide
debugIdlookupAllow Sentry to resolve source maps across all projects in the self-hosted instance using
debugId, instead of limiting resolution to the event’s project.2. Cross-project artifact resolution scope
Introduce a configurable scope that allows source map lookup across a defined set of projects within the same self-hosted installation.
3. Global source map registry (instance-level)
Treat source maps as instance-level artifacts rather than project-scoped assets, enabling reuse across microfrontends.
4. Explicit resolution mode configuration
Provide a setting such as:
Why this matters
This limitation becomes especially important in self-hosted environments because:
Without cross-project resolution, debugging distributed frontend systems becomes fragmented and incomplete.
Product Area
Issues - Source Maps