Linear Releases Feature Deep Dive: Track Every Deployment in 2026

May 20, 2026 5 Min Read

Linear Releases links your CI/CD pipeline to Linear, so every deploy shows which issues shipped. You create a release pipeline in Settings > Releases, copy its access key, and add Linear’s GitHub Action (or CLI) to your build. After that, each deploy groups the issues mentioned in its commits into a release. It is on the Business ($16 per user a month, billed yearly) and Enterprise plans.

Before this, “Done” in Linear only meant the PR merged. It did not tell you if the code was live. I have set this up for a web app and a mobile app in the same monorepo, and it took about 20 minutes each. This guide follows Linear’s Releases docs, checked in October 2026.

Why Releases matters

An issue marked Done does not always mean customers have it. Was it merged to staging or production? Is an Android fix out now, or in two weeks with the next store release? Releases answers those questions. It also gives you:

A list of what went out in each deploy
A Changelog tab per pipeline, where you can write notes or generate them with AI
Clear answers for support and sales: “Is this fix live yet?”

Plans and limits

	Free	Basic	Business	Enterprise
Price per user (yearly)	$0	$10	$16	Custom
Releases	No	No	Yes	Yes
Release pipelines	–	–	Up to 15	No limit

Prices are from Linear’s pricing page.

Continuous or scheduled? Pick per pipeline

Every pipeline is one type or the other. Make one pipeline per product and environment. For example, “Web app (production)” and “iOS (production)” are separate pipelines.

Continuous pipelines

Each push to your main branch creates a completed release right away. There are no stages and no dates. Linear scans the new commits for issue IDs like ENG-123, attaches those issues, and marks the release done.

Use continuous when:

You deploy many times a day
You use trunk-based development and feature flags
There is no human approval step before production

Scheduled pipelines

Scheduled pipelines add release dates and stages, such as Staging and then Production. Issues collect in the upcoming release as they merge. You can freeze a stage that has started, so new issues stop joining it automatically.

There is also a setting called Move open issues to the next release. When a release completes with unfinished issues, Linear moves them to the next one. Turn it on unless you want leftovers to stay on the old release.

Use scheduled when:

You ship on a weekly or two-week train
QA must sign off before production
You ship mobile apps through app stores
You need a fixed list of what entered a release for audit

Linear itself uses both. Its docs list scheduled pipelines for iOS and Android production, and continuous ones for nightly builds, internal builds and the main web app.

Setup with GitHub Actions, step by step

In Linear, go to Settings > Releases and create a pipeline. Choose continuous or scheduled.
Open the pipeline settings and generate an access key. A personal API key will not work here.
In GitHub, add the key as a repository secret named LINEAR_ACCESS_KEY (Settings > Secrets and variables > Actions).

Create a workflow file, such as .github/workflows/linear-release.yml, based on Linear’s example:

name: Linear Release
on:
  push:
    branches: [main]
jobs:
  linear-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: linear/linear-release-action@v0
        with:
          access_key: ${{ secrets.LINEAR_ACCESS_KEY }}

Push a commit that mentions an issue ID. Check the pipeline in Linear. You should see a new release with that issue.

The fetch-depth: 0 line matters. It pulls full commit history. Without it, the action cannot see the commits since the last release, and issues go missing. More options are in the linear-release-action repo.

Not on GitHub?

Linear also offers an open-source command-line tool with pre-built binaries. Any CI system that can run a command can use it: GitLab, CircleCI, Buildkite, Jenkins and others.

Monorepos: use path filters

In a monorepo, one push can touch the web app and the iOS app. Path filters fix this. They use glob patterns like mobile-ios/** or backend/api/**. A pipeline then only counts commits that change files matching its patterns. Without them, every pipeline claims every issue.

Laptop seen from above on a wooden desk — Use path filters so each pipeline only claims its own commits. Photo: Aleksi Tappura, CC0, via Wikimedia Commons.

Mistakes I see most

Commits without issue IDs. Releases relies on IDs like ENG-123 in commit messages or branch names. If people skip them, issues never attach. Use Linear’s branch names, which include the ID.
Shallow clones. Forgetting fetch-depth: 0 is the top cause of “release created, but empty.”
One pipeline for everything. Staging and production need separate pipelines, or you cannot tell where code is.
Hitting 15 pipelines on Business. With many apps and environments, you can run out. Merge low-value internal pipelines, or plan for Enterprise.
Deleting a pipeline by accident. Deleted pipelines go to Recently deleted for 30 days. After that, the pipeline and its releases are gone for good.

Who can manage pipelines

Workspace admins can delete any pipeline. Team owners can delete a pipeline only if they own every team linked to it. Pipelines with no linked team can only be deleted by admins.

What experienced teams do

Name releases by version on scheduled pipelines, not by commit hash. Support teams talk in versions.
Freeze the stage on code-freeze day. Then late merges roll into the next release on their own.
Turn on auto-generated changelogs for production pipelines, then edit before sharing with customers.
Start with one pipeline. Prove it on your main app before adding mobile and internal builds.

When NOT to use Releases

You are on Free or Basic. It is not available. Upgrading just for this is hard to justify for small teams.
Your team does not reference issues in commits. Fix that habit first, or Releases will be mostly empty.
You already have release tracking you trust, like a deploy dashboard tied to Jira versions. Two systems will disagree.

Common questions

Which Linear plans include Releases?

Business and Enterprise. Business supports up to 15 pipelines. Enterprise has no pipeline limit.

What is the difference between continuous and scheduled pipelines?

Continuous creates a completed release on every push to main. Scheduled adds release dates and stages, collects issues over time, and lets you freeze a stage.

Can I use my personal Linear API key?

No. Each pipeline has its own access key. Generate it from the pipeline’s settings.

Does Linear Releases work with GitLab or Jenkins?

Yes. Use Linear’s command-line tool, which runs in any CI system that can execute commands.

Why is my release empty?

Usually the checkout was shallow, or commits do not mention issue IDs. Set fetch-depth: 0 and use Linear branch names.

How do monorepos work with Releases?

Set path filters on each pipeline. Then only commits that change matching files count for that pipeline.

Setup steps and limits checked against Linear’s docs and pricing page on October 14, 2026. Features change; confirm in your workspace.

Linear Releases Feature Deep Dive: Track Every Deployment in 2026

Why Releases matters

Plans and limits