Skip to content
Compartment Docs
Website Star

System Operations

Compartment provides the same platform lifecycle commands for managed-VM and existing-Kubernetes installations:

Terminal window
compartment system status
compartment system restart

system status reports the Helm release and platform workload readiness. system restart rolls the platform workloads and waits for readiness; it does not restart Kubernetes nodes.

Update the platform

Section titled “Update the platform”

Install the current verified stable CLI before updating:

Terminal window
curl -fsSL https://compartment.dev/install.sh | sh

Before updating an operator-owned cluster, use Kubernetes 1.35 or newer, or enable ImageVolume=true on the API server, every eligible kubelet, and every autoscaler or machine-template bootstrap path. The update fails before Helm if the API prunes the image volume or if any current Ready schedulable node cannot mount it. Compartment does not upgrade operator-owned clusters.

The organization quota release supports clean installations only. It does not retrofit quota state onto organizations from an older installation; install it on a new database instead of using system update for that cutover.

For an existing Kubernetes cluster, pass the same operator values file used for the installation:

Terminal window
compartment system update \
  --kube-context production \
  --values compartment-values.yaml

The command verifies the target images, updates the Helm release, runs database migrations, and waits for platform readiness. Your cluster, ingress controller, storage system, and node lifecycle remain operator-owned.

During an update, Compartment keeps the running application proxy serving until its replacement can accept hosted application traffic. Hosted applications stay reachable and do not receive 502 responses while the update proceeds.

An update re-reads the defaults of the chart shipped with the CLI you run, so a release picks up defaults that changed since it was installed. The system domain commands rewrite the same release and behave the same way. Values you set stay yours: anything from your --values file, or set on an earlier install or update, is reapplied on top of those defaults and still wins. To keep a value at a number Compartment later changes, keep it in your --values file rather than relying on the previous default. Removing a key from that file does not restore the chart default, because the value recorded on the release is still replayed; set it explicitly to the value you want instead. Inspect the values a release ended up with using helm get values <release> --namespace <namespace> --all.

On a Compartment-managed VM, run:

Terminal window
sudo compartment system update

That path verifies the Compartment-owned k3s and gVisor runtime, creates a local etcd snapshot, and updates the platform through resumable stages. It fails closed when the recorded installer-owned release metadata differs and then requires reprovisioning a clean VM; it does not automatically delete generated K3s host files. See Operate a Managed VM for diagnostics, recovery, backup limits, and reprovisioning.

Manage the install domain

Section titled “Manage the install domain”

Inspect or change the install-level domain with:

Terminal window
compartment system domain status
compartment system domain set --base-domain apps.example.com --values compartment-values.yaml
compartment system domain verify
compartment system domain activate --values compartment-values.yaml

Use Install Domain to choose the DNS and TLS ownership model. App-specific aliases use the separate compartment domain commands.

Next steps: