Feature request: upload the same sourcemap artifacts to multiple Sentry instances (multiple url/authToken targets)

[Pavel-Liteiniy]

Problem

@sentry/webpack-plugin currently supports:

• multiple projects (project: string[]) for the same Sentry instance
• a single url + a single authToken

For teams that must upload the same build artifacts to multiple self-hosted Sentry instances (for example, staging + production instances with different base URLs and tokens), this becomes hard to do with the plugin alone.

Why this matters

A naive approach is to configure two plugin instances with different url/authToken.
In practice this can lead to double processing/injection of the same output files and can affect sourcemap mapping quality.

Current workaround:

1. keep one plugin instance only for injection (sourcemaps.disable: "disable-upload"),
2. upload artifacts to each target instance in CI with sentry-cli sourcemaps upload.

This works, but it moves core plugin use-cases into custom CI scripting.

Feature request

Please support uploading to multiple Sentry instances in a single plugin configuration, e.g.:

sentryWebpackPlugin({
  org: 'my-org',
  project: 'my-project',
  release: { name: process.env.RELEASE_VERSION },
  sourcemaps: { assets: ['build/**/*.js', 'build/**/*.map'] },
  uploadTargets: [
    { url: 'https://sentry-staging.example.com', authToken: process.env.SENTRY_AUTH_TOKEN_STAGING },
    { url: 'https://sentry-prod.example.com', authToken: process.env.SENTRY_AUTH_TOKEN_PROD },
  ],
})

Expected behavior

• Build artifacts are injected/processed once.
• The same artifacts are uploaded to each configured target.
• Optional per-target overrides (if needed): org, project, headers.
• Works with self-hosted instances as well.

Alternatives considered

• Two plugin instances (one per target): can cause double artifact processing.
• CI-only uploads via sentry-cli: works, but duplicates plugin logic in CI and adds maintenance overhead.

Environment

• @sentry/webpack-plugin: 4.9.0
• Sentry self-hosted: 23.6.2

Thanks!

[linear]

BUNDLER-107

[nicohrubec]

Thanks for writing in! I'll discuss this with the team and get back to you.

[nicohrubec]

Could you be a more specific about why initializing two plugin instances with different url/authToken doesn't work for you, as in what specific problems did you run into? This approach should work fine, if it doesn't then we should fix that. We did have some issues with debug ids being injected twice in the past. This has since been fixed for rollup, but maybe we need to port this to webpack too.

[Pavel-Liteiniy]

Could you be a more specific about why initializing two plugin instances with different url/authToken doesn't work for you, as in what specific problems did you run into? This approach should work fine, if it doesn't then we should fix that. We did have some issues with debug ids being injected twice in the past. This has since been fixed for rollup, but maybe we need to port this to webpack too.

@nicohrubec thanks for the follow-up. Here are the concrete issues we hit with webpack (@sentry/webpack-plugin 4.9.0):

We had two plugin instances in the same build (same assets/project, different url + authToken for two self-hosted Sentry targets divided by environment e.g. my.sentry.io and my.sentry.test.io).
In this setup, output files are processed twice, and Sentry bootstrap code is injected twice.

For example, in one emitted runtime chunk (runtime.c16a4212.js) we see two identical preambles back-to-back:

• _sentryDebugIds init
• _sentryModuleMetadata init
• SENTRY_RELEASE = { id: "..." }

So for webpack, plugin processing is not idempotent when two instances target the same assets.

With a single plugin instance, duplication disappears.

Current workaround on our side is:

• keep one plugin instance per build target,
• route url/authToken via CI env,
• and handle extra upload flows in CI when needed.

This looks very similar to the “double injection” class fixed for rollup in #827.
If helpful, I can provide a minimal repro config/repo.

Here is asset example runtime.c16a4212.js