> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Publishing Applications as Add-ons

> Snapshot an application's manifests as a versioned add-on your organisation can install onto any cluster.

<Note>
  Publishing an application to the add-on catalog snapshots its committed manifests and its deploy options as one immutable version. The add-on installs independently of the application afterwards - it keeps working even if the source application is later deleted.
</Note>

## What publishing does

An application in Ankra is a repository Ankra generates Kubernetes manifests for. Publishing turns the current state of those manifests into a catalog entry your organisation can install onto any of its clusters, without going back to the application.

A publish captures three things at that moment:

* the committed manifests under the application's `manifests/` directory, plus its `.ankra/ankra.yaml` descriptor
* the **deploy options** the application declares, which become the add-on's install-time inputs
* the metadata shown in the catalog: display name, description, category

Everything is a snapshot. Later changes to the application only reach the catalog through another publish, and published versions are immutable - a version number, once used, cannot be reused.

<Info>
  This is different from [publishing an add-on to the Ankra Catalog](/platform/addon-publishing). That proposes a curation manifest to the *global* catalog every organisation sees, through a reviewed pull request. Publishing an application stays inside your organisation and takes effect immediately.
</Info>

## Before you publish

Ankra checks whether the application is publishable at all and shows the result as the first step of the publish flow. Each check reports one of:

| Status      | Meaning                                                 |
| ----------- | ------------------------------------------------------- |
| **ok**      | Nothing to do.                                          |
| **warning** | Publishing works, but something is worth knowing first. |
| **blocked** | Publishing cannot proceed until this is resolved.       |
| **unknown** | The check could not be evaluated.                       |

A **blocked** check stops the flow. A **warning** does not - it is a judgement call you are allowed to make, and it is repeated on the confirmation step so it is not lost along the way.

Where Ankra can resolve a check itself - most often a missing image registry declaration - the step offers **Fix automatically** rather than instructions. Checks that need an application admin say so instead.

## Publishing

1. Open the application and select **Publish to catalog**.
2. **Readiness** - resolve anything blocked, then continue.
3. **Details** - the version, display name, description, category, and a changelog.
   * Leave the version blank to bump the patch automatically. The field suggests the next one.
   * A version that is already published is refused here, before anything is snapshotted.
   * The changelog is shown against the version in the add-on's history. It is optional.
4. **Review** - what changed in the most recent published version, so you can see the shape of a typical change before adding another.
5. **Confirm** - a recap, any carried warnings, and what the snapshot means.

The first publish creates the add-on. Later publishes add versions to it.

## Version history

The add-on's detail page lists every published version, newest first, with its changelog, who published it, and how many files and options it carries.

**Compare** on any version shows what changed against the version published before it:

* **files** added, removed or modified, with the before and after contents side by side
* **options** added, removed or modified

A changed option is worth attention: options are the add-on's install-time input contract, so changing one is a breaking change for anyone who already installed the add-on. A version that starts or stops referencing an environment `Secret` is called out for the same reason.

<Note>
  There is no rollback and no "current version" control. An installation pins the version it was installed at, so there is nothing to roll back *to* - installing an earlier version explicitly is the equivalent, and existing installations are unaffected by later publishes.
</Note>

## Installing a published add-on

Published applications appear in **Add-ons** alongside Helm add-ons. Installing one asks for a cluster, a namespace, and values for whichever deploy options the version declares, then deploys that snapshot.

Because the snapshot is self-contained, the add-on installs even when the source application has been deleted. The catalog says so on the entry, and no new versions can be published once the source is gone.

## Unpublishing

**Unpublish** hides the add-on from the catalog without touching anything already installed. Existing installations keep running and keep reconciling; the entry simply stops being installable. Publishing a new version makes it visible again.

Deleting the add-on outright is a separate, destructive action: it tears down the installations that came from it.

## Limits

An add-on holds at most 500 published versions. Snapshots are never pruned, because installations pin the version they were installed at and removing an old snapshot would break them.