What do I need before I create Uptime Kuma?

A cluster with the NGINX ingress controller and a domain no other service uses yet. You do not need a database instance. If the domain’s zone is registered at Cloudflare or Scaleway DNS, Clusterward creates the record itself; otherwise it shows the address it has to point to.

Does Uptime Kuma need a database?

No. The blueprint runs Uptime Kuma 2 with SQLite; monitors, history and settings live on the application’s 2 GiB disk, which gets a snapshot every day.

What is the setup password for?

A fresh Uptime Kuma shows its account page to whoever arrives first, and whoever fills it in owns the monitor. So a new instance first asks for the user “setup” and the password from the run page. After your admin account, press “Open to everyone”: the protection goes and the password is deleted.

Can I put Cloudflare in front of it?

Yes, after setup. During setup the record should be DNS only, because the certificate is issued through it. After that you can switch it to “Proxied”; Cloudflare passes the dashboard’s WebSocket connection through.

How do I update Uptime Kuma?

The image is pinned to the tested major version (2-slim-rootless). To update, enter a new image tag on the service page and restart; the data stays on the disk. Before a jump, an on-demand snapshot is worth it.

What happens if a step fails?

The run page shows which step failed and why. “Retry” continues there once the cause is fixed. “Roll back…” removes everything the run created, in reverse order; the chart stays in your templates.

What happens to the data when I remove Uptime Kuma?

The disk survives an undeploy: it is marked so that Helm leaves it in place on uninstall, and a new rollout mounts it again. You delete it for good on the service’s Volumes card, after a final snapshot.

Does Uptime Kuma cost extra?

Not at Clusterward: billing is per cluster, not per application. At Scaleway you pay for the 2 GiB of Block Storage, the snapshots and the pod’s share of your nodes – it reserves 50 m CPU and 128 MiB of memory.

App catalog

Uptime Kuma on Kubernetes: your status monitor in a few minutes

Uptime Kuma checks your websites, APIs and servers from the outside and shows availability and outages on status pages. From Clusterward’s app catalog it runs in your own cluster: give a name, a domain and the cluster, no database needed – a disk with snapshots, a certificate and protection until setup come with it.

Book a demo Logs & monitoring

Uptime Kuma run in the app catalog of the Clusterward cockpit: all steps done, setup password active (simplified illustration) — Illustration: a simplified view. The product shows more details and options.

In short

What the app catalog does for Uptime Kuma

Uptime Kuma is a free status and uptime monitor. Clusterward’s app catalog brings it to your Kapsule cluster as a ready-made blueprint: an application of its own with a Helm service that runs Uptime Kuma 2 from the rootless image, keeps its data in SQLite on a disk of its own with daily snapshots and is reachable through a Let’s Encrypt certificate. After that it is an ordinary application in the cockpit.

At a glance

Inputs: Name, domain and cluster
Database: none – SQLite on the disk
Disk: 2 GiB, daily snapshots, 7 days
Image: Uptime Kuma 2, rootless, pinned
Certificate: Let’s Encrypt for your domain
Protection: Setup password until the first account

How it works

From three fields to a running monitor

01
Pick the blueprint
Apps → App catalog → Uptime Kuma. Enter a name, a domain and the cluster – the cluster needs the NGINX ingress controller.
02
Clusterward creates
Application, environment production, chart, service with its disk, domain and – in a registered zone – the DNS record. Then the deploy.
03
Create your account
The site first asks for the user setup and the password from the run page. Behind it you create your admin account in Uptime Kuma.
04
Open to everyone
“Open to everyone” removes the protection and rolls out again. Then you set up monitors and status pages.

What’s included

What every Uptime Kuma instance from the catalog brings

What you would otherwise work out yourself on the first Helm install.

Status pages for your customers

Uptime Kuma shows availability and outages on public status pages – under your own domain.

No database needed

The data lives in SQLite on the application’s disk. You need no database instance, and no database costs are added.

Disk with snapshots

2 GiB of Scaleway Block Storage, a snapshot every day, kept for seven days. Restore and on-demand snapshots from the Volumes card.

Protected until setup

A fresh Uptime Kuma shows its account page to whoever arrives first. The setup password keeps strangers out until your admin account exists.

Certificate and DNS

Let’s Encrypt for your domain. If the zone sits at Cloudflare or Scaleway DNS and is registered, the record is created automatically.

Live dashboard without drops

The dashboard holds a long-lived WebSocket connection. The ingress keeps it open for up to an hour instead of cutting it after a minute.

Rootless and pinned

The image runs without root and is pinned to the tested major version. An update is a new image tag on the service page.

Retry or roll back

If a step fails, “Retry” continues from there. “Roll back…” removes everything the run created, in reverse order.

Then an ordinary application

Logs, usage, restart, domain and resources are managed on the usual pages. Nothing stays tied to the blueprint.

Standards, not home-made

Built on standards

Helm chart
A plain chart in your templates, versioned as “Uptime Kuma (catalog)”.
Uptime Kuma 2
The official image in its slim-rootless flavour, without the embedded MariaDB.
Scaleway Block Storage
One volume per instance, snapshots directly at Scaleway.
cert-manager
Let’s Encrypt via HTTP-01 for the domain, renewed automatically.

What changes

Uptime Kuma on Kubernetes with and without the catalog

Facts

What you prepare, what the catalog creates

Uptime Kuma needs less than WordPress: no database instance, just a cluster with the NGINX ingress controller and a domain.

What	You	The catalog
Cluster	with the NGINX ingress controller	checks it before starting
Domain	a free hostname	certificate, record in registered zones
Database	nothing	not needed
Data	nothing	2 GiB disk, daily snapshots
Resources	nothing	50 m CPU and 128 MiB reserved, up to 500 m and 512 MiB

Two tools

Uptime checks on the service or Uptime Kuma?

Clusterward checks the domains of your services itself: uptime checks on a service report an outage after two failures to your channels – for your team, with nothing to install. Uptime Kuma is for what your customers should see: public status pages, monitors for services outside Clusterward and a history of its own.

Side by side

Uptime checks: on the service, alert to your team
Uptime Kuma: a monitor of its own in the cluster, status pages
Checks: Checks your services’ hosts, Kuma any reachable service
Cost: both in the plan, Kuma needs a disk and a pod

Uptime Kuma in context

Uptime Kuma is the second blueprint in the app catalog after WordPress. How its disk is backed up and restored is described under Volumes & snapshots, how the domain gets its record under DNS & certificates.

What Clusterward shows on every service without Uptime Kuma – logs, usage and uptime checks with alerts – is covered under Logs & monitoring.

Related pages

What goes with it

Logs & monitoring

Logs, 30 days of usage and uptime checks on the service.

Go to Logs & monitoring

WordPress from the catalog

Database, disk with snapshots, cron and certificate in minutes.

Go to WordPress

Volumes & snapshots

Disks per service, scheduled snapshots and restore.

Go to Volumes

FAQ

Frequently asked questions about Uptime Kuma on Kubernetes

A cluster with the NGINX ingress controller and a domain no other service uses yet. You do not need a database instance. If the domain’s zone is registered at Cloudflare or Scaleway DNS, Clusterward creates the record itself; otherwise it shows the address it has to point to.

Your question isn’t here? Write to us – we usually reply the same working day.

Ask a question

Uptime Kuma in the demo

We create an instance from the catalog, open it behind the setup password and set up the first monitor with a status page.

Book a demo