Terms of Service
The agreement between you and us for the use of Aether Platform. Read section 4 and section 5 carefully — they set out what you are charged and what happens if a payment fails.
Last updated: 9 September 2026
01 Who we are, and what this is
Aether Platform is operated by EAGLE VERSE SRL, registered at Baia Mare, Maramureș, Romania, trade register no. 2010000840245, CUI 27852110 ("we", "us"). "You" means the person or company that registers an account.
The service is managed Kubernetes: we provision and operate Kubernetes clusters for you — control planes, worker node pools, networking and storage — together with a container registry for your organization and the tooling around them (web portal, HTTP API, API tokens). You run your own workloads on those clusters. We operate the platform; what you deploy on it is yours.
These terms apply from the moment you create an account.
02 Accounts and organizations
- Give us accurate account and billing details, and keep them current. Invoices are issued to what you tell us.
- Your account belongs to an organization. Roles within it (owner, admin, member, viewer) control what each person can do. Whoever holds an administrative role can add and remove members, provision infrastructure and incur charges on the organization's behalf.
- You are responsible for your credentials — passwords, passkeys, API tokens and registry robot accounts. Anything done with them counts as done by you. Tell us promptly if you believe a credential has been compromised, and revoke it from the portal.
- You are responsible for the workloads you run, the data you put on your clusters and the images you push to your registry, including having the right to use them.
- You must be able to enter a contract, and you must not be barred from receiving our services under applicable sanctions law.
Cluster credentials
The kubeconfig you download for a cluster carries an administrator certificate for that cluster, valid for one year from the cluster's creation. It is a standalone credential: it keeps working wherever it has been saved, it does not stop working when someone leaves your organization, and removing a member from the portal does not revoke a kubeconfig they already downloaded. There is no self-service rotation or revocation today; if a kubeconfig may have been exposed, the available responses are to delete and recreate the cluster, or to open a support ticket. We recommend handing out credentials you mint inside the cluster and scope with Kubernetes RBAC rather than sharing the administrator kubeconfig.
03 Acceptable use
Use the platform lawfully. Specifically, do not use it to:
- infringe anyone's intellectual property or other rights;
- attack, scan, overload or attempt to gain unauthorised access to third parties, other tenants, or our own infrastructure;
- send unsolicited bulk email or operate an open mail relay;
- host or distribute malware, or run anything designed to conceal its origin for abusive purposes;
- circumvent the platform's isolation, quotas, billing or authentication mechanisms.
Where a workload endangers the platform, another tenant, or a third party — or where we are legally required to act — we may suspend or isolate that workload. We aim to tell you first and to act no more broadly than the problem requires, but where the risk is immediate we may act first and inform you straight after.
04 Billing
Prices are in euro (EUR), as published in the rate card on aetherplatform.cloud/pricing, and exclude VAT; the VAT treatment that applies to you is shown on the invoice. A billing month is a calendar month, measured in UTC. There are exactly two ways a resource is charged — a flat monthly fee, or a per-hour fee — and which one applies depends on the resource:
A cluster is billed either from a package or per resource. You choose when you create the cluster, and the choice is fixed for that cluster's lifetime. The rows below set out how each resource is charged; the first row sets out what a package covers and what it does not.
Every node has a 15-minute grace period. It is measured from the moment the node first appears in the cluster's node list, and it applies to every node in either kind of pool — the pool's first nodes, nodes added later and replacement nodes alike — whether or not the node ever became Ready. A node removed inside that window carries no node charge. A node counts as removed when its removal is requested: you delete it, scale the pool down, or delete the pool or the cluster. The time it then spends draining does not count against the grace period and is never billed. Once the window has passed, the node is charged as its pool's row below sets out — for a fixed pool that is the whole calendar month, not the minutes it ran.
We record every node and pool from the moment it exists — that record is what the portal's usage views and your invoice are computed from. A payable charge is locked only once the grace period has passed: for a fixed pool or a package, the calendar month in which the grace period expires; for an autoscaling node, its first started hour.
| Resource | How it is charged |
|---|---|
| Package clusters | A cluster can be created from a package instead of being priced per resource. The package is a flat monthly fee at the published rate, on the same monthly terms as a fixed pool: full calendar month, no proration, locked as the fixed node pools row below sets out — with the cluster in the pool's place, since a package fee belongs to the cluster and not to any one pool — and not refunded if you delete the cluster. The grace period applies through the cluster — the fee is not charged if the cluster is removed within 15 minutes of its first node appearing in the cluster's node list. A package includes an allowance of vCPUs, memory and node disk for the whole cluster: the cluster's fixed pools consume it first, counting only nodes whose grace period has expired, and anything above the allowance in any dimension is charged as an overage at the per-resource rates, each dimension on its own — unused memory does not offset extra vCPUs, and unused allowance is not credited. The overage amount is locked at the first observation in which fixed pools past their grace period exceed the allowance; it is not repriced later in that month. A node removed inside its grace period therefore never creates an overage. Where we detect repeated creation and removal intended to exploit that, we may defer a removal until the node is at least 16 minutes old; the grace-period exemption then no longer applies and the applicable package overage becomes payable. That enforcement delay is separate from ordinary draining, which never extends a node's billable lifetime. An autoscaling node that fits entirely inside the allowance left after the fixed pools accrues no hourly charge; one that does not fit is charged per node-hour like any other autoscaling node. A package does not include the cluster's dedicated public address, load balancers, persistent volumes or registry storage — those are charged as their rows below set out. Package names, prices and allowances are published on the pricing page. |
| Fixed node pools | A flat monthly fee at the published rate for the pool's configured size. Its nodes carry no separate charge, so the node grace period applies through the pool: the fee is not charged if the pool is removed within 15 minutes of its first node appearing in the cluster's node list. 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. Neither does removing nodes from it. How changes to a pool and month boundaries affect that amount is set out below the table. |
| Control plane | €0 (free). We operate your cluster's Kubernetes control plane at no charge. You pay for the worker nodes, the addresses and the storage your cluster uses. |
| Autoscaling node pools | Per node-hour at the published rate, for every node the pool runs — including the nodes it holds at its minimum. Each started hour is rounded up to a full hour. A node accrues nothing once it is removed. |
| Dedicated public IPv4 | A flat monthly fee at the published rate, for a cluster's dedicated public API address. Same monthly terms: full month, no proration, and the month is locked the first time the billing sampler observes the address — the sampler runs every few minutes, so that is not the same as the moment the address is created. The node grace period does not apply to it. Every cluster has one: the address is part of what a cluster is, not an add-on you decline. The HTTP API still accepts a cluster created without a public endpoint; that is an implementation gap rather than a supported configuration, and such a cluster has no supported way in. Private-network connectivity, which would make the public endpoint optional, is a future capability. |
| Load balancers | A flat monthly fee at the published rate, per load balancer, on the same monthly terms: the month is locked the first time the billing sampler observes the address, and the node grace period does not apply to it. The public address is included — a load balancer's IP is not charged again as a dedicated address. |
| Storage and registry | Persistent volumes (block and shared) are charged at the published monthly rates, per GiB. The storage your container registry uses is charged at the published monthly rate per started GiB. Both are measured hourly: once every clock hour the billing sampler observes what exists and charges that hour at the monthly rate divided by 730, so a month's charge is the sum of its hourly observations rather than a single monthly reading, and a volume or image created and deleted between two observations costs nothing. Block storage is charged for the provisioned capacity, regardless of how much data is stored; shared storage is charged for actual usage observed at billing measurement time, because capacity is not hard-quota limited. We charge nothing for network traffic — there are no egress fees. |
A pool is an autoscaling pool when you give it a budget range rather than a fixed size. If you are unsure which applies, the pool's billing mode is shown in the portal.
The grace period exists so that a node created by mistake, or one that never came up, costs nothing. It is not a free allowance to be taken repeatedly: where an account creates and destroys nodes in a pattern that exploits it, we may defer a removal past the window and charge for the node — deferring it until the node is at least 16 minutes old, after which the grace-period exemption no longer applies and the charges it covered, including any package overage, become payable. That is an exception we apply to abuse, not the ordinary course, and it is not the same thing as a drain: a drain delays when a node disappears, never when its billing stops, whereas this deferral deliberately holds the node past the grace window — which is precisely what makes the charge payable.
The grace period covers the node only. It does not cover a cluster's dedicated public address, its load balancers, its persistent volumes or its registry storage. The address and load-balancer months are locked the first time the billing sampler observes the address, which is a few minutes after it is assigned rather than the moment it exists. Persistent volumes and registry storage are charged per hourly observation, so one created and deleted between two observations costs nothing.
Changing a fixed pool, and month boundaries
- Decreasing a fixed pool's node count part-way through a month does not reduce that month's locked amount. The next month locks at the new size.
- Increasing a fixed pool's node count is reflected in the next month's amount; no additional charge is added within the month in which you make the change. On a package cluster that holds only while the cluster stays inside its allowance: growth that takes the cluster's fixed pools past the allowance for the first time in a month creates an overage line charged in that month, and an overage line that already exists is not repriced until the next month. Only nodes whose grace period has expired count towards the allowance, so nodes removed inside their grace period never push a cluster over it.
- Changing a pool's per-node vCPU, memory or disk after creation is not supported today; to change node size, create a new pool with the new shape and drain the old one. Replacement nodes carry no separate charge in a fixed pool.
- Deleting a fixed 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. The deleted pool's locked month stays payable.
- A fixed pool's or a 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. So a pool whose grace period expired before a UTC month boundary and that is still there after it is charged for both months, while a pool removed within its grace period is charged in neither. 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. An autoscaling node-hour is charged in the month in which that hour starts.
The stored payment method
Clusters are billed to the payment method stored under Billing. When you save a card, your bank authenticates you at that moment, and you authorise the following two things — they are the reason the card is stored at all:
- Monthly billing is charged against the stored payment method. We charge it for your monthly invoices when you are not present.
- Any balance owed when your account closes is collected from it. If you close your account or organization with an outstanding balance, we issue a final invoice and collect it from the stored payment method.
You can replace or remove a payment method in the portal; removing the last one is only possible when you have no active clusters. Card details are held by our payment processor — see the Privacy Policy.
Invoices are issued in your organization's name and are available in the portal.
05 If a payment fails
When a charge against your stored payment method fails on a live account, this is what happens. Each step is announced by email and in the portal before it takes effect, naming the invoice, the amount and the dates below.
| Day | What happens |
|---|---|
| Day 0 | We notify you of the failed charge and give you a way to update your payment method. Nothing is touched. |
| Day 7 | If the invoice is still unpaid, the worker node pools of your clusters are scaled to zero. Control planes keep running and your cluster configuration and data are retained, so paying restores your pools to the size they were. |
| Day 30 | If the invoice is still unpaid, your clusters may be deleted and the account blocked from provisioning. Deletion is not reversible and the debt remains payable. |
Paying the invoice at any point ends this sequence. A second failed charge while it is running does not restart the clock — the dates are fixed from the first failure. We may also refuse a new registration that is linked to an unpaid balance from a previous account, and we may pursue the debt by ordinary means.
06 Cancellation and deletion
You may delete a node pool, a cluster or your whole organization at any time, from the portal or the API. There is no minimum term and no cancellation fee — but note that flat monthly charges under section 4 are not prorated, so deleting something mid-month does not refund that month.
Billing for a node ends when its removal is requested, before it drains. Counting from the moment the node appeared in the cluster's node list: if you scale a pool down at minute 12 and the node then drains until minute 21, 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 a dedicated public address or load-balancer month that is already locked. Nodes charged per node-hour stop accruing when the deletion is requested. Persistent volumes stop at the next hourly observation that no longer sees them. Registry storage is charged per organization and is unaffected by deleting a cluster.
Closing your organization settles the balance. Before your data is erased we issue a final invoice for what is outstanding and collect it from your stored payment method. If it cannot be collected, a small balance is written off and the erasure completes; a larger one remains a debt we may pursue, and we retain the minimum needed to do so — described in the Privacy Policy. Erasure is not withheld indefinitely: it completes within one month of your request either way.
Invoices we have already issued are retained for the period accounting and tax law requires, even after your account is erased. Everything else is deleted.
Deleting a cluster destroys its workloads, volumes and data. We do not keep a copy. Take your own backups before you delete anything you want to keep.
07 Availability and changes
The service is provided as-is and as-available. There is no service level agreement: we do not commit to an uptime percentage, and we offer no service credits. We run the platform carefully and monitor it, but you should not place a workload here that cannot tolerate an outage. If we ever offer an SLA it will be a separate published document; nothing in these terms implies one.
We perform maintenance, including maintenance that restarts components. Where it is planned and disruptive we announce it in advance; where it is a security fix we may act immediately.
We may add, change or withdraw features. For a change that materially reduces what you already use, we give you notice. Price changes are announced in advance and take effect from the next billing month — never retroactively, and never within a month already locked under section 4.
08 Liability
To the extent the law permits, our total liability to you for all claims arising in any 12-month period is capped at the total fees you paid us in the 12 months before the event giving rise to the claim.
We are not liable for loss of profits, loss of business, or indirect or consequential loss; nor for loss of your data or workloads beyond restoring from backups you have configured. We do not take backups of your cluster data on your behalf.
Nothing in these terms excludes or limits liability that cannot lawfully be excluded or limited — including liability for death or personal injury caused by negligence, for fraud, and any liability a consumer has under mandatory law.
You are responsible for your workloads, and you will cover claims brought against us that arise from what you ran or stored on the platform.
09 Termination, law and contact
We may suspend or terminate an account for a material breach of these terms — in particular section 3 — and, where the breach can be fixed, we will say what is wrong and give you a reasonable chance to fix it first. Section 5 governs termination for non-payment. You may terminate at any time under section 6.
These terms are governed by the laws of Romania, and the courts of Maramureș County, Romania have jurisdiction — without affecting any right you have as a consumer to bring proceedings where you live.
We may change these terms. We will announce a material change in advance, in the portal and by email, and the "last updated" date above always reflects the current version. Continuing to use the service after a change takes effect means you accept it; if you do not, you may close your account under section 6.
Questions about these terms: legal@aetherplatform.cloud. Operational questions belong in a support ticket in the portal, which reaches us faster.