Dora NodaUbicloud calls itself "the open source alternative to AWS." It gives you elastic compute, block storage, a firewall and load balancer, managed Postgres, managed Kubernetes, and IAM — all running on bare-metal providers like Hetzner, self-hostable or available as a managed service, at what the company claims is a third of the equivalent AWS bill. It's a genuinely useful project, and it runs on the same Hetzner hardware a Cluster-API-managed PaaS fleet already targets.
So here's the question worth answering directly, not with a feature comparison: should bex provision Cluster API's Hetzner nodes on top of Ubicloud's IaaS layer instead of talking to Hetzner's Cloud and Robot APIs directly? The short answer is no, not as a default — because "on top of Ubicloud" isn't a config flag, it's a new Cluster API infrastructure provider someone has to write and maintain, trading a dependency on Hetzner's API for a dependency on Ubicloud's API and Hetzner's underneath it. The rest of this piece is the architecture that makes that answer concrete, and the one condition under which the trade would flip.
What Ubicloud Actually Is
Ubicloud isn't a thin API wrapper — it's a full control plane. It's written in Ruby on Roda and Sequel, and it manages Linux "data plane" nodes over SSH, provisioning VMs through Cloud Hypervisor inside Linux namespaces. To get a Hetzner box into the system, you run Ubicloud's "cloudify" script against it, which currently works against bare-metal servers leased from Hetzner (and Leaseweb), not virtual machines — nested virtualization isn't supported, so you can't cloudify a Proxmox VM.
Once a box is cloudified, Ubicloud exposes it through its own primitives: elastic compute, non-replicated block storage, virtual networking, managed Postgres, managed Kubernetes, and an attribute-based IAM system with recursive tag resolution. The company — founded by the team that built Citus Data before its acquisition by Microsoft — raised a $16M seed in March 2024 (Y Combinator, e2vc, and others) and says its services now power more than a million VMs a week, with managed Postgres running up to 9x faster transactions than AWS RDS on local NVMe storage. It isn't a napkin-stage project; it's operating at real scale.
It also isn't static pricing. Ubicloud raised prices roughly 26% in 2026 — new deployments at the higher rate from May 1, existing resources migrated June 1 — citing over 30% growth in its own infrastructure costs since its last adjustment in 2024. That same window brought a strategic partnership with ClickHouse, bundling Ubicloud-managed Postgres into ClickHouse Cloud for unified transactional-plus-analytical workloads. Worth noting for the cost math below: Ubicloud is itself exposed to the input-cost pressure (Hetzner hardware, DRAM) that's been repricing the entire self-hosting stack throughout 2026 — it just absorbs that pressure one layer removed from the hardware, the same position a hosted PaaS occupies relative to Ubicloud's own customers.
What Cluster API on Hetzner Actually Is
Cluster API Provider Hetzner (CAPH) sits at a different layer entirely. It's a Kubernetes-native controller set that extends the Cluster API's declarative machine lifecycle to Hetzner infrastructure. A HCloudMachine custom resource maps to a Hetzner Cloud VM; a HetznerBareMetalHost maps one-to-one to a Hetzner dedicated server, registered into an inventory that CAPH's controllers reconcile against. When a machine goes unhealthy, CAPH's self-healing loop reprovisions it — no SSH session, no manual intervention — because the desired state lives in the Kubernetes API, not in a human's runbook.
Critically, CAPH talks to Hetzner's own Cloud and Robot APIs directly. There's no intermediary translating machine specs into Hetzner API calls; the provider is that translation layer, and it's purpose-built for exactly this reconciliation loop.
The Actual Architectural Question: What Changes If You Stack Them?
Here's what "provision Cluster API's Hetzner nodes on top of Ubicloud" would concretely require. CAPH's controllers are written against Hetzner's Cloud API — HCloudMachine creates a server via hcloud-go, Hetzner's own SDK. Ubicloud's compute API is not the Hetzner Cloud API. It's Ubicloud's own resource model — VMs backed by Cloud Hypervisor, addressed through Ubicloud's control plane, with its own auth, its own IAM, its own lifecycle semantics. No Cluster API infrastructure provider for Ubicloud exists today.
That means "stack them" isn't a configuration change to CAPH — it's writing a new provider (call it a hypothetical CAPU) that reconciles Cluster API Machine objects against Ubicloud's compute API instead of Hetzner's. That provider needs its own controller, its own CRDs mapping Ubicloud VM state into Cluster API machine phases, and its own maintenance burden every time either Cluster API's contract or Ubicloud's API changes underneath it. This is the honest verdict the title promises: not a drop-in swap, a net-new piece of infrastructure software to build and carry.
What That Extra Layer Would Actually Buy
The case for building it isn't nothing. Ubicloud cloudifies bare-metal servers from multiple providers — Hetzner today, Leaseweb, and AWS bare-metal instances per its own docs — behind one consistent compute API. A Cluster API provider written against that API would inherit portability across all of them for free; a provider written directly against Hetzner's API, like CAPH, is Hetzner-only by construction. If a tenant someday needs a node pool on a bare-metal provider Hetzner doesn't operate in — a region, a compliance jurisdiction, a hardware spec Hetzner doesn't sell — routing through Ubicloud's abstraction would mean not writing a second Hetzner-style provider from scratch for every new bare-metal vendor.
That's a real, specific benefit. It's also a benefit for a problem bex doesn't have yet: today's fleet is Hetzner-only by design, and Netcup is the only other bare-metal vendor even under evaluation elsewhere on this list — as a cost-comparison footnote, explicitly not a CAPH target, for the same reason: no Cluster API provider tooling exists for it either.
What That Extra Layer Actually Costs
Two costs, and both are concrete rather than hypothetical. First, operational: Ubicloud's own self-hosting docs are direct about what running its control plane entails — you bootstrap each node with its "rhizome" agent, manage the control plane's own availability (it needs a PostgreSQL instance and Ruby 4.0 to run), rotate secrets, apply updates, and monitor for stuck jobs, because "there is no self-healing control plane — you own the reliability of the system." That's an entire second control plane to operate, sitting underneath Cluster API's own control plane, which already exists to solve the self-healing problem. Running CAPH on top of Ubicloud doesn't remove an operational surface; it adds one, and the new one explicitly doesn't self-heal the way the thing built on top of it does.
Second, financial: Ubicloud's own margin, now larger post-May-2026 repricing, sits between the tenant's bill and the Hetzner hardware it ultimately runs on. That's the identical structural critique this list has already leveled at Qovery's $299–$2,099/month control-plane fee layered over a team's existing cloud bill — a rented abstraction charging its own margin on infrastructure already being paid for once. Ubicloud is dramatically cheaper than Qovery's positioning and it's solving a different problem (an IaaS layer, not a PaaS control plane), but the shape of the trade is the same: every layer between a workload and the bare metal it runs on is a layer with its own pricing decision, made on its own schedule, for its own reasons — and 2026 has shown Ubicloud will move that lever when its own costs move.
Two Different "Open-Source X Clone" Pitches
It's worth being precise about why "open-source AWS clone" and "open-source Render clone" aren't competing descriptions of the same product — they're descriptions of adjacent layers in the same stack. Ubicloud's primitives — VMs, block storage, managed Postgres, Kubernetes-as-a-service, IAM — are infrastructure a platform could be built on. A git-push PaaS's job is turning a repository into a running, HTTPS-served application; it consumes infrastructure primitives, it doesn't re-sell them as primitives.
That distinction lands directly on a boundary bex already draws deliberately: managed databases are a stated non-goal, not a gap waiting to be closed. Ubicloud's managed Postgres — the product built by the team that built Citus — is a serious answer to "I want a database I don't operate." That's precisely the layer a self-hosted PaaS focused on deploying applications intentionally leaves to someone else, or to the tenant's own Postgres instance. Treating Ubicloud's Postgres offering as a reason to reconsider that non-goal would be a scope creep this list has flagged before under a different vendor's name; treating it as validation that the boundary is correctly drawn — infrastructure primitives are their own product category — is the more honest read.
The Verdict
For a Hetzner-only Cluster-API fleet today, CAPH talking directly to Hetzner's Cloud and Robot APIs stays the right architecture: one fewer control plane to operate, one fewer vendor margin between a tenant's bill and the hardware, and a provider that already exists and is purpose-built for exactly this reconciliation loop. Ubicloud's cloudify layer is a genuinely useful project for the problem it's actually solving — turning bare metal from any of several providers into consistent IaaS primitives without hand-rolling that layer yourself — and the trigger for revisiting this isn't Ubicloud's existence, it's a real tenant requirement for a bare-metal provider Hetzner doesn't operate in. Until that requirement shows up, building a Cluster API provider against Ubicloud's API would be solving a portability problem the fleet doesn't have yet, at the cost of a second unhealed control plane and a second margin it does have today.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned straight through Cluster API onto Hetzner's own APIs, no intermediary control plane required. Star the repo on GitHub or deploy your first app today.
Sources
- Ubicloud — Open source alternative to AWS
- ubicloud/ubicloud on GitHub
- Ubicloud Price Adjustment (2026)
- ClickHouse PostgreSQL powered by Ubicloud
- Build Your Own Cloud — Ubicloud Documentation
- Ubicloud Kubernetes
- Ubicloud: Funding, Team & Investors
- Cluster API Provider Hetzner (CAPH) — Introduction
- syself/cluster-api-provider-hetzner on GitHub
- HetznerBareMetalHost reference — CAPH Docs.
