Skip to content

Add-ons

Your hosted control plane has no plan: you set its shape (1 to 3 API servers, a state limit) and layer add-ons on top. This page is the practical companion to Pricing: what each add-on actually gives you, how to consume it, and, where it applies, a command you can paste.

You choose add-ons in the dashboard: in the create wizard, and later under the cluster’s Settings → Plan (the Add-ons card on the cluster page only shows what is installed). The kubehz operator translates your choice into the matching Kubermatic (KKP) settings on your control plane; you never edit KKP directly.

Apps are not add-ons

Add-ons are control-plane options. Software that runs in your cluster comes from the app catalog on the cluster’s Applications tab: pick an app and a version, optionally pass Helm values, and the operator installs it (GET /api/catalog/apps, PUT /api/clusters/{id}/apps/{name}). Today the catalog holds cert-manager; more apps follow as they are reviewed.

What’s included vs. what’s an add-on

Two things people expect as add-ons are not, because they are built in:

  • etcd backups: scheduled snapshots are included in every hosted control plane, default-on. See etcd backups below for what that means.
  • High availability: HA is the API-server count you set (3 API servers), not a separate line item. Set three and you have it.

Add-ons at a glance: every add-on below is €0 until 1 November 2026. These are the list prices that start after that date (see Pricing):

€0 until 1 November 2026

Add-onPrice from 1 November 2026Monthly capNeeds
Cluster web dashboard (Headlamp)€0.001/h€0.73/moany shape
OPA / Gatekeeperfreefreeany shape
etcd backupsincludedincludedevery control plane
Audit logging€0.001/h€0.73/moany shape
Monitoring€0.010/h€7.30/moany shape
Logging€0.008/h€5.84/mo3 API servers
Dedicated nodes€0.018/h€13.14/mo3 API servers

How the meter works. kubehz bills every started hour in full. Billing starts when you create the resource. kubehz bills the resource while it exists, in any state, and only deletion stops the charge. The hourly charges of one unit never go above its monthly price: the €/mo figure is the hourly rate multiplied by 730 hours, and it is a maximum, also in a 31-day month. Add-ons are billed separately. An add-on that stays after you delete something else is billed until you delete the add-on too. See Pricing.

One price sits outside this list because it is not an add-on: a static node, a worker node you bring yourself, costs €0.001/h per node, at most €0.73/mo, billed per hour the node is Ready. A NotReady node is the one exception to the rules above: kubehz never bills it. See Static nodes.

Cluster web dashboard (Headlamp)

What it enables. A hosted Headlamp web dashboard for your cluster, run by kubehz next to your control plane and published at an instant public URL:

text
https://dash-<cluster-id>.kubehz.cloud

Open it from the cluster’s detail page in the kubehz dashboard (the Open dashboard button). You sign in with your kubehz account (the same SSO login as the platform), and what you can see and do follows your Kubernetes RBAC: Headlamp forwards your own identity token to the API server and holds no admin credentials of its own. No kubeconfig, no proxy, no second password.

It costs €0.001/h, at most €0.73/mo, on every shape, and you can untick it anywhere. The create wizard selects no add-on for you; you tick this one. Headlamp replaced the deprecated upstream kubernetes-dashboard behind this add-on (2026-07): same option, same price, a strictly better access path.

Prefer a local app? Headlamp desktop opens the same cluster from your downloaded kubeconfig, with no add-on required. It is also the dashboard story for self-hosted clusters.

Fallback: kubectl proxy. A cluster still running the legacy in-cluster kubernetes-dashboard can keep reaching it through the API server’s service proxy, authenticated with your own kubeconfig:

  1. Download the cluster’s kubeconfig from the kubehz dashboard (the cluster detail page).

  2. Start a local proxy to the API server:

    bash
    kubectl --kubeconfig ./kubeconfig proxy
  3. Open the service-proxy URL for the dashboard in your browser:

    text
    http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

The proxy inherits your kubeconfig, so the dashboard sees precisely what you would see with kubectl, and nothing more.

OPA / Gatekeeper

What it enables. OPA Gatekeeper policy enforcement in your cluster: admission-time validation of resources against policies you author as ConstraintTemplate + Constraint objects. It is free and available on every shape. The operator maps this to KKP’s opaIntegration.enabled; the Gatekeeper components run inside your cluster.

How to consume it. Once the add-on is on, apply a ConstraintTemplate (defines a reusable rule) and then a Constraint (applies it to specific kinds). The classic starter is “every namespace must carry an owner label”:

Show the full ConstraintTemplate + Constraint YAML
yaml
# 1. The template: a reusable "required labels" rule.
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }
---
# 2. The constraint: require an `owner` label on every Namespace.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["owner"]

Save both documents as required-labels.yaml, then apply them:

bash
kubectl apply -f required-labels.yaml

What enforcement looks like. After that, a namespace without an owner label is rejected at admission:

console
$ kubectl create namespace demo
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied
the request: [ns-must-have-owner] you must provide labels: {"owner"}

Create the namespace with the label instead, and it is admitted:

bash
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    owner: platform-team  # any value — the policy only requires the key
EOF

etcd backups

What it enables. Scheduled snapshots of your control plane’s etcd, the datastore behind every object in your cluster (Deployments, Secrets, CRDs, the lot). This is included in every hosted control plane, default-on; there is nothing to buy or turn on. The operator provisions a KKP EtcdBackupConfig for your cluster.

Schedule and retention. Backups run every 6 hours (cron 0 */6 * * *) and the most recent 20 snapshots are kept; older ones are pruned automatically. Snapshots are written to kubehz-managed object storage in the EU. You do not manage a bucket.

One-shot snapshots and restore. Next to the schedule you can take a snapshot yourself, before a risky change, and restore from any snapshot you hold. Both are self-service: the cluster page’s Backups section, or the API (POST /api/clusters/{id}/snapshots with a name, GET to list them, DELETE .../snapshots/{name} to drop one, and the restore action on a snapshot). A restore is a KKP EtcdRestore against your control plane: the API server is unavailable for the minutes it takes, and every object changed since the snapshot is gone. If you would rather have a second pair of eyes, ask in chat before you press it.

Audit logging

What it enables. Kubernetes API audit logging on your control plane: a record of who did what against the API server (requests, subjects, verbs, resources). €0.001/h, at most €0.73/mo, on any shape. The operator maps this to KKP’s auditLogging with a fixed policy preset.

What preset is applied. kubehz enables the recommended audit policy preset, a balanced level that captures the security-relevant operations without the volume of a full request/response firehose. (The preset is fixed; there is no per-cluster policy editor.)

Where events go. Audit events are emitted by the API server on your control plane. Choose a delivery for them on the cluster page (or with PUT /api/clusters/{id}/audit-delivery): webhook posts each batch to an HTTPS endpoint of yours (with an optional CA bundle), s3 writes them to an S3-compatible bucket you own (endpoint, bucket, prefix, access key), none keeps them on the control plane only. To browse and search them, pair the add-on with Logging, which gives you a place to read them at scale.

Monitoring

What it enables. Per-cluster metrics collected from your cluster and shipped to the kubehz platform. €0.010/h, at most €7.30/mo, on any shape. You toggle it in the kubehz dashboard: at create time in the wizard’s add-on options, or later under the cluster’s Settings → Plan. A Prometheus runs in your cluster and feeds the platform; you do not run or scale it.

What the fee covers. The platform side: multi-tenant metrics storage with 15-day retention, the dashboard query path, and alerting. kubehz runs and operates all of it. On your side only a light collector runs on your own workers; the fee pays for our backend and storage, not your compute.

What’s collected. Cluster and node health, control-plane and workload resource usage (the standard Kubernetes/cAdvisor/kube-state signals), so you get CPU, memory, pod and node metrics over time without running your own Prometheus.

Where to see it. Metrics surface in the kubehz dashboard’s Monitoring section on the cluster page.

Alerting. The section also holds your alert rules and receivers. A rule group is a Prometheus rule file for metrics or logs (PUT /api/clusters/{id}/monitoring/rules/{name} with the YAML in data); a receiver is a webhook URL or an email address (PUT .../monitoring/receivers/{name}). Subscribe your own account to the cluster’s alert mails with POST /api/clusters/{id}/alerts/subscription, or the toggle on the same page.

Logging

What it enables. Per-cluster log aggregation, Loki-backed, via the same platform stack. €0.008/h, at most €5.84/mo; it needs the three-API-server shape. Like monitoring, you toggle it in the kubehz dashboard: in the wizard’s add-on options at create time, or later under the cluster’s Settings → Plan. A promtail-style collector runs in your cluster and ships pod logs to the platform’s Loki; you do not run Loki yourself.

What the fee covers. The platform-side ingest, the 7-day log storage, and the query path behind the dashboard’s log browser. kubehz runs and operates all of it. The collector on your nodes is yours and marginal; the fee pays for our backend and storage.

Retention. The add-on includes 7-day log retention: the last week of logs is queryable, and older data ages out.

Where to see it. Logs surface in the kubehz dashboard alongside monitoring. The in-dashboard log browser is rolling out; the collection and 7-day retention are what the add-on provisions today, and this is also the natural companion to Audit logging for reading audit events.

Dedicated nodes

What it enables. Places your control plane on dedicated bare-metal capacity in the kubehz fleet instead of shared cloud VMs: steadier, isolated performance for the control plane. €0.018/h, at most €13.14/mo; it needs the three-API-server shape. The operator steers your control plane onto metal-class nodes (a placement change, not a resize).

Live migration on toggle. Dedicated is reversible: turning it on (or off) triggers a live migration of the control plane onto (or off) the metal pool: the operator moves the workload; you don’t rebuild the cluster.

Capacity gating (the honest bit). Bare metal is a scarce, deliberately limited pool. Because of that, dedicated is capacity-gated at provisioning time: if the metal pool is at its floor, the option can be temporarily unavailable to order even on a pro cluster. This is intentional (metal is added as demand justifies it) and pro-only so throwaway clusters don’t churn the scarce capacity. If it’s unavailable when you try, it will open as capacity is added.

Next steps


Doc status

AspectDetail
StateAdd-ons live; snapshots, restore, audit delivery and alerting self-service; in-dashboard log browser rolling out
Last reviewed5 September 2026