Sourcemap deobfuscation ¶

When your frontend throws an error, the stack trace points to minified JavaScript — line numbers and variable names that don't match your source code. The Nais telemetry collector maps these back to your original source using sourcemaps.

How it works ¶

The telemetry collector fetches sourcemap (.map) files from the same origin where your JavaScript is served. When an error arrives with a minified stack trace, the collector:

This happens server-side in the collector — no extra configuration is needed in your application.

Requirements ¶

For deobfuscation to work:

Build configuration ¶

Production sourcemaps often need explicit configuration. Verify your bundler generates .map files:

// vite.config.js
export default {
  build: {
    sourcemap: true, // generates .map files
  },
};

// webpack.config.js
module.exports = {
  devtool: 'source-map', // generates separate .map files
};

// next.config.js
module.exports = {
  productionBrowserSourceMaps: true,
};

Upload the bundle and sourcemaps to the CDN ¶

Building .map files is only half the job — the collector can only fetch them if both the JavaScript and its .map file are served from the CDN. Publish your build output with the CDN upload action. Add a step to the GitHub workflow that builds your frontend:

- uses: nais/deploy/actions/cdn-upload/v2@master
  with:
    team: <team>
    source: dist
    destination: /<app>/dist

source is your build output directory (dist for Vite, build for Create React App, .next/static for Next.js), and destination is the path under your team's CDN prefix. See Upload assets to the CDN for the full workflow (repository authorization, permissions, and every input the action accepts).

Where the files land ¶

With the step above, your build output is served from:

https://cdn.nav.no/<team>/<app>/dist/main.[hash].js
https://cdn.nav.no/<team>/<app>/dist/main.[hash].js.map

The .js file carries a relative //# sourceMappingURL=main.[hash].js.map comment, and the .map file sits right next to it — so the collector resolves it from the same directory.

Put it all together ¶

The end-to-end flow:

What happens when resolution fails ¶

If the collector can't fetch or parse a sourcemap, it falls back to minified output:

Common reasons for failure:

Verify it works ¶

If you see minified output instead, check Troubleshooting.

Resolved stack traces also appear on each error in the Nais APM Issues tab, with your own code highlighted. Deobfuscation is server-side, so it works the same whether you instrument with raw Faro or @nais/apm.

My app runs in a container ¶

If your frontend is served from a pod — a server-rendered app (Next.js, Remix, SvelteKit) or any container that ships its own .js assets — then uploading .map files to the CDN does nothing on its own.

The reason is the origin match: the collector only resolves a stack frame when that frame's JavaScript file is served from cdn.nav.no. Frames whose files are served from your pod never trigger resolution, no matter where the .map file lives.

The supported recipe: serve the static JavaScript (and its .map files) from the CDN even when the SSR shell runs in the pod. Most frameworks let you host client bundles on a separate asset host:

The pod still renders the HTML shell, but the <script> tags point at the CDN, so the browser loads the bundles from there and the collector can resolve them.