Run the installer

Have everything on Install Thinkube ready: the installer, a prepared machine, and your accounts and tokens.

A separate machine you install from does not become a node. After the install, the tokens are on the control plane, and you no longer need the machine you installed from.

The first screen names the three phases: a system requirements check, cluster configuration, and automated deployment. Press Get Started.

The installer checks the machine it is running on. Required: Ubuntu 24.04.x LTS, a non-root user with sudo, OpenSSH server, network connectivity, and free disk space in your home directory. Tools it can install if missing: Git, the OpenSSH client, a Python virtual environment, and Ansible inside that environment.

Every required item must pass before you can continue.

Enter the sudo password of your user. The installer uses it to configure SSH to the server, install missing tools, set up its environment, and configure system services. The password is not written to disk.

The same password must work on every server you select next; the SSH screen checks it.

Enter the network to scan as a CIDR, for example 192.168.1.0/24, and press Start Network Scan. Each discovered server is listed with its IP address, hostname, operating system and whether SSH is reachable. A machine that is not Ubuntu is marked Failed. Press Select on each server to install on, and Deselect to take one out again, then Setup SSH Connectivity. One of them becomes the control plane and the others workers; you choose which on the Role Assignment screen. You can also add machines later from Thinkube Control — Add more nodes.

The installer verifies that it can reach every selected server, then configures passwordless SSH between them: it generates keys where needed and distributes them. If a server cannot be reached, check that SSH is running there and that the sudo password is the same as on the machine you install from.

For each server the installer reads CPU cores, memory, disk and GPUs, and sums them in a capacity summary. It also reads the NVIDIA driver on each server with a GPU. The driver must be version 580.0 or newer. An older driver is reported as outdated and the installer offers to install a compatible one. A GPU older than the Volta generation is reported as unsupported. If no server has a usable GPU you can continue without a GPU, or stop.

Choose one control plane. It must be a physical machine, not a virtual one, with at least 16 CPU cores and 64 GB of memory. A smaller machine cannot be chosen. Every other server becomes a worker. With a single server, the control plane also runs your workloads. GPU nodes serve and train models.

With a DGX Spark, install on another machine and add the Spark later as a worker, so its memory stays free for AI work. On a DGX Spark, the GPU and the system share one pool of memory. The control plane runs more than Kubernetes. It also runs Thinkube Registry, Thinkube Identity, the database, Thinkube Git and the image builds. As a worker, the Spark keeps its memory for models, notebooks and fine-tuning.

Enter the cluster name, your domain, and the tokens:

The screen also asks for your name and email. They are the author of the commits you make on the platform.

Press Verify next to a token to check it now: the installer calls the service and shows a green mark when the token works and has the access it needs. When you continue, the installer verifies every token you have not verified yet.

Tailscale is the only overlay network supported. Enter the Tailscale auth key, which each node consumes once when it joins the tailnet, and the API access token, which the installer uses to talk to your tailnet’s admin API. Press Verify. When you continue, the installer adds the tag:k8s-operator definition to your tailnet’s policy file; the next screen needs it.

The cluster runs the Tailscale Kubernetes operator, which needs an OAuth client. The operator uses it to add the cluster’s gateway to your tailnet. Tailscale does not let the installer create that client, so this is the one step done in Tailscale’s own console. The screen lists it: open Settings → Trust Credentials, add an OAuth credential with the Devices → Core and Keys → Auth Keys scopes, read and write, tagged tag:k8s-operator, and paste the client ID and secret. Press Verify.

The same screen asks for the gateway hostname the operator will claim on your tailnet. Leave it blank to use <cluster name>-gw. It becomes reachable as <name>.<your tailnet>.ts.net.

The installer installs Tailscale on every selected server and joins each one to your tailnet, then shows the overlay address of each node. Tailscale assigns the addresses; nothing is entered here.

This screen shows the network overview for you to check: the overlay range Tailscale uses, the container build architectures detected from the servers, and each server with its addresses and role.

The last look before anything is installed: cluster name and domain, the admin username, the overlay provider, and the node with its hardware, addresses and role. Press Start Deployment.

The installer runs the platform’s playbooks in order and streams their output. The phases, in the order they run:

Most of the time goes to downloading container images and building the ones this cluster’s architectures need. If no new output appears for some minutes, it is pulling or building an image. A failed phase stops the deployment; the output names the task that failed.

If a step fails, the Deployment screen names it and offers Retry, which runs that step again. Copy Failed Log and Download All Logs keep the output for a support request. Closing the installer loses the progress; the next run starts from the first screen.

The final screen shows:

The installer adds these to each node:

The installer leaves Ubuntu, its packages, the kernel, netplan, your account and its sudo rights, sshd, and the NVIDIA driver as they are.