Operate a Managed VM

Use these commands only on a VM provisioned by compartment install --target vm. Existing Kubernetes clusters keep their operator-managed lifecycle.

During initial provisioning, Compartment automatically installs cert-manager, creates the internal registry CA and Issuer, adds the CA to the managed node trust store, and installs gVisor/runsc. These are managed host components; do not pre-create an issuer, patch node trust, or install the runtime before installation.

Check status

sudo compartment system status

Status combines the host provisioner stage, k3s service and version, Kubernetes readiness, and the Compartment Helm release. After a reboot, wait for this command to report k3s and the platform as ready before deploying.

Create diagnostics

sudo compartment system diagnose

The command creates a local compressed support bundle with provisioner state, service status, node readiness, and platform workload status. Credentials, bearer tokens, kubeconfig key data, and Secret values are excluded or redacted. Review the archive before sharing it.

Update

curl -fsSL https://compartment.dev/install.sh | sh
sudo compartment system update

First install the current verified stable CLI. The update command verifies the installer-owned host content, creates an etcd snapshot, invokes the canonical platform update, and verifies the resulting host and cluster versions plus a real gVisor canary. It does not adopt or rewrite an older installer-owned release: when the recorded release metadata differs, the command fails closed and requires reprovisioning a clean VM. Compartment does not automatically delete generated K3s files because it cannot prove their exact ownership. Managed Kubernetes components do not update in the background. If an update stops, correct the reported problem and rerun the same command.

The platform update re-reads the defaults of the chart bundled with the CLI you just installed, so a release picks up defaults that changed since it was installed. Values recorded for your installation, including anything in /etc/compartment/values.yaml, are reapplied on top of those defaults and still win.

If the update refuses to run because installer-owned host content changed, the error lists every drifted path and what changed about it (content, file mode, or owner) against what the installer recorded in /var/lib/compartment/installer/state.json. Restore those paths to their installer-written state and rerun, or capture a bundle with sudo compartment system diagnose and reprovision a clean VM. Replacing an installer-owned binary such as /usr/local/bin/helm with a different build is enough to trip this check.

Scheduled local etcd snapshots protect against some operator errors. They are stored on the same VM and are not a machine-loss backup. Copy verified backups and application data off-host according to your recovery requirements.

Recover an interrupted installation

Rerun the original install command with sudo only when the failure occurred after the installer-owned host stages completed. The installer revalidates every recorded file before resuming cluster-only work. If a host mutation stage was interrupted, it fails closed instead of adopting partial files; preserve diagnostics and reprovision a clean VM.

Destroy the provisioned cluster

There is no supported in-place destructive reset. Back up required data, preserve diagnostics, and delete or reprovision the VM through your infrastructure provider. Compartment refuses automatic cleanup because K3s creates mutable host files that cannot be matched to exact installer-written content. A normal Helm uninstall does not destroy the host cluster.