Release Management

A release gathers the tasks that ship together, the checks that prove it is ready, the people who must sign it off, and the environments it is deployed to. Atlas works out how ready a release is from its scope, its required checks and its sign-offs, and says plainly what blocks it. It records what your pipeline did and does not run the pipeline itself.

• Start a release from one of ten built-in templates (standard, hotfix, major launch, mobile app, infrastructure change, security patch, regulated release, data migration, feature flag rollout and marketing launch) or from one your team made, and the type, next version, dates, readiness checks, pipeline and notes outline are filled in. Every value can be changed before the release is created
• Gather the tasks that ship in it from any project in the workspace, and see how many are done
• Keep a readiness checklist of quality, security, documentation, operations and communication checks, each required or optional
• Ask named people to sign off and record each decision with its comment. Each person asked is notified, and the owner is told how each decision came out
• A readiness score weighted 50% on scope, 30% on required checks and 20% on sign-offs, with every blocker listed in plain words. A release cannot be marked Released while something blocks it, unless a workspace owner or administrator overrides it with a recorded reason
• Record each deployment to an environment with its status and times, follow the pipeline from the first environment to the last, remove a deployment that is still planned, and roll a release back
• Draft release notes from the finished scope, grouped into features, fixes and other changes, then edit and publish them inside the workspace
• See releases as cards, as a list, as a board by status, and as a calendar that shows every moratorium window

• A release cannot move to Released while it has no scope, while scope tasks are not done, while a required check is not done, or while a sign-off is pending or rejected. A target day in the past is a warning and not a blocker. A moratorium refuses on its own terms and an override does not lift it: only an approved exception, or a release type the moratorium lets through, turns its block into a warning.
• Only a workspace owner or administrator can release past a blocker. They must write a reason of up to 500 characters, and the reason is recorded with the release.
• Only the person who was asked can approve or reject their own sign-off. Asking the same person again resets their earlier decision to pending.
• A Released or Cancelled release no longer accepts changes to its scope, checklist or sign-offs. Cancelled is final. A released release can only be rolled back, and it cannot be deleted.
• Only the owner of a release, or a workspace owner or administrator, can delete it, and only before it is released. Tasks you are not allowed to read are not listed in a scope, and the API reports how many are hidden.
• Atlas records deployments and does not run your build or deploy pipeline. Enter a deployment by hand, or send it through the API from your pipeline. A release holds at most 2000 tasks and 100 checks, and one request can ask at most 20 people.

1. 1Open Releases from the sidebar, under Plan, or press the command key and K and search for it.
2. 2Choose New release, start from a template or from a blank release, check the name, version, dates, checks and pipeline, then choose Create release.
3. 3Open the release and add the tasks that ship in it. You can search tasks from any project in the workspace.
4. 4Add the checks that must pass before it ships, such as a security review or a documentation check, and mark each required or optional.
5. 5Choose Request sign-off and pick the people who must agree. Each one is notified and approves or rejects with an optional comment.
6. 6Move the release to In progress with Start work, and to Ready with Mark ready when the work is done.
7. 7Choose Draft notes to write release notes from the finished scope, edit them, then choose Save notes and Publish notes.
8. 8Choose Record deployment for each environment as it goes live. When nothing blocks the release, move it to Released.
9. 9Open Release templates to save your own plan as a template, and Moratoriums to add the periods when nobody should ship.

Why can I not mark a release as Released?

Something still blocks it. Open the release and read the readiness panel, which lists every blocker: no scope, scope tasks that are not done, required checks that are not done, sign-offs that are pending or rejected, or an active freeze window on Production. Resolve each one and try again. A workspace owner or administrator can release past a blocker by writing a reason.

How is the readiness score worked out?

Scope counts for 50%, required checks for 30% and sign-offs for 20%. A release with no scope scores 0. The score is a guide to how much is left, and the list of blockers is what decides whether the release can move to Released.

Who can override a blocker?

Only a workspace owner or administrator. They write a reason of up to 500 characters when they release, and the reason is recorded with the release and in its activity. Anyone else who tries to override is refused.

What is a moratorium?

A period when the workspace does not ship, such as a festival, a public holiday, a sale or a compliance window. Open Moratoriums under Releases to add one with its reason, its days and times in a time zone, whether it repeats every year or every week, and the environments and projects it covers. Choose how strongly it is enforced: warn only, block deployments, block releasing, or a full freeze in which nobody can create a release at all. Only workspace owners and administrators can change moratoriums. Every screen shows a window in the time zone it is written in and names that zone. When your own clock reads it differently, your time is shown beneath it.

How do I get a release through a moratorium?

Open the release, choose Request an exception and write why it must go ahead. A workspace owner or administrator other than you approves or rejects it from Moratorium exceptions, and an approved exception turns the block into a warning for that release only. A moratorium can also let chosen release types through, such as a hotfix. An exception cannot unlock creating a release during a full freeze, because an exception belongs to a release that already exists.

Does Atlas deploy my release?

No. Atlas records what your pipeline did. You enter a deployment by hand or send it through the API with its environment, status and times. Recording a deployment does not start one.

How do release notes get written?

Choose Draft notes and Atlas writes Markdown from the finished tasks in the scope, grouped into features, fixes and other changes. Edit the text, save it, and publish it inside the workspace. Saving new text withdraws an earlier publication, so what is published is what was reviewed. You can also copy the notes as Markdown.

How is this different from the Atlas release notes?

The Atlas release notes are the product changelog that Atlas writes for everybody, and What is new in the account menu opens the newest one. Release Management is your own workspace: the releases you plan and ship, with their scope, checks, sign-offs and deployments.

Can an assistant or my pipeline use it?

Yes. The API and the Atlas MCP server cover every action on the screen: list, create, change and delete releases, create them from templates, move their status, manage scope, checks, sign-offs, deployments, notes, templates, moratoriums and exceptions, and read the calendar. A token needs the releases:read scope to read and releases:write to change. Sixteen webhook events, from release.created to release_moratorium.blocked, report each change.