You enter a name, a domain, the cluster and your MySQL instance. Clusterward creates the application, database, disk with daily snapshots, cron job and certificate, then rolls out WordPress. Until you have finished the installation, a password keeps strangers off the site.
Running WordPress on Kubernetes usually means picking a chart, writing values, creating a database, planning the disk, setting up cron, getting a certificate and hoping nobody opens the installer before you do. The Clusterward app catalog handles all of that with a template that we maintain and test live before adding it. The result is a perfectly ordinary application in your cockpit: every setting stays editable, and nothing is tied to the template afterward.
Name, domain, cluster and MySQL instance – that is all the catalog asks for.
Application, database, disk, service and DNS record are created, every step visible.
Run the WordPress installer behind the setup password and create your admin account.
“Open to everyone” removes the protection; after a minute the site is reachable for everyone.
Everything that makes WordPress on Kubernetes stable is set up from the start.
A MySQL database with its own user on your instance. The password is generated and only referenced in the values, never written into them.
WordPress, themes, plugins and uploads live on a 10 GiB disk with daily snapshots, kept for seven days and restorable with one click.
A Kubernetes cron job calls WP-Cron every five minutes. Scheduled posts and plugin tasks run on time, even when nobody visits the site.
A fresh WordPress site belongs to whoever opens the installer first. That is why the site asks for a setup password until you are done.
The domain gets a Let’s Encrypt certificate. If the zone is managed in Clusterward, the DNS record is created along with it.
If a step fails, the run page tells you why. “Retry” picks up from there; “Roll back…” removes everything the run created.
Resources, domains, networking, values: everything can be changed on the usual pages. Clusterward writes a new domain into the chart’s host; the template itself no longer writes anything.
Logs from all instances, 30 days of usage and uptime checks work for the WordPress site just as they do for any service.
Each additional site gets its own application and database on the same MySQL instance – ideal for agencies with many client sites.
The site runs on the official WordPress container, not on a custom build. New sites run the tested major version 6; to upgrade, change the image tag on the service.
The chart sits in your templates as “WordPress (catalog)”. A new chart version becomes the next version; existing sites keep theirs.
The database lives on your MySQL instance in the private network, backed up by Scaleway.
The disk is Scaleway Block Storage, backed up as snapshots in your project.
You need two things in the cluster beforehand; everything else is created during the run.
| Component | Who | Note |
|---|---|---|
| Cluster with NGINX ingress controller | You, once | Cluster page → Ingress controller |
| MySQL instance in the same cluster | You, once | Cluster page → Managed databases, about ten minutes |
| DNS zone | Optional | Registered: record created automatically, otherwise by hand |
| Application and production environment | Catalog | Its own namespace on the cluster |
| Database, disk, cron, certificate | Catalog | Daily snapshots, seven days |
| WordPress admin account | You | In the installer, behind the setup password |
Uptime Kuma checks your websites and services from the outside and shows availability and outages on status pages. From the app catalog, a name, a domain and the cluster are enough; no database is needed. As with WordPress, a setup password keeps strangers out until you have created your account; after that, “Open to everyone” opens the site.
How the disk is backed up and restored is shown in Volumes & snapshots; you create the database instance under Managed databases.
If you run many client sites, Agencies & studios covers roles per client; logs and uptime checks for every site are described in Logs & monitoring.
Persistent data with a snapshot before every deletion.
Go to Volumes & snapshotsMany client projects in one cockpit, roles per client.
Go to Agencies & studiosLogs from all instances, usage and uptime checks on the service.
Go to Logs & monitoringCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionTogether we create a WordPress site, run the installer behind the setup password and back up the disk with a snapshot.
