The app catalog brings proven applications to your Kapsule cluster as tested blueprints. You give a name, a domain and the cluster; Clusterward creates the application, database, a disk with snapshots and the certificate and rolls out. After that it is an ordinary application in the cockpit – nothing stays tied to the blueprint.
The app catalog is a collection of blueprints for ready-made applications. A blueprint knows how an app runs best on your cluster: Helm chart, database, disk, cron job and certificate. You answer only what is yours – name, domain, cluster and, where the app needs one, the database instance. Clusterward maintains the blueprints and tests each one live before it appears in the catalog.
A new blueprint joins the catalog only after it has run on a real cluster.
A WordPress site with its own MySQL database, a 10 GiB disk for uploads, themes and plugins, a real cron job and a certificate.
Go to WordPressA status and uptime monitor with status pages for your customers – no database, the data lives on a 2 GiB disk.
Go to Uptime KumaFor anything the catalog does not cover: an empty application in which you create the build, environment and service yourself – from GitHub or a container image.
Go to DeploymentsApps → “App catalog”. The tile shows what the app needs, for example a MySQL instance.
Name, domain, cluster and, where needed, the database instance. Clusterward checks cluster, name and domain first.
Application, environment production, chart, database, service with its disk, domain and DNS record – then the deploy.
Behind the setup password you set the app up, then “Open to everyone” opens it to all.
Every blueprint runs on a real cluster before it appears in the catalog. The image is pinned to the tested version.
Every app gets its own disk with daily snapshots, kept for seven days, restorable on the Volumes card.
Let’s Encrypt for your domain. If the zone is registered at Cloudflare or Scaleway DNS, the record is created automatically.
Otherwise a fresh app shows its installer to whoever arrives first. The setup password keeps strangers out until your account exists.
If a step fails, “Retry” continues from there. “Roll back…” removes everything the run created, in reverse order.
Logs, usage, restart, domain and resources are managed on the usual pages; the chart sits versioned in your templates.
The catalog never creates a database instance – it takes about ten minutes and Scaleway bills it on its own. Everything else is created in the run.
| What | You | The catalog |
|---|---|---|
| Cluster | with the NGINX ingress controller | checks it before starting |
| Database | an instance of the engine where needed (WordPress: MySQL) | a database and its own user on it |
| Domain | a free hostname | certificate, record in registered zones |
| Rights | view of all applications, databases at “Operate” | nothing else |
| Plan | applications left in the plan | disables the tiles when the limit is reached |
What each blueprint creates in detail is described on the pages for WordPress and Uptime Kuma. How the disks are backed up and restored is covered under Volumes & snapshots.
For applications the catalog does not cover, you create the build, environment and service yourself – described under Deployments. If you need the same app for every customer, use a tenant pipeline.
Database, disk with snapshots, cron and certificate in minutes.
Go to WordPressStatus pages and checks, no database.
Go to Uptime KumaDisks per service, scheduled snapshots and restore.
Go to VolumesYour question isn’t here? Write to us – we usually reply the same working day.
Ask a questionWe create an app from the catalog, open it behind the setup password and show how it carries on as an ordinary application.
