Managed applications catalog

The catalog is usually the reason people take the platform in the first place. Instead of “please set up PostgreSQL for us”, a person opens a list and orders a database the way they would order a virtual machine.

What is on the list

The catalog is split into four groups, and the exam names them in English: Databases, Messaging, Platform services, and Networking services.

Virtual machines and Kubernetes clusters live in the same API group, but the exam assigns them to other domains — virtualization and multi-tenancy — rather than to the catalog.

One item in platform services comes as a surprise: Tenant is a catalog application too. That is exactly how nested tenants are created — an administrator orders a child tenant from the catalog, just as they would order a database.

The list grows from version to version, and there is no point memorizing all of it. What gets asked is something else — that they are all built the same way.

One mechanism for everything

This is worth understanding once, so you never have to come back to it.

You create an object. The platform creates a HelmRelease for it, Flux deploys the chart — and the chart in turn brings the operator, which from then on runs your database: it watches replication, takes backups, and switches the primary copy over on failure.

The platform does not write its own database engines — it uses well-known operators. Their names come up in questions:

Remember the order of the links exactly this way: the operator comes from the chart, it does not precede it.

Two practical conclusions follow from this, and both show up in questions. First: the dashboard does nothing special — clicking the button assembles exactly the same object and sends it to the API. Second: if a service has not come up, look at the HelmRelease instead of guessing from the pods.

Which application types exist on a particular cluster is shown by a single command:

kubectl api-resources | grep apps.cozystack

The platform writes the result back into the object itself — into status.conditions. A healthy application has Ready: True there; if it does not, go further down the chain, to the HelmRelease.

Three paths to the same thing

The dashboard is a form with fields. The fields come from the application’s definition, so the list of parameters always matches the platform version.

kubectl is the same object as text. This path matters not because it is more convenient, but because the definition can be reviewed, stored in Git and rolled back. A button click cannot be rolled back.

Terraform is for those whose infrastructure is already described in it. The official provider is called cozystack/cozystack; the name is worth remembering, it gets asked.

And a warning common to all three paths: kubectl delete on an application object wipes out the application entirely — together with its pods and data. Treat this command the same way you would treat deleting a database.

What you set when ordering

Each service has its own set of fields, but three things are almost always there.

Size (resourcesPreset) — how many resources to give. It is set not with numbers but with a ready-made preset such as t1.micro or u1.medium: the platform substitutes concrete values behind it.

Storage (storageClass) — how much space and of which class. replicated keeps several copies on different nodes; local is faster but lives on a single one.

Users and databases — the platform creates them itself. That is exactly why the schema file you apply afterwards contains no commands to create the database and the user: they have already been run.

The platform generates passwords itself and puts them in a secret. In the dashboard it is visible on the Secrets tab of the application itself.

High availability is not free

When ordering a service, you choose the number of replicas. One replica is a training setup: the node goes away, and the service goes with it. With two or more, the platform itself keeps track of which one is primary and switches over on failure.

This is also where a common trap lives: service high availability and data safety are different things. Replicas save you from a node failure, but not from a dropped table. For the latter you need backups, and they have a lesson of their own.

What version 1.5 brought

Three facts from this release are asked about directly. Encryption of client connections (TLS) arrived for four services: Kafka, NATS, Qdrant and PostgreSQL. Backups of managed applications started working out of the box — previously an administrator first had to set up storage for them. And ApplicationDefinition appeared: the mechanism registers a new application type in the catalog on top of a Helm chart, and that type immediately gets its own API object, a form in the dashboard and the same chain with a HelmRelease. This is how organizations add their own services to the shared catalog — the catalog is not a closed list.

We have covered the catalog, but one of its items — virtual machines — deserves a separate look: it has a model of its own, and habits from vSphere let you down here.

Further reading: managed applications · Kubernetes clusters