Platform model
Aether is built around a clean split: you own and run your tenant clusters; we run the control plane. Understanding that split makes everything else fall into place.
Tenant clusters
Section titled “Tenant clusters”A tenant cluster is a Kubernetes cluster that belongs to your organization.
It’s where your workloads run. You create as many as you need, on the regions you
choose, and you have full kubectl-level control over what runs inside them:
Deployments, Services, ingress, network policies, persistent volumes, and so on.
The managed control plane
Section titled “The managed control plane”Every cluster has a Kubernetes control plane — the API server and the components that schedule and reconcile your workloads. On Aether, the control plane is fully managed. Aether provisions it, operates it, keeps it healthy, and backs it with a fully managed datastore.
You never:
- Manage, patch, or upgrade the control plane’s machines.
- SSH into control-plane nodes.
- Size, scale, or babysit the control-plane database.
You only ever interact with the control plane through its Kubernetes API — the same way any Kubernetes client does.
How tenants are separated
Section titled “How tenants are separated”Aether separates tenants at several specific layers. These are the concrete mechanisms — read them as the scope of what the platform does, not as a blanket claim of security:
- Network. Each cluster’s worker nodes sit on their own VLAN, separate from every other cluster’s.
- Control plane. Each cluster has its own control plane, and its state lives in a dedicated per-tenant datastore database.
- Load balancers. A cluster’s
LoadBalancerServices are served by a load-balancer VM perLoadBalancerService, dedicated to your cluster. - Registry. Each organization gets its own registry project, which is the boundary the registry’s credentials are scoped to.
Every cluster gets a public Kubernetes API endpoint. It is mandatory and billed at €4 per month, locked the first time the billing sampler observes the address. Private-network-only connectivity to the API server, which would make the public endpoint optional, is a future capability and is not available today.
The endpoint is protected by TLS, with client-certificate authentication — the kubeconfig you download carries a client certificate — and Kubernetes RBAC. You can narrow reachability further with authorized networks; see the Networking model.
Everything inside the cluster is yours to secure: your workloads and their dependencies, your RBAC bindings, your Secrets, and your application-level security.
Backups
Section titled “Backups”Here is what the platform backs up, and what stays yours:
- Aether backs up the control-plane datastore. Your cluster’s Kubernetes state is protected by continuous write-ahead-log archiving, so the control plane can be recovered.
- Aether does not back up your application data or your persistent volumes. PV backups are yours to own — schedule them with the backup tool of your choice, and keep your manifests in Git so your workloads can be reapplied.
Who’s responsible for what
Section titled “Who’s responsible for what”| Aether handles | You handle |
|---|---|
| Provisioning and operating the control plane | Your workloads and manifests |
| Control-plane health, the cluster datastore, and its backups | Your application data, your PVCs, and backing them up |
| Installing the Cilium CNI | Your NetworkPolicy rules and ingress |
| Bringing up, autoscaling, and tearing down worker nodes | Choosing node-pool sizes, counts, and autoscaling budgets |
| Managed load balancers, block and shared storage, registry | Using them from your workloads |
| TLS on the API endpoint and platform surfaces | Your cluster’s RBAC, Secrets, and application security |
Learn more
Section titled “Learn more”- Regions — where your clusters live.
- Node-pool model — how your worker nodes work.
- Networking model — isolation and connectivity.