Add-ons

Your hosted control plane has no plan. You set its shape (1 to 3 API servers, a state limit) and add add-ons on top.

This page is the practical companion to Pricing. For each add-on, it tells you what you get, how to use it and, where it applies, a command you can paste. The API reference describes every API route that this page names.

You choose add-ons in the dashboard: in the create wizard, and later under the cluster’s Settings → Shape. The Add-ons card on the cluster page shows only 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 after we review them.

Included, not add-ons

Two things that people expect as add-ons are not add-ons, because every hosted control plane has them:

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

Add-ons at a glance: every add-on below is €0 until 1 December 2026. The table shows the list prices that start after that date, excl. VAT. Consumers pay VAT on top: 22% in Slovenia, or the rate of their country. The Pricing page shows the prices incl. VAT.

€0 until 1 December 2026

Add-on	Price from 1 December 2026	Monthly cap	Needs
Cluster web dashboard (Headlamp)	€0.001/h	€0.73/mo	any shape
OPA / Gatekeeper	free	free	any shape
etcd backups	included	included	every control plane
Audit logging	€0.001/h	€0.73/mo	any shape
Monitoring	€0.010/h	€7.30/mo	any shape
Logging	€0.008/h	€5.84/mo	3 API servers
Dedicated nodes	€0.018/h	€13.14/mo	3 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. 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.

kubehz bills add-ons separately. If an add-on stays after you delete something else, kubehz bills it until you delete the add-on too. See Pricing.

One price is not in this list, because it is not an add-on. A static node (a worker node that you bring yourself) costs €0.001/h per node, at most €0.73/mo excl. VAT. kubehz bills it per hour that 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. kubehz runs it next to your control plane and publishes it at an instant public URL:

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).

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 excl. VAT, on every shape. You can untick it in the wizard and under Settings → Shape. The create wizard selects no add-on for you: you tick this one.

Headlamp replaced the deprecated upstream kubernetes-dashboard behind this add-on in July 2026: same option, same price, a better access path.

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

Fallback: kubectl proxy. If your cluster still runs the legacy in-cluster kubernetes-dashboard, you can still reach it through the API server’s service proxy. The proxy authenticates 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:

   kubectl --kubeconfig ./kubeconfig proxy

3. Open the service-proxy URL for the dashboard in your browser:

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

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

OPA / Gatekeeper

What it enables. OPA Gatekeeper policy enforcement in your cluster. Gatekeeper checks resources at admission against policies that you write as ConstraintTemplate + Constraint objects.

It is free and available on every shape. The operator maps this add-on to KKP’s opaIntegration.enabled. The Gatekeeper components run inside your cluster.

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

Show the full ConstraintTemplate + Constraint 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:

kubectl apply -f required-labels.yaml

What enforcement looks like. After that, the admission webhook rejects a namespace without an owner label:

$ 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 Gatekeeper admits it:

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).

Every hosted control plane includes it, on by default. 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 * * *). kubehz keeps the most recent 20 snapshots and prunes older ones automatically. It writes the snapshots 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: use the Backups section on the cluster page, or the API.

In the API, POST /api/clusters/{id}/snapshots with a name takes a snapshot, GET lists them, DELETE .../snapshots/{name} drops one, and the restore action on a snapshot restores it.

A restore is a KKP EtcdRestore against your control plane. The API server is unavailable for the minutes the restore takes, and every object that changed since the snapshot is gone. If you want a second pair of eyes, ask in chat before you press the button.

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).

It costs €0.001/h, at most €0.73/mo excl. VAT, on any shape. The operator maps this add-on to KKP’s auditLogging with a fixed policy preset.

Which preset applies. kubehz enables the recommended audit policy preset. This balanced level captures the security-relevant operations without the volume of a full request/response firehose. You cannot change the preset: there is no per-cluster policy editor.

Where events go. The API server on your control plane emits the audit events. 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 that you own (endpoint, bucket, prefix, access key).
• none keeps them on the control plane only.

To browse and search the events, pair this add-on with Logging. Logging gives you a place to read them at scale.

Monitoring

What it enables. Per-cluster metrics: kubehz collects them from your cluster and sends them to the kubehz platform. It costs €0.010/h, at most €7.30/mo excl. VAT, on any shape.

You turn it on in the kubehz dashboard: in the wizard’s add-on options when you create the cluster, or later under the cluster’s Settings → Shape. 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, a monitoring agent runs on your own workers: 2 replicas that request 220m CPU and 532 MiB memory together (see Worker capacity). The fee pays for our backend and storage, not for your compute.

What kubehz collects. Cluster and node health, and the resource use of the control plane and the workloads (the standard Kubernetes/cAdvisor/kube-state signals). You get CPU, memory, pod and node metrics over time without a Prometheus of your own.

Where to see it. The metrics show in the Monitoring section on the cluster page in the kubehz dashboard.

Alerting. The same section 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 the toggle on the same page, or with POST /api/clusters/{id}/alerts/subscription.

Logging

What it enables. Per-cluster log aggregation, based on Loki, through the same platform stack. It costs €0.008/h, at most €5.84/mo excl. VAT, and it needs the three-API-server shape.

Like monitoring, you turn it on in the kubehz dashboard: in the wizard’s add-on options when you create the cluster, or later under the cluster’s Settings → Shape. A promtail-style collector runs in your cluster and sends 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: it requests 60m CPU and 74 MiB memory on every worker node. The fee pays for our backend and storage.

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

Where to see it. Logs show in the kubehz dashboard next to monitoring. The rollout of the in-dashboard log browser is in progress. Today the add-on gives you the collection and the 7-day retention.

Logging is also the natural companion to Audit logging: it gives you a place to read the 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. The control plane gets steadier, isolated performance.

It costs €0.018/h, at most €13.14/mo excl. VAT, and it needs the three-API-server shape. The operator moves your control plane onto metal-class nodes (a placement change, not a resize).

Live migration on toggle. Dedicated is reversible. When you turn it on (or off), the operator starts a live migration of the control plane onto (or off) the metal pool. The operator moves the workload: you do not rebuild the cluster.

Capacity gating (the honest bit). Bare metal is a scarce pool, and we limit it on purpose. Because of that, dedicated is capacity-gated at provisioning time. If the metal pool is at its floor, you may not be able to order the option for a while, even on a cluster with three API servers.

This is intentional: we add metal when demand justifies it. The option needs the three-API-server shape, so that throwaway clusters do not churn the scarce capacity. If the option is unavailable when you try, it opens again when we add capacity.

Worker capacity

Some add-ons run pods on your hosted workers, and those pods request CPU and memory. Before kubehz turns such an add-on on, it checks that the worker pools can hold the system pods plus every add-on you chose. The check counts these requests:

On your workers	CPU	Memory	Counted
System pods on every node	175m	114 MiB	per worker node
System pods for the cluster	320m	484 MiB	once per cluster
Monitoring (2 agent replicas)	220m	532 MiB	once per cluster
Logging (collector)	60m	74 MiB	per worker node
OPA / Gatekeeper	200m	1024 MiB	once per cluster
cert-manager (app catalog)	60m	160 MiB	once per cluster

The cluster web dashboard, audit logging, etcd backups and dedicated nodes run next to the control plane. They need nothing on your workers.

The rule. The pools must give at least 1.5 times the sum of these requests, for CPU and for memory. The 50% headroom covers use above the requests, the extra pod during a rolling update, and the error in the estimate.

kubehz estimates what one node gives from its server type: vCPU × 1000m minus 400m of CPU, and 93% of its memory minus 500 MiB. An autoscaled pool counts with its minimum node count.

Example. One worker with 2 vCPU and 4 GB (cpx22 or cax11) gives 1600m CPU and 3309 MiB. The system pods plus monitoring need (175 + 320 + 220) × 1.5 = 1073m CPU and (114 + 484 + 532) × 1.5 = 1695 MiB. One such worker is enough.

When kubehz checks. When you create a cluster with workers and add-ons, add an add-on, install a catalog app, or give a cluster without workers its first workers. On a cluster that already has workers, this check never refuses a pool change (scale down, new type, removal).

kubehz does not judge static pools (it does not know their size). It also lets the change through when the Hetzner catalog is not available.

When it does not fit. kubehz refuses the change with ADDON_NEEDS_CAPACITY. The help text states what the add-ons and the system pods need, what the pools give, and an example pool that is enough (for example 2 × cax11).

Choose a larger server type, add workers, or remove an add-on. Every hosted worker also needs at least 2 vCPU: see Server types.

Next steps

• Pricing: the full add-on price list.
• Hosted control plane: the shape and the hosted path overall.
• Worker Pools: pools, scaling and autoscaling on your cluster.
• Dashboard & account: where you toggle add-ons and download the kubeconfig.

---

Doc status

Aspect	Detail
State	Add-ons live, with self-service snapshots, restore, audit delivery and alerting. In-dashboard log browser: rollout in progress
Last reviewed	30 October 2026