Releases and Sourcemaps | Self-hosted error tracking

Why releases and sourcemaps matter

In production, your JavaScript and TypeScript is almost always bundled and minified. Variable names get shortened, whitespace disappears, and entire files get concatenated. When an error occurs, the stack trace you see points to line numbers and symbols that no longer exist in your source.

Without sourcemaps, you are left guessing which component, hook, or function actually failed. Debugging turns into archaeology. Releases tie those maps to specific versions of your app so you know exactly which deploy introduced (or fixed) a problem.

This is one of the highest-ROI improvements you can make for frontend and full-stack JavaScript teams. It is also one of the most requested features for any error tracker.

How Telebugs handles releases and sourcemaps

Telebugs treats releases and sourcemaps as first-class concepts that work together.

• A release is a named snapshot of your application at a point in time (version, commit, deploy date). It can contain multiple sourcemap artifacts.
• Sourcemaps are the files generated by your bundler (webpack, Vite, esbuild, tsc, etc.) that map the minified output back to the original source.
• When an error arrives with a release identifier, Telebugs looks up the associated maps and rewrites the stack frames before storing or displaying the issue.
• The result: stack traces in the dashboard show your original file names, function names, and line numbers.

This works for any Sentry-compatible SDK sending JavaScript or TypeScript events. You keep your existing instrumentation and just point the DSN at Telebugs.

Creating releases

There are two practical ways to create releases. Both are supported today.

Manual in the dashboard

Go to the Releases tab in a project and click Create release. Give it a version (semantic or commit-based) and optional metadata. This is great for smaller teams or when you want explicit control.

Automated with Sentry CLI (recommended)

Telebugs is compatible with the Sentry CLI. You can reuse the exact commands and scripts you already have for Sentry.

First, generate a personal API key in your Telebugs account settings. Then run commands like:

# Create a release
sentry-cli releases new 1.12.0

# Upload sourcemaps (example for a typical build output)
sentry-cli sourcemaps upload --url https://your-telebugs-instance.com/ ./dist

# Or associate with a specific release
sentry-cli releases files 1.12.0 upload-sourcemaps ./dist

The CLI handles authentication via the auth token and talks to Telebugs using the same protocol Sentry expects.

Many teams already have this wired into CI/CD (GitHub Actions, GitLab, etc.). Switching to Telebugs is usually just changing the URL and token.

Uploading sourcemaps from your build

The most reliable way is to upload during or right after your production build.

• Sentry CLI (shown above) — works for almost any bundler.
• Webpack / Vite plugins — the official @sentry/webpack-plugin or vite-plugin-sentry work with Telebugs (just point them at your instance URL and token).
• Other tools — esbuild, Rollup, tsc with sourceMap, or custom scripts that call the releases API.

After upload, the maps are attached to the release. Future errors that reference that release will be automatically resolved.

Telebugs also supports the same release + dist naming conventions as Sentry, so existing automation rarely needs changes beyond the endpoint.

What you gain in practice

The difference is immediate and dramatic for any team shipping minified frontend or full-stack JavaScript.

• Stack traces point to the exact line in your source component or hook instead of a 1-character minified identifier.
• You can click through to the original file in context of the error (or copy the readable frame for your editor).
• Grouping quality improves because Telebugs can see the real call sites before grouping rules run.
• Releases give you a timeline: "this regression appeared in 1.11.3" with the exact sourcemaps for that version.
• No extra agents or sidecars. The same single Telebugs container that ingests errors also serves the map lookup.

Teams using React, Next.js, Vue, Svelte, or plain TypeScript in Node report the biggest wins because their production bundles are heavily transformed.

When releases and sourcemaps make sense

You need them if you minify or bundle JavaScript/TypeScript that runs in production (browser or server). Almost every modern web or hybrid app does.

They are less critical for pure backend services that ship readable source or for very small internal tools where you can reproduce locally easily. But even then, having them available for the occasional hard production bug is cheap insurance.

If you are already using a Sentry SDK for error reporting, adding sourcemap support is usually the highest-leverage next step after basic DSN configuration.

How this compares to self-hosted Sentry

The client-side experience is nearly identical because you are using the same SDKs and the same wire format. The difference is on the server side:

• Self-hosted Sentry requires a much larger infrastructure footprint to run the full feature set (including sourcemap handling).
• Telebugs keeps the sourcemap + release functionality in the same lightweight single container as the rest of error tracking.
• No per-event billing pressure to limit how many maps or versions you keep.
• Setup for this specific feature is the same CLI/plugin workflow you already know.

Many teams end up running Telebugs precisely because they want the Sentry SDK ecosystem and sourcemap support without the operational tax of the full self-hosted Sentry stack.

Frequently asked questions

Do I need releases to use sourcemaps?

Releases are the recommended and most reliable way to associate maps with the exact version of code that produced an error. You can upload maps without a formal release in some flows, but using releases gives you the full timeline and grouping benefits.

Which bundlers and tools are supported?

Anything that can produce standard sourcemap files (.map) and talk to the Sentry releases API works. This includes webpack, Vite, Rollup, esbuild, tsc, the Sentry CLI, and the official Sentry plugins. If your current Sentry sourcemap setup works, it will work with Telebugs after changing the URL.

Does this affect error grouping?

Yes, in a good way. When frames are mapped back to original source before grouping rules run, you get more accurate and stable groups for frontend errors. See the error grouping guide for details.

How much storage do sourcemaps use?

Maps are small relative to the rest of your data (usually a few hundred KB to a few MB per release). Telebugs stores them alongside the release and purges according to your retention policy. There are no per-event or per-map fees. Full details in the data retention and compliance guide.

Can I use this with existing Sentry instrumentation?

Yes. Point the DSN at your Telebugs instance (or use the Lapsoss adapter for Ruby if you want a vendor-neutral layer). Your code, plugins, and CLI commands stay the same.

Ready to see your real source code in production errors?

Read the Telebugs manual for complete releases and sourcemaps setup, or get Telebugs and start uploading maps from your next deploy.