Day-two operations: maintenance, upgrades, transfer

This page covers ongoing life of a workspace after it is active: patching, Kubernetes upgrades, moving between projects, and choosing server types where applicable.

Maintenance windows

What maintenance controls

Each workspace carries a maintenance configuration with:

Master switch — maintenance enabled or disabled.
Weekly schedule — for each weekday (0–6), an hour in UTC when automated work may run.
Priority hour — a dedicated UTC hour for higher-priority updates such as security patches flagged by the platform.

Compute maintenance
Toggle automatic operating-system updates on hosts attached to the workspace’s compute story.

Kubernetes maintenance (only for kubernetes workspaces)
Toggle automatic Kubernetes patch upgrades during maintenance.

Important permission behavior

Disabling maintenance entirely (enabled: false) is typically administrator-only. If a non-admin attempts to turn it off, the product may force maintenance back to enabled while still allowing schedule changes.

Why: operators want a baseline security posture; “no maintenance ever” is an escalation event.

PATCH semantics quirk to be aware of

When you update maintenance via the product’s PATCH-style interaction, omitting the nested compute or kubernetes blocks may turn off the corresponding automatic update flags (implementation sets them to false if absent). Always send the full object your UI expects, or confirm behavior with your client library.

Kubernetes version upgrades

Viewing current and target versions

For active Kubernetes workspaces you can:

Read the currently running Kubernetes version record (semantic version, supported upgrade metadata).
List eligible upgrade targets — versions that are active in the catalog and allowed by the version’s upgrade.from compatibility list for your current version.

User meaning: you will not see every future Kubernetes release — only operator-approved and graph-compatible hops.

Triggering an upgrade

Starting an upgrade enqueues a dedicated upgrade task (asynchronous). The HTTP interaction typically returns “accepted” (HTTP 202) rather than waiting for completion.

What happens under the hood (simplified)

Control plane changes go through Kamaji (API server version moves with the tenant control plane object).
Worker nodes are reconciled through host automation (package installs, kubeadm upgrades) coordinated by the task stack.

Operational cautions

Upgrades are disruptive to scheduling and API availability windows depending on strategy; plan maintenance communication.
Rollback of Kamaji tenant control planes may be limited once certain upgrade steps succeed — treat upgrades as forward-only unless your operator documents snapshot/restore.

When upgrades are blocked

The product refuses upgrades when:

The workspace is not a Kubernetes workspace.
The workspace is not in an active operational state (or is in special transient states such as reconciled gating — consult error messages).
The requested version is unknown or not active in the catalog.

Transferring a workspace to another project

You can move a workspace from one project to another within the same organization when you have transfer permission.

Why do this

Re-homing a environment after restructuring teams.
Promoting a workspace from a sandbox project to a production project (if your governance allows).

What to verify afterward

RBAC on the destination project — teammates may lose access if they only had rights on the old project.
Automation that encoded the old project id in scripts or CI variables.
Billing attribution if your org maps cost centers per project.

Compute profiles (machine types)

For workspaces backed by a compute provider (for example Hetzner Cloud), the product can list compute profiles: predefined server types with pricing information.

Availability filtering
For Hetzner-backed providers, the platform may mark profiles unavailable if the underlying cloud API reports that server type is not present in any datacenter reachable with your token.

Pricing overrides
If your organization has active billing agreements with pricing overrides, those can adjust displayed setup, hourly, or other price components for matching profiles.

User workflow

Open compute profiles for the workspace.
Pick an allowed profile when creating or resizing hosts (exact UX depends on client).
Confirm the price line matches your agreement.

Reconciliation and “drift”

Loopback runs reconciliation loops (scheduled jobs) for active workspaces:

They refresh status fields you see in the UI.
They help ensure seeding and cluster health converge after changes.

If the UI shows warnings or reconciling states for a long time, involve your operator — it may indicate cloud API errors, credential expiry, or a stuck task queue.

Deletion

Deletion flows are destructive: they tear down DNS, integrations, and infrastructure according to operator policy.

Before you delete

Back up manifests, persistent data, and secrets.
Export kubeconfigs only if you still need emergency access during wind-down (then revoke).

(Exact deletion sequencing is operator-dependent once the API accepts the delete.)