Your Cloud Account, Their Control Plane: Why Edka's BYO-Hetzner Model Is Winning

On August 15, 2025, a solo founder named Camil Blanaru posted a Show HN that hit 437 points. The pitch was one sentence long: Edka spins up a production-ready Kubernetes cluster in your own Hetzner account in about two minutes. Not on Edka's cloud. Not on a vendor's managed Kubernetes you rent by the hour. In your Hetzner account — your servers, your bill, your exit.

That single ownership detail is why the post blew up. Hetzner is already the default cheap substrate for European self-hosting — CX and CPX Cloud instances from a few euros a month, dedicated AX and CCX lines, bare-metal Robot servers linked over vSwitch — and a decade of Kubernetes-on-Hetzner tooling (k3s, hetzner-k3s, kube-hetzner) has made cluster provisioning almost trivial. Edka's bet is that the hard part was never provisioning. It is everything after: add-ons, databases, deployments, TLS, observability, and day-two operations — the platform layer that sits between a running cluster and a team that can actually ship on it. Edka automates that layer while leaving the infrastructure in your name.

This post unpacks the four-layer design that makes that work, why the broader bring-your-own-account (BYO-account) pattern is emerging as the honest middle path between closed-PaaS billing and DIY cluster bootstrapping, how Edka's managed control plane compares concretely to the Cluster API Provider Hetzner (CAPH) alternative that provisions the same hardware declaratively, and what an Apache-2.0 control plane actually has to prove before you paste a Hetzner API token into it.

The 2-minute cluster and the four layers on top​

Edka's landing page frames itself as "the platform layer for your cloud account" and the architecture shows through even in the marketing copy. The Show HN post spelled out four layers explicitly — a useful mental model that survives beyond Edka's own product.

Layer 1 — Cluster provisioning. One command (or one console click) creates a k3s-based Kubernetes cluster on Hetzner. k3s is the deliberate choice: lightweight, single-binary, batteries-excluded Kubernetes that starts fast and stays small. Hetzner Cloud instances for speed on day one, with the option to attach Hetzner Robot dedicated servers as Metal server pools over a private vSwitch for sustained workloads. The claim is about two minutes to a production-ready foundation — not a toy single-node, but a cluster with networking, storage, and Hetzner-specific defaults (load balancers, volumes, private networking) wired up. Camil's background is a decade of Kubernetes stretching back to the alpha days and the kube-aws project before AWS launched EKS; the last four years before Edka were spent helping small businesses cut costs by moving workloads to Hetzner. The two-minute number reads less like marketing and more like someone who got tired of repeating the same bootstrap manually.

Layer 2 — Add-ons. One-click deploy for metrics-server, cert-manager, and the usual operators, preconfigured for Hetzner with no extra wiring. This is the layer most "spin up k3s on Hetzner" scripts leave you to solve yourself — and the layer where a first production outage usually lives (missing metrics, expired certs, a misconfigured ingress). Edka ships the operators pre-tuned for Hetzner's load balancer and volume primitives so you do not debug the glue.

Layer 3 — Applications. Minimal-config UIs for apps built on top of add-ons. The Show HN example: need PostgreSQL? Fill a few fields and the platform installs CloudNativePG, provisions a high-availability cluster with point-in-time recovery, and hands back ready-to-use endpoints. Backups restore to any point with a click. The same pattern extends to MySQL, Valkey (Redis), ClickHouse, and supporting services — each is a thin UI over an operator that already knows how to run on the cluster underneath. A live demo on edka.io/apps showed the flow end-to-end.

Layer 4 — Deployments. Connect CI to push container images to a public or private registry and Edka handles the rest: automatic deployment updates with semantic-versioning rules, instant rollbacks, autoscaling, persistent volumes, secrets and environment imports, and quick public exposure. A companion demo on edka.io/deployments walked through the push-to-running path.

Underneath, the stack is candidly listed: TypeScript, React + Tailwind CSS, PostgreSQL, Redis, BullMQ, and Vault plus AWS KMS for encrypted sensitive data. Pricing is equally explicit — a Free tier (1 cluster, up to 24 vCPUs, Cloud instances only), Standard at €180 per month (2 clusters, unlimited vCPUs, HA control plane, Metal pools, 3 users), and Pro at €450 per month (3 clusters, advanced per-node observability, 10 users). Startup and solo-founder discounts cut Standard to €45 and Pro to €90 for three years. Satellite clusters — single-node Kubernetes on a VPS or on-prem machine you already own, joined with one command — are included in every tier (1 on Free, 5 on Standard, 10 on Pro) and cost €10 per month each beyond that. Cloud and Metal instances themselves are always billed separately by Hetzner, directly in your account. That separation is the whole point: Edka charges for the platform, Hetzner charges for the metal.

The product is at version 0.9.6 as of this writing, still in beta, with Hetzner Cloud as the only supported provider today and AWS, GCP, Scaleway, DigitalOcean, and OVH listed as "coming soon." Newer surface on the site adds Codex environments and Hermes/OpenClaw agent runtimes, private networking with Tailscale and Cloudflare Zero Trust, Gateway API, custom domains with TLS, and built-in observability — the usual PaaS surface, just running on hardware you own.

Why BYO-account is winning as the middle path​

For five years the default advice split cleanly into two camps. Camp one: use a hosted PaaS — Render, Railway, Fly.io, Vercel — and accept that you pay their margin on every line item and their repricing schedule controls your forecasting. Camp two: bootstrap your own Kubernetes, learn the add-ons, write the Terraform, and own the bill — along with the 3 a.m. pager.

Both camps are honest positions. Both carry a tax that 2026 has made harder to ignore. Hosted PaaS pricing on every major platform repriced at least once in the last twelve months — Render's workspace overhaul, Netlify's per-seat-to-flat switch, Vercel's fourth repricing since 2024, Fly.io's new billing lines, Docker Hub's 80% Pro jump — and Hetzner itself raised Cloud and dedicated-server prices twice in 2026 on DRAM-constrained hardware. Owning the cluster outright still beats paying a margin, but bootstrapping from scratch still means owning every integration mistake yourself.

BYO-account control planes split the difference. You create a Hetzner (or AWS, or GCP) account you own. You generate an API token scoped to that account. A control plane — Edka, Porter (YC S20), Qovery, Northflank, Ownkube, and the coming wave of agent-ops dashboards — uses that token to provision, configure, and operate infrastructure inside your account. The servers, volumes, load balancers, and traffic bills land on your provider invoice. The control plane bills separately, flat, for the software that made those resources useful. If you stop paying the control plane, the infrastructure stays — it is Kubernetes with standard add-ons, not a proprietary runtime that deletes your data when the subscription lapses.

Three properties make this pattern sticky once teams try it:

• You own the exit. The data plane is standard Kubernetes. Edka says this explicitly: "Kubernetes native, portable foundation" with "a clear detach path." The escape hatch is not a migration guide — it is the fact that kubectl already works and the operators are not proprietary forks.
• You own the bill. Hetzner's invoice is Hetzner's price list, passed through without a vendor margin on top. A Hetzner CPX31 at ~€13 per month costs ~€13 whether Edka provisioned it or you did. That does not make it free — Hetzner's own 2026 repricings proved the substrate can move — but it removes one entire margin layer and one entire schedule of surprise line items from the bill.
• You own the failure domain. A hosted PaaS outage is a multi-tenant event — everyone sharing the same edge, control plane, and support queue recovers in order. A fleet on your own Hetzner account shares a fault domain you drew, not one a vendor's incident commander is load-shedding for the largest tenants first.

The counter-argument is real too: you also own the account hygiene. Token rotation, project scoping, backup retention, and upgrade windows are yours to not neglect. BYO-account does not remove ops — it removes the ops that are identical on every team (bootstrap, add-on wiring, TLS) and leaves the ones that are specific to your workload.

Edka versus Cluster API on the same Hetzner hardware​

The sharpest comparison for Edka is not Render or Railway. It is the other way to get declarative, self-healing Kubernetes on the same Hetzner metal: Cluster API Provider Hetzner (CAPH), the CNCF-aligned open-source provider maintained under syself with about 1,130 GitHub stars and active maintenance (last update August 2026). Both aim at the same terminal state — production Kubernetes on Hetzner you own — but they start from opposite ends of the abstraction stack.

Neither is "better" without a team shape attached. If you have a platform engineer who already lives in Cluster API and wants to compose exactly the ingress, policy, and observability stack the org standardized on, CAPH gives you finer grain and no control-plane subscription. If you are a small team that wants Render-style "push and it runs" but on your own bill and with kubectl when you need it, Edka's four layers replace a quarter of bespoke glue you would otherwise write, test, and page for.

The honest hybrid is common: CAPH for the fleet, Edka-style tooling (or bex, or Porter) for the tenant surface. One manages Machines, the other manages what tenants push onto them. The 2026 consensus on HN roundups that "PaaS should be the default, Kubernetes the exception" gets this half right — most teams should not hand-roll a platform — but draws the conclusion as binary when the BYO-account pattern is the synthesis: PaaS ergonomics, Kubernetes underneath.

What "trust us with your Hetzner token" actually has to mean​

Every BYO-account control plane asks for the same unnerving thing: an API token scoped to an account that can create and delete servers on your behalf. The Edka HN thread was full of the right question — "what have you done for security hardening?" — and the answer deserves to be a checklist, not a vibe. If you are evaluating any BYO control plane (Edka, bex, or any successor), these are the non-negotiables:

• Scoped, revocable, and least-privilege tokens. Hetzner Cloud supports project-scoped API tokens. A control plane should document exactly which scopes it needs (read vs write, which projects) and nothing more, and revocation should be immediate and tested. Edka's docs show project-scoped provisioning, which is the correct granularity — one compromised token does not mean every project in the account is writable.

• Envelope encryption for secrets at rest. Storing a Hetzner token or a database password in plaintext in a Postgres column is a breach waiting for a dump. The Show HN post lists Vault plus AWS KMS for sensitive data — the standard envelope pattern where Vault holds the data encryption keys and KMS holds the master key, so a database leak alone does not leak tokens. Any BYO control plane that cannot name its KMS and rotation story has not thought about this long enough.

• A detach path you can test before you need it. "No vendor lock-in" is cheap to say. It is expensive to prove. The test is: can you revoke the control plane's token, keep the cluster, and continue operating it with kubectl, Helm, and your own GitOps? If the answer requires exporting proprietary state, the "you own the servers" pitch is half true. Edka's insistence on k3s + standard operators + keep-your-Hetzner-account is the right shape — verify it by actually detaching a staging cluster during evaluation.

• Open-source control plane, or a credible substitute for it. This is where license matters. Bex is Apache-2.0 — you can self-host the entire control plane, not just the data plane. Edka is source-available in the sense that the managed service is the product; the infrastructure it leaves behind is standard Kubernetes, which is a weaker but still meaningful guarantee. For teams whose threat model includes "what if the vendor disappears," an Apache-2.0 control plane you can run yourself is a strictly stronger answer than a promise about the data plane. Ask which layer is open and which is not, and price that distinction into the decision.

• Auditability of what the control plane did on your behalf. Every server create, volume attach, and firewall rule change should be an auditable event tied to an actor (human or automation). BullMQ-backed job queues and observable diagnostics, which Edka lists as part of the stack, are the plumbing for this — but plumbing is not proof. Ask to see the audit log.

None of this is unique to Edka. It is the price of admission for any team that lets a SaaS create servers in their name. The BYO-account pattern earns trust not by asking for less access but by making the consequences of granting it narrow, revocable, and survivable.

Where BYO wins, where it doesn't, and what to do on Monday​

BYO-account control planes win most clearly for teams that already decided Hetzner is where they want to run — European data residency, predictable flat invoices, bare-metal economics — but do not want to re-derive the same platform glue every new hire has to learn. The 437-point HN thread is a proxy for how many teams are already sitting in that exact gap: they know Hetzner is cheap, they know k3s is easy, and they know the third week of add-on integration is where the optimism dies.

BYO wins less clearly when the team has no opinion on the substrate yet, or when its workload is genuinely bursty and idle-free in a way that per-second billing (Fly.io Machines, Cloud Run) actually fits. A cluster you pay for by the month is the wrong instrument for a workload that runs ten seconds an hour. BYO also wins less clearly if the team's real need is multi-cloud abstraction — Crossplane-style composite resource definitions spanning clouds — rather than one good fleet on one good provider. Edka's own roadmap lists AWS, GCP, and others as "coming soon" but is Hetzner-only today, which is honest about the current scope.

If you want to try the pattern without rewriting your deploy pipeline, the lowest-regret path is:

1. Create a dedicated Hetzner Cloud project with a scoped token (not your main project).
2. Provision a single staging cluster via the BYO control plane and deploy one real service to it — not a hello-world, a service with a database, TLS, and a backup schedule.
3. Practice the detach: revoke the token, operate the cluster with kubectl for a day, restore a database backup with the underlying operator directly.
4. Then decide whether you want the control plane to manage the fleet long-term or just to bootstrap it.

Edka is one implementation of that path — polished, opinionated, and explicit about you owning the account — but the pattern is bigger than one product. The teams quietly winning on Hetzner in 2026 are not debating whether to self-host. They are deciding where the boundary between "I own this" and "I automate this" should sit. BYO-account control planes put that boundary in the one place both sides can agree on: your account, their automation, and an exit you can test before you need it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Like Edka, it provisions into infrastructure you control; unlike a managed BYO service, the control plane itself is Apache-2.0 and self-hostable. Star the repo on GitHub or deploy your first app today.