---
title: Releases | ReplayPilot Docs
description: Tag sessions with the version of your app that was live when they happened.
canonical: https://replaypilot.com/docs/releases
---

# Releases | ReplayPilot Docs

Search docs…⌘KBrowse docs

Get started
- [Installation](/docs/getting-started)
- [What's new](/docs/whats-new)

Dashboard
- [Replays & the session player](/docs/replays)
- [Errors](/docs/errors)
- [Frustration signals](/docs/frustration)
- [Funnels](/docs/funnels)
- [Releases](/docs/releases)
- [Logs & network requests](/docs/logs)
- [Visitors](/docs/visitors)
- [Heatmaps](/docs/heatmaps)
- [Click map](/docs/click-map)
- [Cohort retention](/docs/cohorts)
- [Projects & project keys](/docs/projects)
- [Alerts](/docs/alerts)
- [Shared links](/docs/shared-links)

Integrations
- [Integrations](/docs/integrations)
- [MCP server](/docs/mcp-server)

Account & data
- [Billing & plans](/docs/billing)
- [Security & masking](/docs/security-masking)
- [Data retention & limits](/docs/retention-limits)
- [Team accounts](/docs/team-accounts)

# Releases

Tag sessions with the version of your app that was live when they happened.

## How releases work

ReplayPilot doesn't have a "create release" button. Instead, your Sentry SDK
already reports a **release** (a version string, like 1.4.2 or a git
commit hash) and an **environment** (like production or staging) with
every session it sends. ReplayPilot reads those two values and groups your
sessions by them automatically.

This works through the same Sentry-compatible endpoint used for error
reporting. See [Errors](/docs/errors) for how to set up that endpoint and your Sentry
DSN. Releases need no extra configuration once errors are working.

## Reading the Releases page

For each release and environment, ReplayPilot shows the **crash-free
session rate**: the percentage of that release's sessions that didn't
crash. A release with 100% has had zero crashing sessions so far, and that
includes a brand-new release with no sessions reported yet.

Use this page to compare releases side by side. A sudden drop after a
deploy is a fast way to spot a bad release before it spreads.

## Source maps

If you minify or bundle your JavaScript for production, error stack traces
normally show minified file names and line numbers, which aren't useful for
debugging. Upload a **source map** for each release, and ReplayPilot uses it
to show your real file names and line numbers on the [Errors](/docs/errors)
page instead.

Source map upload isn't a dashboard feature. It's a POST request your
build or deploy process makes to ReplayPilot's API, authenticated with your
project's **secret key** (not the public key from your snippet). A CI job
is a typical place to add this step, right after your build finishes.

A few things to know:

- Each upload belongs to one release name and file name. Uploading again for
the same pair replaces the old map.

- There's a **10 MB** size limit per source map.

- ReplayPilot applies maps when you view an error's stack trace, not when you
upload them. If an error happens before you've uploaded its map, uploading
it afterward still fixes that error's stack trace, even retroactively.

Questions about a specific stack trace not resolving? Check that the
release name in your source map upload matches the release name your SDK
reports exactly, including case.

[← Funnels](/docs/funnels)[Logs & network requests →](/docs/logs)