Skip to main content
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.

​
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.
This is different from publishing an add-on to the Ankra Catalog. 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.

​
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: 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.
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.

​
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.