The control plane is free. The rest is one rate card.

Because of the architecture. Your control plane runs as pods against an isolated datastore, so its marginal cost to us is small enough not to charge an idle-cluster fee for it. You pay for worker resources, storage, load balancers, registry storage and the cluster’s mandatory public API endpoint.

Yes. Every cluster currently requires a separately billed public API endpoint: a dedicated public IPv4 for its Kubernetes API, €4 per month, flat, no proration, locked the first time the billing sampler observes the address. It is mandatory on every supported configuration. The worked examples and the calculator totals on this page include the endpoint; package fees are listed without it, so the packages table shows both the fee and the fee with the mandatory endpoint. Private-network connectivity, which would make the public endpoint optional, is a future capability. One implementation gap is worth naming: the REST API still accepts public_endpoint: false on cluster creation. Such a cluster gets no public address and is not charged the €4, but it also has no supported access path — it is an implementation gap, not a cheaper way to buy a cluster.

The control plane itself, single sign-on, the container registry service with image scanning, DNS and TLS automation, control-plane datastore backups, the cluster autoscaler and the observability stack. Those services are free; the resources they consume are not hidden — registry storage bills at €0.15 per started GiB per month, volumes and load balancers at their rate-card rows.

A fixed pool bills a flat monthly fee for the full calendar month, and there is no proration. A fixed pool’s or package’s monthly amount is locked when its grace period expires, for the month in which the grace period expires; in every later month it is locked the first time the pool — or, for a package, the cluster — is seen in that month. Deleting the pool later in a month does not refund the locked amount. Fixed pools bill per pool rather than per node, so the 15-minute grace period works through the pool — the pool’s monthly fee is not charged if the pool is removed within 15 minutes of its first node appearing in the cluster’s node list. The control plane is €0 in every mode.

An autoscaling pool bills per node: after its grace period a node bills per started node-hour, at its per-node monthly price divided by 730, with each started hour rounded up, counted from the moment the node first appears in the cluster’s node list. A pool is autoscaling when its vCPU or memory budget has room to grow — the budget, not a node count, is what decides it.

Every node has a 15-minute grace period, measured from the moment it first appears in the cluster’s node list, whether or not it becomes Ready. Remove it within that window and it carries no node charge. It applies to every node in a fixed or an autoscaling pool — the pool’s first nodes, nodes added later, and replacement nodes alike. A node counts as removed when its removal is requested — you delete it, scale the pool down, or delete the pool or cluster — and the time it then spends draining does not count against the grace period and is never billed. Because a fixed pool bills per pool, the waiver is keyed on the pool: its monthly fee is not charged if the pool is removed within 15 minutes of its first node appearing in the cluster’s node list — pool created 12:00, first node appears 12:08, removal requested 12:20 is 12 minutes, so no charge. Aether records every node and pool as soon as it appears, but a payable charge is locked only when the grace period passes: for a fixed pool or a package, its month; for an autoscaling node, its first started hour. The grace period covers the node only, and it does not apply to the public API endpoint, load balancers, persistent volumes or registry storage. A public API endpoint and a load balancer each lock a flat month the first time the billing sampler observes the address. Persistent volumes and registry storage are charged per hourly observation: once every clock hour the billing sampler observes what exists and charges that hour at the monthly rate ÷ 730, so something created and deleted between two observations costs nothing. Where an account creates and destroys nodes in a pattern that exploits the grace period, Aether may defer a removal past the window and charge for the node; that is an exception applied to abuse, not the ordinary course, and it is distinct from a drain, which delays when a node disappears but never when its billing stops.

Billing for a node ends when its removal is requested, before the drain. Scale a pool down 12 minutes after its node first appeared in the cluster’s node list and let the node drain for another 9: its lifetime for billing is 12 minutes, inside the grace period, so it carries no charge. Deleting a fixed pool or a package cluster after its grace period does not refund the locked month, and deleting a cluster does not refund the €4 endpoint month or any load-balancer month already locked. Hourly nodes stop accruing when the deletion is requested. Storage stops at the next hourly observation after the volumes are gone. Registry storage is per organization and is unaffected by cluster deletion. Deleting a cluster destroys its workloads, volumes and data; Aether keeps no copy.

You can change the node count; you cannot change the node size. Decreasing a fixed pool’s node count mid-month does not reduce the locked amount, and the next month locks at the new size. On a custom cluster, increasing it is reflected in the next month’s amount — the current billing engine adds no further charge within the month the change is made — and the locked month never decreases. On a package cluster the increase can cost you in the same month: if growth takes the cluster’s fixed pools past the allowance for the first time that month, counting only nodes whose grace period has expired, the overage line is created and charged then; an overage line that already exists is not repriced until the next month. If we detect repeated creation and removal intended to exploit the grace period, we may defer removal until the node is at least 16 minutes old; the grace-period exemption then no longer applies and the applicable package overage charges become payable — an enforcement delay separate from ordinary node draining, which does not extend billable lifetime. Changing a fixed pool’s per-node vCPU, memory or disk after creation is not supported today: create a new pool with the new shape and drain the old one. Deleting a pool and creating another — even with the same name, in the same month — creates a new pool with its own grace period and its own monthly charge, and the old pool’s locked month stays payable. On month boundaries: a fixed pool’s or package’s month becomes payable only when its grace period expires, and it is charged for the month in which the grace period expires; after that it is charged for every calendar month in which it exists. Example: a first node that appears at 23:55 UTC on 30 September has a grace period that ends at 00:10 UTC on 1 October — September is not charged, and October becomes payable if the pool is still there when the grace period ends.

In GiB, once every clock hour. Persistent volumes and registry storage are measured in GiB (1 GiB = 1024³ bytes, the unit Kubernetes and the registry report); node disk is the size you type per node in GB and is part of the node price, not a persistent volume. Once every clock hour (UTC) the billing sampler observes what exists and charges that hour at the monthly rate ÷ 730 — so a volume or an image created and deleted between two observations costs nothing. There is no monthly maximum or average: the month’s charge is the sum of its hourly observations, so a volume that exists for the whole of a 31-day month costs 744/730 of the monthly rate, and one that exists for a day costs about a thirtieth of it. A block volume is charged for the provisioned capacity, regardless of how much data is stored, rounded up per volume; a shared volume is charged for actual usage observed at billing measurement time, because capacity is not hard-quota limited — summed and rounded up once per cluster; registry storage is what the registry reports for your organization, rounded up to a whole GiB. The full worked examples are in the billing model documentation.

Yes — Dev €29, Starter €79, Growth €179, Scale €279 per cluster per month, each with a whole-cluster allowance of vCPUs, memory and node disk. A cluster is billed either from a package or custom, chosen when it is created and fixed for its lifetime. The package price is a flat monthly fee on the same terms as a fixed pool. An overage line is created when the cluster’s fixed pools exceed the allowance, counting only nodes whose grace period has expired, and anything above the allowance in any dimension is priced at the custom rates. If we detect repeated creation and removal intended to exploit the grace period, we may defer removal until the node is at least 16 minutes old; the grace-period exemption then no longer applies and the applicable package overage charges become payable — an enforcement delay separate from ordinary node draining, which does not extend billable lifetime. Packages do not include the mandatory €4 public API endpoint, load balancers, persistent volumes or registry storage — the packages table on this page shows each package fee both alone and with the endpoint.

No. There is no per-GB egress meter, no bandwidth charge and no charge for API calls — the rate card and, on a package cluster, the package fee plus any overage are the whole bill.

No. Aether publishes no uptime commitment and no service credits today, and there is no status page. Product support runs through the Support section of the portal after you sign in; legal and privacy questions go to legal@aetherplatform.cloud.

Monthly invoices in EUR, with VAT handled on the invoice — every price on this page is VAT excluded. Month-to-date spend and a daily-spend chart are live in the portal.