Change the Sentry DSN to point your SDK at Epure

The usual starting point: you asked Claude Code or Cursor to add error tracking, it ran Sentry's Next.js wizard, and the repo now holds @sentry/nextjs with a Sentry DSN pasted into three files. You want the same SDK to report to a different tool. Nothing else in the code needs to change for that. The destination is one string, repeated wherever Sentry.init runs.

What is the one-line DSN change?

The one-line change replaces Sentry's DSN with an Epure DSN in each Sentry.init call, or in the environment variable those calls read. A Sentry Cloud DSN looks like https://<key>@o<orgId>.ingest.sentry.io/<projectId>. An Epure Cloud DSN looks like https://<public-key>@app.epure.sh/<project-id>, where the project id is a number. Copy it from the project's Client Keys settings in Epure; on a self-hosted instance the host is your own domain.

  # .env.local, .env.production, or your host's environment settings
- SENTRY_DSN=https://<key>@o<orgId>.ingest.sentry.io/<projectId>
+ SENTRY_DSN=https://<public-key>@app.epure.sh/<project-id>
- NEXT_PUBLIC_SENTRY_DSN=https://<key>@o<orgId>.ingest.sentry.io/<projectId>
+ NEXT_PUBLIC_SENTRY_DSN=https://<public-key>@app.epure.sh/<project-id>

Leave the SDK package, its version and your captureException calls alone. Epure stores errors only, so set tracesSampleRate to 0 while you are in the file; transactions, replays and profiles reach Epure as 202 Accepted and are not stored. The full switch, with rollback and what stays in Sentry, is in switch from Sentry and keep the Sentry SDK.

Which part of the Sentry DSN decides where errors go?

A Sentry DSN has three working parts, and Epure checks each one on every request. The host tells the SDK where to connect. The last path segment is the project id, so the SDK posts to https://app.epure.sh/api/<project-id>/envelope/. The part before @ is the public key, sent in the X-Sentry-Auth header or as sentry_key in the query string. A wrong part returns its own status from the Epure ingest route:

• Wrong project number: 404 project_not_found.
• Unknown or missing public key: 401 invalid_dsn.
• A key from another Epure project: 403 project_mismatch.
• A key you rotated or revoked in Client Keys: 403 dsn_revoked.

Copy the whole DSN in one piece rather than editing the host of the old Sentry value. A Sentry DSN with only its host edited fails with 404 project_not_found or 401 invalid_dsn, and an Epure key on a Sentry host never reaches Epure at all.

Ran Sentry's wizard? Which line do you change?

After Sentry's Next.js wizard, the DSN is one line in each of three files: instrumentation-client.ts, sentry.server.config.ts and sentry.edge.config.ts, per Sentry's manual setup page (checked 6 Nov 2026). Find every copy before you edit, including .env files, so no runtime keeps the old destination:

grep -rnE "ingest\.([a-z]+\.)?sentry\.io|SENTRY_DSN" \
  --include="*.ts" --include="*.tsx" --include="*.js" --include="*.mjs" \
  --include=".env*" --exclude-dir=node_modules --exclude-dir=.next .

Replace each literal with process.env.NEXT_PUBLIC_SENTRY_DSN in the browser file and process.env.SENTRY_DSN in the server and edge files, then set both variables to the Epure DSN. In next.config.ts, remove tunnelRoute: Sentry's docs say its default rewrite mode "works only with Sentry SaaS DSNs" (build options). Leave the rest of withSentryConfig as it is for now.

A coding agent can make this edit from one instruction. A prompt for that: "Replace every hard-coded Sentry DSN with process.env.SENTRY_DSN on the server and edge and process.env.NEXT_PUBLIC_SENTRY_DSN in the browser, set tracesSampleRate to 0, remove tunnelRoute from next.config.ts, change nothing else." Review the diff; it should touch four files at most, plus your .env.

Which environment variable holds the Sentry DSN?

SENTRY_DSN is the variable most Sentry SDKs read on their own. Sentry's Node options and Python options pages list it, and both SDKs fall back to it when init gets no dsn, so a Node or Python server switches by changing one variable and restarting. Laravel uses SENTRY_LARAVEL_DSN instead (Laravel guide).

Browser code reads no server variable. Next.js copies NEXT_PUBLIC_-prefixed values into the client bundle at next build, and its docs warn that the built app "will no longer respond to changes" to them (Next.js environment variables). Vite does the same with VITE_ names. Change the variable in the build environment, such as Vercel project settings or CI, not only on the running server.

Why does Sentry still receive errors after the DSN change?

Sentry keeps receiving errors when one runtime still holds the old DSN. The usual cause is a browser bundle built before the change: the old value is inlined, and any tab opened before the deploy keeps sending to Sentry until it reloads. Next come a tunnelRoute still in next.config.ts, a hard-coded DSN in one of the three files, and a background worker or cron process that was never restarted.

Check in the browser's network tab which host the error request goes to. A request to app.epure.sh means the DSN change worked and the rest is on the Epure side: read its status code and follow event sent but no issue in Epure. A request to ingest.sentry.io or to your own /sentry-tunnel path means the old configuration is still live.

How do you check the new DSN without a browser?

One curl call checks the Epure DSN from a terminal or a CI step, with no SDK and no browser. Post a minimal event to the store endpoint with the public key and project id from the DSN. Epure answers 202 Accepted with the event id, and an issue with the message "Epure DSN check" appears under Staging a moment later. Any other status names the broken part, as listed above.

curl -sS -i -X POST "https://app.epure.sh/api/<project-id>/store/" \
  -H "Content-Type: application/json" \
  -H "X-Sentry-Auth: Sentry sentry_version=7, sentry_key=<public-key>" \
  -d '{"level":"error","environment":"staging","exception":{"values":[{"type":"Error","value":"Epure DSN check"}]}}'

# expected: status 202, body {"id":"<event-uuid>"}

Then repeat the test through the real SDK from the deployed build, because curl proves the DSN and not your bundle. Set environment in Sentry.init to production, staging or local: in Epure v0.2.0 the Issues view filters on those three names exactly. Per-runtime details are on the Next.js setup page and the Sentry SDK compatibility matrix.

How do you undo the DSN change?

Undoing the DSN change takes the same steps in reverse: restore the previous SENTRY_DSN and NEXT_PUBLIC_SENTRY_DSN values, put back tunnelRoute if you removed it, rebuild the browser bundle and restart servers. Keep the old Sentry project until the new destination has run in production for a while, so the rollback is a config change and not a new setup. Epure Cloud's 14-day trial needs no card, so there is nothing to cancel if you go back.