Standard
Control plane free of charge — you only pay for the worker nodes.
€0.00$0.00/ month per cluster
- SLA
- 99.9%
- Max. workers
- 100
- Managed control plane
- Automatic upgrades
- CSI and CCM drivers
- Cluster Autoscaler
- Ingress with Load Balancer
We operate the control plane — the part of the cluster that decides what runs where. You are only charged for the worker nodes, i.e. the machines on which your containers actually run.The control plane costs nothing, and with it the ingress load balancer at the entrance of the cluster, the drivers and the autoscaler, which adds a node when space is tight. The Kubernetes API remains unchanged: what runs here also runs on any other compliant cluster.
3 minor versions are maintained simultaneously. The current one is 1.36, available since 04/2026 and maintained until 08/2027.
Managed Kubernetes shifts work, it does not make it disappear. Before any prices, these two columns state which part of operations lies on which side.
At no extra charge in every tier, without a ticket, without a maintenance contract.
Everything that depends on your application — and therefore nobody can decide for you.

We maintain 3 minor versions simultaneously. The current 1.36 receives security patches until 08/2027, the oldest still supported 1.34 until 12/2026. After that, we upgrade the control plane in an announced window — details can be found under Versions.
The control plane runs on our hardware, is updated, backed up and monitored by us — and appears on the invoice in the Standard tier at €0.00$0.00. This is not an introductory offer, but the model.
A Kubernetes cluster consists of two parts. The control plane — API server, scheduler, controller manager and etcd — decides what runs where. The workers execute. Only the second part consumes your resources, and only it is billed.
Worker nodes are normal cloud instances from the same catalogue as everything else. The same hourly rate, the same cap on the monthly price, the same locations. A node that the autoscaler removes again after two hours costs two hours.
The included traffic is attached to the node, not the cluster: each worker brings its own volume, and the sum is available to the entire cluster. A pool of three ND3 nodes thus contributes 90 TB of outbound traffic per month, regardless of which node it flows through.
What incurs additional costs: persistent volumes via Block Storage, the storage of the private registry, outbound traffic above the included volume of the nodes and — if booked — the surcharge for the High Availability or Enterprise tiers.
Included in the price
Control plane, tier Standard
Managed control plane · Automatic upgrades
Load Balancer Layer 4
TCP and UDP with Proxy Protocol v2. Supports the ingress controller of the cluster. Additional and higher tiers are billed, the included amount is credited.
Public connection per node
1 × IPv4 + /64 IPv6
Private Registry base fee
Only used storage is billed
Maintenance window: Default window
Tuesday to Thursday between 02:00 and 06:00 CET. The date is announced 72 hours in advance, the nodes are replaced sequentially.
etcd backup from tier Highly available
In Highly available and Enterprise, tier “Snapshots (7 days)” is included.
The scope of services for each tier also includes: CSI and CCM drivers · Cluster Autoscaler.
Based on consumption

Three dedicated workers, one 100 GB persistent volume each, one public ingress. Enough for an application with a database, cache and background processing — with capacity for the failure of one node.
| Item | Quantity | Unit price | Total |
|---|---|---|---|
| Control plane, standard tierSLA 99.9%, automatic upgrades | 1 | €0.00$0.00 | €0.00$0.00 |
| Ingress with Load BalancerPublic IPv4 and IPv6, Proxy Protocol v2 | 1 | €0.00$0.00 | €0.00$0.00 |
| Worker node ND34 vCPU dedicated, 16 GB RAM, 160 GB NVMe | 3 | €77.60$90.02 | €232.80$270.05 |
| Block Storage NVMePersistent volumes, 100 GB per worker | 300 GB | €0.0860$0.0998 / GB | €25.80$29.93 |
| Outbound traffic30 TB per worker included | 90 TB | €0.00$0.00 | €0.00$0.00 |
| Net total per month | €258.60$299.98 |
The result
A flavor is the size of a node: vCPU, memory and local NVMe in a fixed combination. We do not recommend sizes with shared cores for production clusters. Kubernetes' own processes run permanently on every node — they consume their share of the quota faster than the application does.
Monthly price is also the cap for hourly billing
| Configuration | vCPU | RAM | Local NVMe | Price / month |
|---|---|---|---|---|
| ND2AMD EPYC (dedicated) | 2 | 8 GB | 80 GB | €38.80$45.01 |
| ND3AMD EPYC (dedicated) | 4 | 16 GB | 160 GB | €77.60$90.02 |
| ND4AMD EPYC (dedicated) | 8 | 32 GB | 240 GB | €138.99$161.23 |
| ND5AMD EPYC (dedicated) | 16 | 64 GB | 360 GB | €276.49$320.73 |
| NM4AMD EPYC (dedicated) | 8 | 64 GB | 320 GB | €193.30$224.23 |
| NA4Ampere Altra (shared) | 8 | 16 GB | 160 GB | €21.49$24.93 |
| NA5Ampere Altra (shared) | 16 | 32 GB | 320 GB | €41.49$48.13 |
| NG-L4AMD EPYC (dedicated) | 8 | 48 GB | 400 GB | €540.00$626.40 |
NG-L4 belongs in a separate pool with the taint nvidia.com/gpu. A taint is a restriction mark on the node: only workloads that really need a graphics card and explicitly tolerate the mark end up there.
Any instance size from the catalogue is permitted as a worker, including the 10 GPU configurations. They run in their own node group at the same hourly rate as the instance and with the same cap on the monthly price. The device plugin for NVIDIA is rolled out when the group is created.
A GPU group may scale down to zero. Nodes that the autoscaler shuts down cost nothing from the moment they are shut down — with hourly billing, you are only charged for what has run.
Calculation example · 2 × NG-RTX4000
1 × NVIDIA RTX PRO 4000 Blackwell SFF, 24 GB GDDR7 per node · location Frankfurt am Main, net
Cluster with inference pool per month
€686.60$796.46
Standard tier control plane at no extra charge. If the pool runs for less than 730 hours, the hourly rate per hour run applies.
All three tiers deliver the same Kubernetes version, the same drivers and the same workers. What differs is the resilience of the control plane, the upper limit for nodes and the scope of evidence.
Control plane free of charge — you only pay for the worker nodes.
€0.00$0.00/ month per cluster
Control plane distributed across three fire zones.
€65.70$76.21/ month per cluster
For regulated environments requiring evidence.
€177.84$206.29/ month per cluster
| Feature | Standard€0.00$0.00 / month | Highly available€65.70$76.21 / month | Enterprise€177.84$206.29 / month |
|---|---|---|---|
| Availability commitmentmeasured by the availability of the API server | 99.9% | 99.99% | 99.99% with service credit |
| Worker nodes per cluster | 100 | 500 | 2,000 |
| Control plane | one fire zone, managed | three fire zones, active/active | dedicated, without other tenants |
| etcd backup | daily, in a second region | every 15 minutes | every 15 minutes, with WORM lock (immutable until expiry) |
| API endpoint | public, with IP allowlist | additionally private in the vRack (your private network) | additionally private in the vRack |
| Private registrysee Private Registry section | one registry per project | multiple registries, mirror included | multiple registries, mandatory signature possible |
| Audit log | 7 days in the console | Export to Object Storage or Loki | Export, audit-proof |
| Hardening | Upstream defaults | Upstream defaults | CIS benchmark (hardening catalogue), documented |
| Certificates | ISO 27001 | ISO 27001 | ISO 27001 and BSI C5 |
| Escalation | Ticket, 4 hours | Ticket, 1 hour | 24/7 phone number, named contact |
Four components connect Kubernetes to our infrastructure. They are installed, versioned and updated with the cluster — without you having to maintain a Helm chart.
The storage driver csi.block.entronyx.cloud provisions volumes on Block Storage NVMe, csi.file.entronyx.cloud mounts NFS shares. Four StorageClasses (storage profiles) are pre-installed, nvme-delete is the default.
The CCM connects Kubernetes to our API: it sets the provider ID on each node, removes deleted instances from the cluster and creates a public address for each service of type LoadBalancer.
You set a lower and upper limit per node pool. If a pod cannot be placed due to missing capacity, the autoscaler creates a new node. Instance provisioning: on average 35 seconds, guaranteed under 60 seconds. Pools may scale down to zero.
Cilium, the cluster's network plugin, runs in eBPF mode and replaces kube-proxy. ingress-nginx and Gateway API v1 are available as an add-on, cert-manager fetches certificates via DNS-01 against our Anycast DNS.
A managed, private container registry per project: OCI-compliant (the open standard for container images), in the same location as the cluster, with vulnerability scanning on upload and retention rules that prevent storage from filling up unnoticed.
Every new layer is checked against the vulnerability database after the push, before the image can be delivered. The finding is attached to the digest — the checksum of the image — and not the tag: a newly set tag inherits it, a new build does not.
Without a rule, a registry grows monotonically: every build stores a version, none disappear. The rules work per repository and can be viewed in a dry run before execution.
The cluster logs in with a robot account that only has read access. The access token is stored as an imagePullSecret — the access secret for retrieving images — in the namespace and is inherited by all pods via the service account.
A rollout across many nodes requests the same image many times simultaneously — exactly the case where public registries throttle anonymous requests. The mirror fetches the image once and then delivers it from our network.
The registry has no base fee. It stores layers and manifests in object storage and is billed at its rates — €0.0070$0.0081 per GB and month by default. 250 GB of used storage therefore costs €1.75$2.03 net per month. The actual usage after removing duplicate layers is counted, not the sum of the image sizes.
| Storage class | Basis | per GB / month | Minimum quantity | Example quantity | Example / month |
|---|---|---|---|---|---|
| Registry StandardDefault setting. Hosts application images, base images and Helm charts. | Object Storage Standard | €0.0070$0.0081 | 1 GB | 250 GB | €1.75$2.03 |
| Registry PerformancePure NVMe backend for large images and rollouts across many nodes simultaneously. | Object Storage Performance | €0.0180$0.0209 | 1 GB | 250 GB | €4.50$5.22 |
| Registry ArchiveTarget for retention rules: expired versions that must be kept for evidence purposes. | Cold Archive | €0.0024$0.0028 | 1000 GB | 1 TB | €2.46$2.85 |
Registry, robot account, scan rule, retention and mirror are five commands. In the cluster, it remains standard Kubernetes: a secret of type dockerconfigjson, bound to the service account of the namespace.
# Create registry — storage class and region as with Object Storage
entronyx registry create prod \
--region fra1 --class standard --quota 250
# Robot account with read access only, for the nodes of the cluster
entronyx registry robot create ci-pull \
--registry prod --scope "repo:*:pull" --ttl 90d
# Check rule: images with critical vulnerability are not delivered
entronyx registry policy set prod \
--scan-on-push --block-severity critical --block-unscanned
# Retention: the last 10 versions per repository remain,
# untagged manifests are dropped after 7 days
entronyx registry retention set prod \
--keep-latest 10 --keep-tagged "v*,release-*" \
--purge-untagged-after 7d --archive-after 180d
# Mirror for a public registry — pulls run via us afterwards
entronyx registry mirror add prod \
--upstream docker.io --cache-ttl 24h
# Store robot account credentials as imagePullSecret in the cluster
entronyx registry robot token ci-pull --registry prod --format docker \
| kubectl create secret generic entronyx-registry \
--namespace produktion --type kubernetes.io/dockerconfigjson \
--from-file=.dockerconfigjson=/dev/stdin
apiVersion: v1
kind: Secret
metadata:
name: entronyx-registry
namespace: production
type: kubernetes.io/dockerconfigjson
stringData:
# Generated with: entronyx registry robot token ci-pull --format docker
.dockerconfigjson: |
{ "auths": { "prod.registry.entronyx.cloud": { "auth": "<base64>" } } }
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
namespace: production
# The service account pulls the secret for all pods in the namespace,
# so that it does not have to be repeated in every deployment
imagePullSecrets:
- name: entronyx-registry
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: production
spec:
template:
spec:
containers:
- name: web
image: prod.registry.entronyx.cloud/team/web:1.8.2
# The mirror replaces the public registry: the same line,
# different origin, no rate limiting in the rollout
- name: cache
image: prod.registry.entronyx.cloud/mirror/library/valkey:8

The ENTRONYX CLOUD registry has no base fee: you are billed for the storage used after deducting duplicate layers. A pull from your own cluster does not leave our network and therefore costs nothing.
Private registry · billing by usage
Rancher is operated as a managed service: you log in, connect clusters and assign permissions. Updates, backups and availability of the Rancher instance are our responsibility.
Rancher shows the state, utilisation and events of all connected clusters side by side. The cluster view is a view of the same API server that kubectl addresses — no second state that could diverge.
An external cluster is imported: Rancher outputs a manifest that starts an agent in the target cluster and establishes the connection from the inside out. The external API server does not need to be publicly accessible for this.
Rancher does not maintain its own user management. Whoever logs in comes from the same directory service as in the console. The roles come from the rights federation: one group, one assignment, effective in all assigned clusters.
Helm charts — the package format for Kubernetes applications — from a shared catalogue can be rolled out to a selection of clusters simultaneously — filtered by label, for example to all clusters with the label stage=production.
Select region, connect directory service. The instance gets its own name under our domain and a certificate that is renewed automatically.
Clusters from your ENTRONYX projects are connected via the API. Nothing changes in the cluster that you would need to revert.
For clusters with other providers or in your own data centre, Rancher generates a manifest. When applied, it starts the agent that establishes the connection from the inside.
Groups are assigned roles — for the instance, for individual clusters, or for projects within a cluster. There is no second user list that needs to be maintained.
Roll out catalogue applications, compare states, track events. For daily work, kubectl remains usable without changes — Rancher complements it, it does not replace it.
# Create Rancher instance; login runs via the same
# Directory service like the console
entronyx rancher create zentral --region fra1 --sso oidc
# Take over an ENTRONYX cluster — no agent needed, the connection
# is created via the API
entronyx rancher attach zentral --cluster prod-fra
# Import an external cluster: Rancher outputs a manifest,
# which starts an agent in the target cluster
entronyx rancher import zentral --name kunde-onprem > agent.yaml
kubectl --kubeconfig ~/.kube/onprem apply -f agent.yaml
# Rights come from the rights federation, not from a second user list
entronyx iam binding create \
--group "team-plattform" --role rancher.clusterOwner --scope zentral
entronyx iam binding create \
--group "team-anwendung" --role rancher.projectMember --scope zentral/produktion
Rancher is an additional component in your chain. With a single cluster and a team that already works with kubectl, it brings more interface than benefit. From the third cluster onwards, or at the latest with separate teams or locations, the calculation changes.
| Feature | One cluster, one team | Multiple clusters, teams, or locations |
|---|---|---|
| Access | one kubeconfig, maintained locally | one login process for all clusters |
| Permissions | RoleBindings directly in the cluster | Roles once in the identity federation, effective everywhere |
| Overview | kubectl and custom dashboards are sufficient | State of all clusters side by side |
| Third-party clusters | separate toolchain per provider | imported, in the same interface |
| Rollout | Helm against one cluster | Selection via labels, in stages |
| Effort | none — there is nothing extra to learn | one more interface your team needs to know |
| Our recommendation | you are better off without Rancher | Managed Rancher, from three clusters |
We maintain three minor versions in parallel. A new version is available no later than six weeks after the upstream release, and the oldest continues to run for at least twelve months.
The window per version spans around sixteen months — from the day of availability to the end of support in the table. Within this window, the version receives security updates and bug fixes, but not afterwards. If a version expires without you having upgraded, we will upgrade the control plane to the next minor version during an announced maintenance window.
| Version | available since | support until | Status |
|---|---|---|---|
| 1.36 | 04/2026 | 08/2027 | Standard |
| 1.35 | 12/2025 | 04/2027 | maintained |
| 1.34 | 08/2025 | 12/2026 | maintained |
Check for deprecated API groups, missing PodDisruptionBudgets (the minimum number of running pods per application) and add-ons whose version does not match the target version. The result is a list, not a guess.
The control plane is upgraded first. In the Highly Available tier, the API server remains accessible throughout the entire process because the three instances switch one after the other.
Each pool is renewed with Surge 1: a new node is added, an old one is cordoned, drained and removed. PodDisruptionBudgets are respected; if necessary, the process waits.
There can be a maximum of three minor versions between the API server and the kubelet — the service that starts the containers on each node. As long as this gap is maintained, node pools can deliberately stay behind — for example, a pool with particularly sensitive workloads.
A downgrade of the control plane is not possible because etcd migrates its schema. The way back is via a new cluster in the old version and applying your manifests.
A removed API group does not delete any objects. What is in the cluster stays there and continues to run — only the next apply, the next Helm upgrade or the next GitOps sync will fail, often months after the upgrade. The preflight run therefore searches the entire object inventory and not just your manifests in the repository. If it finds a usage, the upgrade is aborted instead of postponing the error into the future.
| API group | Affected objects | removed in | Replacement |
|---|---|---|---|
| networking.k8s.io/v1beta1 | Ingress, IngressClass | 1.22 | networking.k8s.io/v1 |
| batch/v1beta1 | CronJob | 1.25 | batch/v1 |
| policy/v1beta1 | PodDisruptionBudget | 1.25 | policy/v1 |
| autoscaling/v2beta2 | HorizontalPodAutoscaler | 1.26 | autoscaling/v2 |
| flowcontrol.apiserver.k8s.io/v1beta3 | FlowSchema, PriorityLevelConfiguration | 1.32 | flowcontrol.apiserver.k8s.io/v1 |
The change is usually one line in the manifest: swap group and version, field and object names remain the same. We announce exceptions in the release notes when the respective version is released.
The values are hard limits of the control plane, not recommendations. If you want to push them to the limit, you should talk to us beforehand about the distribution of the node pools — 2,000 nodes in a single pool behave differently than 2,000 nodes in forty pools.
| Feature | Standard | Highly available | Enterprise |
|---|---|---|---|
| Worker nodes per cluster | 100 | 500 | 2,000 |
| Node pools per cluster | 8 | 32 | 64 |
| Clusters per project | 5 | 25 | unlimited |
| Pods per node | 110 | 110 | 110 |
| Services of type LoadBalancer | 5 | 20 | 100 |
| etcd database size | 8 GB | 8 GB | 8 GB |
| Persistent volumes per nodeLimit of the block storage connection | 16 | 16 | 16 |
Clusters, node pools, registries and autoscaling limits are resources in the Terraform provider. Anything you can click in the console, you can also version.
# Create cluster — the Control Plane is not charged
entronyx kube cluster create prod-fra \
--version 1.36 --tier ha --region fra1 --private-endpoint
# Node pool with autoscaling between 3 and 12 workers
entronyx kube nodepool create workers \
--cluster prod-fra --flavor nd3 --min 3 --max 12 --autoscale
# Mount credentials into the existing kubeconfig
entronyx kube kubeconfig prod-fra --merge
kubectl get nodes -o wide
kubectl get storageclass
# NAME PROVISIONER DEFAULT
# nvme-delete csi.block.entronyx.cloud true
# nvme-retain csi.block.entronyx.cloud false
# capacity-delete csi.block.entronyx.cloud false
# shared-nfs csi.file.entronyx.cloud false
resource "entronyx_kube_cluster" "prod" {
name = "prod-fra"
region = "fra1"
version = "1.36"
tier = "ha" # 99.99%, Control Plane across 3 fire zones
private_endpoint = true
vrack = entronyx_vrack.prod.id
etcd_backup {
interval = "15m"
region = "hel1" # Backup is located outside the cluster location
}
}
resource "entronyx_kube_nodepool" "workers" {
cluster = entronyx_kube_cluster.prod.id
name = "workers"
flavor = "nd3"
autoscale = true
min_nodes = 3
max_nodes = 12
labels = { workload = "general" }
}
resource "entronyx_kube_nodepool" "inference" {
cluster = entronyx_kube_cluster.prod.id
name = "inference"
flavor = "ng-l4"
autoscale = true
min_nodes = 0 # scales down to zero
max_nodes = 4
taints {
key = "nvidia.com/gpu"
value = "true"
effect = "NoSchedule"
}
}
apiVersion: v1
kind: Service
metadata:
name: web
annotations:
service.beta.entronyx.cloud/proxy-protocol: "true"
service.beta.entronyx.cloud/health-check-path: "/healthz"
service.beta.entronyx.cloud/algorithm: "least-connections"
spec:
type: LoadBalancer # the cloud controller creates the public IP
selector:
app: web
ports:
- port: 443
targetPort: 8443
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data
spec:
storageClassName: nvme-retain # Volume survives the deletion of the claim
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 100Gi
The control plane is ready in under five minutes. You configure node groups, registry and Rancher connection in the same run — with the same prices, the same locations and the same per-second billing, capped at the monthly price.