Skip to content
Celum

Looking for an alternative to your private cloud?

One sovereign private cloud for your Kubernetes clusters, VMs and applications.

  • Orchestrate your entire cluster fleet
  • Stay air-gapped with the ecosystem and tools you need, ready to run
  • Identify and secure every flow in real time
  • Ask AI about anything in your environment — or let it deploy and operate for you
  • Set up your entire new environment in minutes, not days

Built on the stack you already trust

Standard open-source objects all the way down. If it speaks Cluster API, Celum reads it.

How it works

Onboard. Operate. Observe.

Point Celum at a cluster you already run and it reads what is there. Nothing is installed until you choose to onboard it.

  1. 01

    Onboard

    Give Celum a kubeconfig and the cluster becomes a supervisor, with the clusters and VMs it already runs in one list. Onboarding, when you choose it, installs networking, storage, certificates and a per-node agent. It replaces the cluster's networking and runs once, so onboard a supervisor you are prepared to have changed.

  2. 02

    Operate

    Create clusters from a template, run VMs beside them, and handle networking, storage and policy from one console. Every action is checked against a permission and written to the audit log.

  3. 03

    Observe

    Platform health per supervisor, flow visibility across clusters and VMs, and pod logs with history. Every panel names the reason a component failed, and data freshness is the first check, because empty dashboards over green components is its own kind of incident.

Security and visibility

See what is talking to what. Then lock it down.

Every connection between your clusters and your VMs is recorded and drawn, and the map turns into policy you can test before it drops anything. It is part of the product, not a paid tier. If you can't see it, you can't protect it.

  • Clusters and VMs on one map — topology, sessions, ingress and egress forensics over the window you pick, and an incident replay that walks the window backwards until the anomaly appears.
  • Policy from traffic you actually ran — watch a workload learn its edges, keep the ones that belong, and dry-run the policy against recorded traffic: it tells you which edges it would have broken before you apply it.
  • Tenants see their own project and nothing else — each project gets its own addresses, its own egress identity and isolation on by default; a team can be given flow visibility inside its project alone.
  • On-prem, air-gapped
  • Sign in with your identity provider
  • One permission per action
  • Per-project isolation
  • Audit log per resource and actor
  • Secrets in Vault or Key Vault

Use cases

What teams actually use it for.

Four jobs that come up early: a question you can only answer if something was already recording, work you would rather not stand in the middle of, a migration that cannot be a big bang, and a maintenance window you would rather not book.

  • Platform team · after the alert

    Work out what talked to the payments database at 02:00.

    Flows are recorded continuously, for clusters and virtual machines on the same map, so the question is answerable afterwards instead of only while someone happens to be watching. You pick the window around the alert rather than reconstructing it from logs.

    1. 1Open the window and choose the level — workload, pod or node — across clusters and VMs at once.
    2. 2Replay it backwards until the edge you did not expect appears, then open the session behind that edge.
    3. 3Keep the edges that belong and dry-run the policy against the traffic you just watched: it names the edges it would have broken before anything is applied.

    Flow telemetry is an onboarding step, not a paid tier. Where it was never switched on, the Security surfaces say no data rather than no traffic.

  • Dev teams · without a ticket

    Let developer teams build their own environments, with no admin in the loop.

    Standing up a dev environment does not have to route through the platform team. Map your identity provider's groups onto a project and a role, and the team creates what it needs when it needs it. You decide the boundary once, in the grant, instead of approving the same request every week.

    1. 1Groups from your identity provider become claims on a project, and the project comes with its own addresses, its own egress identity and isolation on by default.
    2. 2A vcluster control plane comes up in seconds at near-zero infrastructure cost — the cheapest environment you can hand out, and the team brings one up itself whenever it needs another.
    3. 3Every lifecycle operation is a separate permission, so a team can restart what it runs without the power to delete it, and credential downloads stay a grant of their own that Operator and Viewer never include.

    Verify what a team actually got by viewing the platform as them, before you tell them it works. Admins stay out of creation, not out of destruction: removing a cluster still takes a second person, and a requester can never approve their own request.

  • Infrastructure lead · mid-migration

    Run vSphere and its replacement side by side, and move when you are ready.

    A licensing change forces the decision, but it does not have to force a big-bang cutover. Celum connects to what you already run, so the estate you are leaving and the estate you are building sit in the same console under the same sign-in, and the migration takes as long as it takes.

    1. 1Hand Celum a kubeconfig and the cluster becomes a supervisor — nothing is installed on it, and the clusters and VMs it already runs appear in one list.
    2. 2vSphere clusters are provisioned and lifecycled alongside KubeVirt ones, while AWS, Azure, GCP, Metal3 and Docker are read and shown beside them through their standard Cluster API objects.
    3. 3New workloads land on the new stack, the old ones keep running where they are, and both are under one identity and one audit trail from the first day.

    Celum provisions and lifecycles vSphere (VKS/TKGs) and KubeVirt. For the read-only providers it displays standard Cluster API objects rather than managing their lifecycle, and it does not itself move a VM out of vSphere.

  • Ops · the window you did not book

    Patch a hypervisor host without scheduling downtime for what runs on it.

    Firmware, a kernel, a disk starting to fail — the host has to come out of service, and that normally means a maintenance window and a negotiation with whoever owns the workloads sitting on it. Move the machines instead, and the workloads never find out it happened.

    1. 1Live-migrate the running VMs off the host; a VM given a stable address keeps that address as it moves, so its connections are never rebuilt.
    2. 2The end-to-end test behind that walks every VM onto every host while a database session keeps writing, and checks that the session never reconnected.
    3. 3Restarting a machine is its own permission, separate from deleting one, and a VM that is a cluster node refuses to be deleted at all.

    The measurement is the claim: conn_id unchanged across every hop, the sequence number still climbing, one connection with no reconnect, and the stall under the 15 s limit.

In the console

Create a tenant cluster or a VM from the same list.

Fill in a cluster template, check the preview and create: the tenant cluster comes up as standard Cluster API objects. Start a KubeVirt virtual machine beside it. Both land in one Workloads list, and a VM opens into its own dashboard and console.

Platform

Everything a platform team needs. In one console.

The public-cloud experience, on hardware you own: self-service projects, one console and one API, and nothing you cannot run inside your own network.

  • Multi-supervisor control plane

    Connect any number of clusters you already run with a kubeconfig. Providers are detected; every cluster and VM rolls up into one Workloads view.

  • Clusters from templates

    Declared variables, a preview before you create, standard Cluster API objects underneath, on any supervisor you connected.

  • Virtual machines

    Golden-image clones, snapshots, live migration, Windows and Linux guests, GPU and real-time instance families.

  • Networking per project

    BGP from every node, address pools with IPAM, and each project leaving the cluster with its own source IP so upstream firewalls can be written per tenant.

  • Storage that stays boring

    Rook-Ceph, NFS and Fibre Channel; Ceph on SAN LUNs with the array's API out of the runtime path.

  • Identity, tenancy and audit

    Sign in with your identity provider, one permission per action and resource, isolated projects, every change in the audit log.

Provisions and lifecyclesKubeVirt · VMware vSphere (VKS/TKGs) · Apache CloudStack · vCluster · Kamaji hosted control planes (experimental).

Reads and shows beside the restAWS · Azure · GCP · Metal3 bare metal · Docker — their standard Cluster API objects, clusters, nodes and health.

Not listed? If it speaks Cluster API, Celum reads it.

Ready to unify your fleet?

Bring a kubeconfig to the call. We connect a cluster of yours and walk your real clusters and VMs, not a sandbox.

  • Self-hosted, on-prem
  • Open-source stack
  • Standard Cluster API objects
  • Talos on every node