Connect your own cluster

Your environments can run on a cluster of your own: a fresh Linux machine, which the installer turns into a k3s cluster, or a Kubernetes cluster you already have. You still drive them from the platform. Your cluster connects to it, always from the cluster to the platform and over HTTPS: nothing has to be opened towards it.

What you need

For a bare server: a recent Linux machine (2 CPU and 4 GB of memory or more), root access, and outbound HTTPS to the internet. The installer puts k3s on it, then the platform's agent: the machine becomes the first node of your cluster, and others can join it later. Keep it for your environments: k3s takes ports 80 and 443 to serve them, and a website the machine already serves would stop receiving its visitors. The installer checks before changing anything, and stops naming what it found — a program on those ports, a Docker container, or another Kubernetes. A machine that already runs Kubernetes connects with the Existing Kubernetes cluster tab.

For an existing cluster: a cluster your kubectl reaches, with a storage class and an ingress controller. The installer touches only what it lays down, and takes over what is already there (below).

Either way, the team.settings permission: it is what creates a cluster and shows its install command, from the team's Clusters page, Connect a cluster button. The page is read with team.view.

The choices to make before installing

The page asks these questions before it gives you the command, and the command follows your answers. Three of them do not change without reinstalling:

• The HTTPS certificates. With Let's Encrypt (recommended), the installer lays down cert-manager unless it is already there, and an issuer: it needs an email address, and *.your-domain pointing at the cluster. On a cluster that already has its cert-manager issuer, name it: it is never changed. Without HTTPS, the environments answer over HTTP only.
• The environments' database. By default, a PostgreSQL 18 server installed with the agent. Or your own PostgreSQL, version 15 or newer (18 to receive copies of the platform's environments), reachable from the cluster, with a dedicated administrator: LOGIN CREATEROLE CREATEDB, never a superuser, with pg_signal_backend. Its password is asked at the terminal: it never appears in the command.
• The network of nodes added later (bare server). Machines in one place, on a private network: nothing to do. Machines in other places, reaching each other over the internet: choose WireGuard now — an encrypted network, which needs a public IP address.

Two others can be added later by running the installer again:

• The team's database servers: CloudNativePG, to create and tune PostgreSQL servers from the cluster's page, and their backups to the team's storage (the Barman Cloud plugin). Recommended.
• High availability (bare server): an etcd datastore from the start, so that other nodes of the control plane can join the machine. Without it, the page sets it up when a first control-plane node is added.

On a bare server, the page also asks where the environments' data goes: the machine's disk, or Longhorn for volumes replicated across the nodes. An environment keeps the storage it was created with.

What is already on your cluster

No need to know beforehand what is installed there: the installer looks before installing, and its summary says it before Continue? [y/N]. What is already there is taken over as it is, never reinstalled nor upgraded — it may serve other applications of yours: k3s, Longhorn, cert-manager and its issuers, CloudNativePG and its backup plugin, your storage and ingress classes.

• cert-manager is recognised where it runs, whatever its namespace. When only its definitions are left, with no cert-manager running, the installer stops before changing anything. With Let's Encrypt, it adds its own issuer, rollbackk-letsencrypt, and lists yours: to use one of them, choose A cert-manager issuer already there on the page.
• CloudNativePG is taken over only if it can run the team's database servers: its operator runs, at version 1.27.1 or newer, and watches their namespace, rollbackk-odoo-db. Otherwise it stays as it is, and the cluster's page says why the database servers are off, and what to change.
• The Barman Cloud backup plugin must run next to CloudNativePG's operator, in the same namespace. Elsewhere, backups stay off and the page says so: it never offers a backup that would not start.
• A cluster already connected to the platform: its own command reinstalls it, environments included. The command of another cluster is refused there — when a colleague connected it already, for instance — and is not used up: reinstall from the page of the cluster already connected, or remove it from the platform first.

Running the command

The command downloads the installer, checks its SHA-256, then runs it. Each step runs only if the one before succeeded:

rm -f rollbackk-install.sh &&
curl -fsSL https://…/install.sh -o rollbackk-install.sh &&
echo "<checksum>  rollbackk-install.sh" | sha256sum -c - &&
sudo sh rollbackk-install.sh --join <token> --letsencrypt-email [email protected]

Paste it whole: on the machine for a bare server, where your kubectl reaches the cluster otherwise. If a step fails — a download refused, a checksum that does not match ("FAILED") — nothing runs. Never run a rollbackk-install.sh left from an earlier time: it is not the one the platform has just published.

The token inside is single-use and lasts a few minutes; the page shows it once. New command makes another one, and the previous one stops working.

The installer first checks the machine or the cluster, then sums up what it is about to do — storage, ingress, database, certificates — and asks Continue? [y/N]. Read that summary: it is the last moment to change your mind, and nothing is installed yet. It also asks for the storage or ingress class when the cluster has several. Once connected, the cluster shows on the page, which says what is left to do, such as pointing your domain.

Every option of the installer

sh rollbackk-install.sh --help lists them. Here they are, with when to use them.

If the cluster does not connect

• The download fails (curl: (22)) or the checksum does not match ("FAILED"): nothing was run. Run it again; if it persists, ask for a new command.
• The command expired, or it was already used: New command, on the page.
• The cluster reaches the internet only through a proxy: --https-proxy.
• The summary is not the one you expected, for instance "certificates: none: HTTP only": answer N. Nothing is installed; run it again with the right options.
• "ports 80 and 443 are not free on this machine": a website or a container answers there already. Stop it or move it, or give the environments another machine. Nothing was changed.
• "this machine already runs Kubernetes": connect that Kubernetes with the Existing Kubernetes cluster tab, from a machine where its kubectl works.
• "already connected to the platform as the cluster …": this machine is a cluster of the platform already. The command was not used; the message says what to do.
• "cert-manager's resource definitions are on this cluster, but cert-manager does not run": start or reinstall cert-manager, then run the command again.
• The installer stops on a refusal — a storage class that gives no volume, an issuer not found: it says why, and what it changed. Usually, nothing.

Reinstalling, or removing the cluster

Running the installer again with a new command reinstalls the agent: the environments and their data stay, and what was in place — classes, database — is taken over. It is also how HTTPS or the team's database servers are added afterwards.

To remove the cluster, its page gives the uninstall command: keep the environments, or delete everything. Removing the cluster from the platform does not touch its machines.