Kwirth does not ship a fixed set of features — it installs them. A marketplace is the catalogue it installs from: one for the open source extensions anyone can use, and as many of your own as you need for the ones only your organisation should see.
A marketplace is not a server you have to run. It is one file: a manifest listing extensions — an id, a name, a version, a description and the URL of the package itself. Kwirth reads that file, shows you what is in it, and downloads a package only when you press install.
Two consequences are worth knowing before you set one up.
Your marketplaces take precedence over the public one. Resolution happens per extension id: the first catalogue in your list that publishes that id is the one that serves it. So you can ship your own build of a public extension, and the clusters that trust your catalogue get yours.
Listing and hosting are separate. The manifest only says where a package lives; it does not hold the package. A public manifest pointing at a private registry is a perfectly normal setup — and the one we recommend, because the manifest then carries no secrets at all.
Kwirth reads manifests from the backend, not from your browser: a catalogue reachable from the cluster works even if your own machine cannot see it.
It is already configured — there is nothing to add. It lives in the Kwirth repository itself, one manifest per family of extension, and it is the catalogue every Kwirth falls back to.
What is in it today:
Every entry keeps its older versions in the manifest too, so installing is not limited to whatever happens to be newest: the extension manager lets you pick the version, and updating is installing on top without losing the extension's configuration.
You register your own in Kwirth settings → Marketplaces: a name, the URL of the manifest, and whether it is consulted at all. That is the whole setup.
They exist for two quite different reasons, and both are common:
A marketplace can protect one thing: reading the manifest. If yours lives in a private GitHub, GitLab or Nexus repository, you tick Manifest needs a token, pick the header that host expects and paste the token. Kwirth stores it encrypted, outside the settings, and the backend is what uses it.
Downloading the packages is configured separately, under Package registries — which is what lets the recommended setup work: a manifest anyone may read, pointing at packages only your clusters may download.
A catalogue can also list a pack — a single entry that brings several extensions at once, with their documentation and their login page if they have one. It is how a product made of four pieces gets installed as one thing, and removed as one thing.
Manifest format, the header each host expects, package registries, and how resolution behaves when two catalogues publish the same id.
Marketplace docs → See a real manifest