Releases

Releases describe a single deployment. They contain the artefacts you uploaded, the version that produced them, and any build metadata PostHog can infer. You should upload sourcemaps and create a release for each deployment of your application.

Error tracking displays this release info over stack traces to help you track down the root cause of an issue, down to the commit and version that produced it.

Creating releases

Release information is automatically created when you inject sourcemaps using posthog-cli sourcemap inject. If you use frameworks with a PostHog package like Next.js or Nuxt, this is handled for you.

The CLI finds or creates the release for the project and version it detects, and stores that link inside each sourcemap. You can specify --project and --version yourself; otherwise the CLI inspects Git metadata (like the repo name and commit SHA) to choose sensible values. Artefacts are locked to their release once written, so they cannot move between releases later.

Uploading artefacts

When you upload sourcemaps using posthog-cli sourcemap upload, the artefacts are associated with a release if it was injected. You can then see release details on issues, link between stack traces and code files, and filter issues based on release information.

Release context in error tracking

Other than a specific release version that you define, captured exceptions inherit the release information recorded during injection. PostHog attaches the release, project, and Git metadata to each exception captured as we capture it in our ingestion pipeline.