Clusters

A cluster is the Kubernetes environment your deployments and managed databases run on. Mengi provisions it on the cloud provider of your choice — AWS, Azure, Google Cloud, Hetzner, Scaleway, DigitalOcean or Thalassa — and keeps it healthy, up to date and matching the configuration you chose. You never have to install or operate Kubernetes yourself.

Shared vs. dedicated clusters

Shared — a managed, multi-tenant environment. Cheapest and fastest to start; nothing to size or maintain. You usually don’t create one explicitly — it’s set up for you when you deploy to a shared region.
Dedicated — your own single-tenant cluster with its own nodes, in the exact provider and region you choose. Required for features like custom domains, high-availability databases and Bring Your Own Cloud.

See Shared vs. dedicated clusters in the deployments guide for help choosing. The rest of this guide focuses on dedicated clusters.

Tiers

Tier	What you get	Best for
Shared	A slice of a managed, multi-tenant cluster	Prototypes, hobby projects
Dedicated	Single-tenant cluster with 1 worker node and a shared load balancer. No SLA.	Development, testing, staging
Dedicated HA	Single-tenant cluster with 3 worker nodes and a dedicated load balancer. SLA included.	Production workloads

The tier is fixed for the lifetime of a cluster — you can’t switch a cluster between tiers later. You can change its node size and node count at any time (see Autoscaling and Resizing nodes).

Part 1 — Create a cluster

Start from New cluster in the dashboard. The wizard has three steps.

1. Cluster type

Choose Shared, Dedicated or Dedicated HA (see Tiers). Each card shows its monthly price up front.

2. Provider

Pick a cloud provider. Providers are listed with their starting price for the chosen tier; the info button on each card opens a full cost breakdown (control plane, worker nodes, load balancer, storage, platform fee and VAT). For a shared cluster this step is skipped — you only pick a geographic region.

3. Configuration

Name — lowercase letters, numbers and hyphens (3–63 characters, starting with a letter). Must be unique within your account.
Region — a specific provider region (e.g. Falkenstein, eu-west). Shared clusters use a geographic region (e.g. Europe, North America) instead.
Bring Your Own Cloud (optional) — run the cluster in your own cloud account using a validated cloud credential. You pay the provider directly for the infrastructure; Mengi bills only the platform fee.
Autoscaling (optional) — let the cluster add and remove worker nodes based on demand, within a minimum and maximum you set (defaults: 1–5 for Dedicated, 3–10 for Dedicated HA). You can change this any time after creation.
Multi-location (Hetzner, Dedicated HA only) — spread worker nodes across two or three European datacenters (Falkenstein, Nuremberg, Helsinki) so the cluster survives a datacenter outage.

The wizard shows an estimated monthly cost and an estimated creation time before you confirm. A verified payment method is required; if you haven’t set one up yet, the wizard takes you to billing and brings you back.

After you confirm, the cluster moves through pending → provisioning → running. Creation typically takes 10–25 minutes depending on the provider (shared clusters are usually ready in a couple of minutes). The Kubernetes version is selected automatically — new clusters always start on the latest version Mengi supports for that provider.

If provisioning runs into trouble, the cluster shows a message and a Retry provisioning action. Retrying restarts provisioning from a clean state; via the API you can also retry into a different region if the original one is at capacity.

Managing a cluster

From a cluster’s page you can:

Watch health and metrics — node readiness, CPU and memory usage, pod counts, and a live list of nodes and workloads.
See costs — month-to-date spend and the projected monthly total.
View recent events and logs, with a link to the full observability view.
Download the kubeconfig — full direct access to your own cluster with standard Kubernetes tooling, any time.
Open Settings — autoscaling and (for multi-location clusters) the datacenter selection.
Manage upgrades and components — see the sections below.

Autoscaling

Autoscaling adds worker nodes when your workloads need more capacity and removes them when demand drops, always staying within the minimum and maximum node counts you set.

Change it under Settings on the cluster (or when creating it). Changes take effect from the next scaling event — running workloads are not interrupted. Autoscaling is per-cluster and only applies to dedicated clusters; shared clusters scale automatically behind the scenes.

Extra nodes beyond the tier’s base count are billed at the per-node rate shown in the cluster’s cost breakdown.

Resizing nodes

You can change a dedicated cluster’s node machine type in place — for example moving from 2 vCPU / 4 GB nodes to 4 vCPU / 8 GB nodes — without recreating the cluster. This is currently available via the API.

When you change the machine type:

Worker nodes are rolled to the new type one batch at a time.
The cluster’s identity, public addresses and persistent volumes survive.
Expect a brief disruption while pods move to the new nodes — apps with multiple replicas stay available throughout.

The cluster must be running to resize. Remember the tier (node count, load balancer, SLA) is fixed — resizing changes how big each node is, not how many you get.

Kubernetes version upgrades

Mengi tracks the Kubernetes versions each provider supports and lets you upgrade with one approval — no manual node juggling.

Upgrading manually

Open the Kubernetes Upgrade dialog from the cluster (the upgrade arrow, or the version badge when an upgrade is available). It shows your current version and the newer versions available, with the recommended one marked. The flow is:

Request — pick a target version and request the upgrade. Before requesting, review the Kubernetes changelog and check your apps are compatible.
Approve & Start — the request waits for your explicit approval, so a teammate (or you, after a second look) confirms before anything changes. You can Cancel a request instead at any point before it starts.
Upgrade runs — the cluster status changes to upgrading and a progress message is shown.

Only one upgrade can be pending or in progress at a time, and upgrades can only be started on a running cluster. The dialog also keeps a full upgrade history (completed, failed and cancelled requests).

Automatic scheduled upgrades

When a new Kubernetes version becomes the default for your provider, Mengi schedules an upgrade automatically about 30 days out for clusters on the old version:

You’re emailed immediately, with reminders 7 days and 1 day before.
The cluster shows a banner with the scheduled date.
Click Update Now to run the upgrade early at a time that suits you, or cancel the request from the upgrade dialog if you need more time.
If you do nothing, the upgrade runs automatically on the scheduled date.

What happens during an upgrade

Upgrades are rolling: nodes are upgraded one at a time, and workloads are moved off each node before it’s upgraded. Apps with multiple replicas stay available throughout; single-replica apps may see a brief restart. Persistent volumes and configuration are untouched. You can’t delete a cluster while an upgrade is in progress.

Cluster components

Besides Kubernetes itself, every Mengi cluster runs a set of platform components — ingress, certificate management, monitoring agents and so on. Mengi keeps these updated for you; you choose how eagerly via a release channel.

Open Cluster Components from the cluster (the package icon). It shows the component version currently in use (read-only) and two channels:

Stable (recommended for production) — platform-tested releases.
Latest — always the newest component versions, including changes still being rolled out.

New clusters start on a stable release. After you switch channels, the change is applied within a few minutes; the cluster must be running to change it. If the dialog says the version is managed by Mengi Cloud, the platform is handling this cluster’s component updates — selecting a channel hands updates over to that channel.

Keeping infrastructure in sync

Everything about a cluster is declarative — Mengi continuously reconciles the real infrastructure against the configuration you declared. If you suspect the two have drifted (for example after making manual changes in your cloud provider’s console on a BYOC cluster), you can trigger a drift check via the API: Mengi compares the running infrastructure to the declared state and corrects any differences. Drift checks are available for running clusters and also run periodically in the background.

Deleting a cluster

You can delete a cluster from the dashboard at any time, after a confirmation step. A few things to know:

Deployments and databases block deletion — delete (or move) them first. The delete button tells you how many are still on the cluster.
Deletion removes all of the cluster’s infrastructure: nodes, load balancer, networking and storage volumes — including the data on them. Deletion is permanent; back up anything you need first.
Imported clusters are not destroyed — deleting one removes it from Mengi and cleans up Mengi’s access, but the cluster and its workloads keep running in your cloud account.
You can’t delete a cluster while a Kubernetes upgrade is in progress.

Good to know

The tier is immutable — pick Dedicated HA from the start for anything that will carry production traffic. Node size and count can be changed later; the tier can’t.
Your deployments inherit the cluster’s provider and region, so place the cluster where your users are.
Keep production clusters on the Stable component channel; use Latest on a development cluster if you want new platform features first.
Don’t postpone Kubernetes upgrades indefinitely — providers retire old versions, and staying one version behind the default keeps upgrades small and low-risk.
The kubeconfig download gives you direct access for debugging, but changes you make by hand aren’t part of your declared configuration — make lasting changes through the dashboard or API instead.
Already have a cluster? You can import an existing Kubernetes cluster into Mengi from New cluster → Import existing cluster and manage its workloads through the dashboard.