Import a Cluster

If you already run a Kubernetes cluster — at a cloud provider or anywhere else — you can import it into Mengi Cloud. Importing brings the cluster under Mengi management: you can deploy to it from the dashboard, watch status and health, and even adopt the workloads that are already running on it (see Discover Workloads).

An imported cluster behaves like a dedicated BYOC cluster — the infrastructure stays yours and in your account; Mengi only installs the components it needs to manage deployments on it.

What Mengi installs on your cluster

When you import a cluster, Mengi installs its platform component bundle — certificate management, secret management, ingress and monitoring — into their respective namespaces (mengi-system, traefik, cert-manager, external-secrets and monitoring). A few cluster-scoped resources are also created:

an IngressClass named mengi-traefik — not set as the cluster default, so existing routing is untouched;
the custom resource definitions (CRDs) the ingress and certificate-management components need;
a Let’s Encrypt ClusterIssuer, so deployments get automatic HTTPS;
a management service account in the mengi-system namespace, which is how Mengi talks to the cluster from then on.

If your cluster already has its own ingress controller or certificate-manager installation, the import would conflict — that’s exactly what the preflight check catches before anything is installed.

Requirements

A reachable cluster — the Kubernetes API server must be accessible from the internet.
A way for Mengi to connect, either:
- a cloud credential (AWS, GCP, Azure or Scaleway) so Mengi can discover the clusters in your account, or
- the cluster’s kubeconfig with administrator access, pasted in directly. Mengi uses it during import to set up its own service account, then switches to that account — see Good to know.
No conflicting platform components already installed (verified by the preflight check).
A unique, lowercase name for the cluster in Mengi.

The preflight check

Before importing, Mengi inspects the cluster and reports anything that would collide with the components it installs. The check is read-only — nothing is changed on your cluster.

What’s checked	Result if found
An IngressClass named `mengi-traefik`	Blocks — Mengi installs one with exactly this name
CRDs belonging to an existing ingress controller, certificate manager or secret-management operator	Blocks — installing the same CRDs again would conflict
ClusterIssuers named `letsencrypt-prod` / `letsencrypt-staging`	Blocks — Mengi owns these names
Another IngressClass marked as the cluster default	Warning — Mengi’s IngressClass is not made the default, so workloads that don’t name an ingress class keep routing through your existing controller
One of Mengi’s component namespaces already exists and contains workloads	Warning — components installed into it may collide with what’s there
A kubeconfig that can’t be parsed, or an unreachable API server	Blocks — fix the credentials and try again

All detected conflicts are listed at once, so you can resolve everything in one pass. Errors block the import; warnings are informational and don’t stop you. If a blocking conflict is reported, resolve it on the cluster (or contact support for help) and run the check again.

Import a cluster — step by step

Open the import page — from the clusters page, click New cluster, then Import existing cluster.
Point Mengi at the cluster, using one of the two tabs:
- Discover from Cloud — pick one of your cloud credentials (AWS, GCP, Azure or Scaleway) and Mengi lists the Kubernetes clusters in that account, with their region, version and status (GKE Autopilot clusters are supported and labelled). Select the one to import and optionally give it a different name.
- Paste Kubeconfig — enter a name, the provider and region, and paste the cluster’s kubeconfig YAML. Use this for clusters Mengi can’t discover via a cloud credential (e.g. Hetzner or on-premises).
Acknowledge the installation — read the notice describing what Mengi installs (see above) and tick I understand and want to proceed.
Check the cluster — click Check cluster to run the preflight. The import button stays disabled until the check reports the cluster is ready to import. If you change the input afterwards, run the check again.
Import — click Import Cluster. The cluster appears on your clusters page and moves through importing → running while Mengi validates connectivity, creates its management service account, connects secret management and installs the component bundle.

Once the cluster is running you can deploy to it like any other cluster — pick it in the New deployment wizard (see Deployments).

Discover Workloads (adopt what’s already running)

An imported cluster usually isn’t empty. Discover Workloads lets Mengi take over management of the apps already running on it — without redeploying or restarting them.

Scan the cluster

Open the imported cluster’s page and click Discover Workloads, then Scan Cluster. Mengi scans for Helm releases, Deployments, StatefulSets and DaemonSets, skipping its own platform components and anything you’ve already imported (those are marked Already imported).

For each workload you see its namespace, container image, port, CPU/memory and replica count — or, for a Helm release, the chart name, version and status. Expand a row to review the details and edit the advanced settings (extra pod/container configuration, or the release’s custom values) before importing.

Adopt workloads

Select the workloads you want and click Import Selected. Each one becomes a deployment in Mengi — adopted in place:

No second copy is deployed and nothing restarts. Mengi takes over the workload exactly as it runs, in its original namespace, with no traffic interruption.
From then on you manage it like any other deployment — update the image, change resources, scale replicas, view logs and events — all from the dashboard.
Helm releases are adopted via their running container image: the chart’s source repository isn’t stored on the cluster, so Mengi keeps the app running as-is and manages it as a container deployment going forward.

Un-adopting

Deleting an adopted deployment untracks it — the underlying cluster resources keep running, because Mengi only created the link, not the workload itself. To actually remove the resources, use the tool that originally installed them (e.g. helm uninstall or kubectl delete).

Removing an imported cluster

Delete the cluster from its page in the dashboard. You must first remove all its deployments (deleting an adopted deployment just untracks it, so the workload itself keeps running).

What Mengi cleans up:

its platform components are removed from the cluster, in an orderly shutdown before the connection is dropped — nothing is left behind;
the management service account and its credentials in mengi-system;
the cluster’s secret-management connection and its registration with Mengi, including the cluster’s record in your dashboard.

What stays: the cluster itself — nodes, control plane and all of your own workloads, including any you adopted and untracked. Mengi never owned the infrastructure, so removing the cluster from Mengi never deletes it.

Good to know

Your admin credentials are only used during setup. Once the import completes, Mengi connects through the dedicated service account it created — the admin kubeconfig you pasted is not used for day-to-day management.
The preflight is free to run as often as you like — it never changes anything on the cluster.
Warnings don’t block an import, only errors do. If you’re unsure about a reported conflict, contact support before importing.
Imported clusters count as dedicated clusters, so features that require one — such as custom domains — work on them.
Discover Workloads is only available on imported clusters, and only while the cluster is running.
Cluster names are lowercase and must be unique within your account.