Bring Your Own Hetzner Account: Edka, Cluster API, and the Token With Only Two Permission Levels

On June 16, 2026, Vercel announced Bring Your Own Cloud on AWS — compute, build artifacts, and application data inside your own AWS account and VPC, with Vercel operating the control plane on top. It works because AWS hands a vendor a very specific kind of key: a cross-account IAM role, scoped to named actions, guarded by an sts:ExternalId so nobody else can borrow it, auditable after the fact with Access Analyzer's unused-access findings.

Edka does the same trick on Hetzner. Its Show HN drew 437 points and 130 comments for a genuinely good pitch: a production-ready k3s cluster in about two minutes, in your Hetzner project, on servers you're billed for directly. To do that, you paste a Hetzner API token into someone else's web app.

Here is the thing nobody says out loud. A Hetzner Cloud API token has exactly two settings: Read, or Read & Write. It is bound to one project. There is no resource-type scoping, no IP allowlist, no tag condition, no expiry, and no assume-role equivalent. The entire security apparatus that makes BYOC defensible on AWS does not exist here.

That does not make the pattern wrong. It makes the trade-off worth pricing out precisely.

Three ways to run Kubernetes on machines you own​

One workload, priced three ways: a 3-node k3s cluster, 6 vCPU and 12 GB total (1 control plane + 2 workers), on Hetzner's post-June-2026 price list — CX23 at €5.49/mo for 2 vCPU / 4 GB / 20 TB traffic, plus €0.50/mo per IPv4. Excluded symmetrically from every column: load balancers (Hetzner's start around €5.39/mo), block storage (€0.0572/GB/mo), and egress overage (€1/TB past the included 20 TB). USD converted at €1 = $1.10.

Four things fall out of that table, and only one of them is the number people expect.

The closed-PaaS column is a range, not a point. Railway meters actual usage at $10/GB-RAM/month and $20/vCPU/month on top of a $20 Pro subscription, so $260 is the allocated-equivalent ceiling — what you'd pay if all 6 vCPU and 12 GB ran flat out all month. At a more realistic 20% average utilization it's $68/mo (≈€62). Railway only undercuts the €17.97 BYO column when metered usage falls to roughly zero — the $20 subscription alone is already ≈€18. For a project that truly idles, renting is close to a wash. At 20% utilization it is 3.4x the BYO column; at full allocation, 13x.

DIY is the most expensive option once your time has a price. €26.96 of hardware is the cheapest hardware row in the table and the most misleading one. A CAPH management cluster is a real cluster: provider version bumps, its own Kubernetes upgrades, etcd backup restores you actually test. Two and a half hours a month at a €75/h loaded rate is €188. If your time genuinely costs nothing, DIY is €9/month more than Edka's free plan and still the most work. That is the honest shape of the trade.

The BYO column's zero is real, and it has a cliff behind it. Edka's Free plan covers one cluster of up to 24 vCPUs, 5 apps, 4 databases and 2 agents — our entire 6-vCPU workload fits inside it, with room for four times the compute. The next step up is Standard at €180/month for 2 clusters, 15 apps and 10 databases (€45/mo for qualifying startups for three years), then Pro at €450. So the fee is €0 until the day you need a second cluster, a sixth app, or a fifth database — and then it is €180. Budget for the cliff, not the free tier: at Standard, the platform fee is ten times the hardware it is managing.

And the row that matters most is identical in two columns. Whether Edka holds your token or you hold it, the blast radius is the entire Hetzner project. Doing it yourself does not shrink the risk. It only changes whose laptop it's on.

For scale: EKS and GKE Standard both charge $0.10/hour — $73/month — for the control plane alone, before a single worker node. The whole 3-node Hetzner cluster costs less than the API server bill on a hyperscaler.

What a Hetzner API token actually grants​

Read means GET. Read & Write means GET, POST, PUT, and DELETE — across everything in the project. You cannot mint a token that manages servers but not firewalls. You cannot restrict it to a resource tag, or to the vendor's egress IPs, or to a two-week window. Tokens don't expire on their own.

Concretely, one leaked Read & Write token can delete every server, every volume, every floating IP, and every snapshot in that project — including the snapshots you were counting on to undo it.

Compare the AWS controls a BYOC vendor is expected to operate under: a cross-account role whose trust policy demands a vendor-specific external ID (the standard fix for the confused-deputy problem), an identity policy scoped to named actions, a permission boundary above it, and Access Analyzer flagging permissions the vendor never actually exercised. That is four independent levers. Hetzner gives you one checkbox.

So use the one scope Hetzner does give you: the project.

• One project per environment. Prod and staging in the same project means one token spans both. Splitting them is free and it is the only isolation primitive available.
• One token per consumer. Edka gets its own token; your CI gets a different one; your laptop gets a third. Revocation should never be an all-or-nothing event.
• Backups in a separate project. If snapshots live where the compute lives, a write token that can destroy the cluster can also destroy its recovery path. Ship backups to a project — or a provider — the cluster's own token cannot reach.
• Rotate on a calendar, not on an incident. Since tokens never expire, rotation is entirely your discipline. If a control plane can't survive you swapping its token without a support ticket, that is a design smell worth catching before you depend on it.

BYO-account versus Cluster API on the same hardware​

Cluster API Provider Hetzner (CAPH, Apache-2.0, maintained by Syself and the community) reaches the same servers by a different road. You stand up a temporary kind cluster locally, run clusterctl init --core cluster-api --bootstrap kubeadm --control-plane kubeadm --infrastructure hetzner, store HCLOUD_TOKEN in a Kubernetes Secret, declare HetznerCluster and HCloudMachine objects, then clusterctl move to pivot management onto a permanent cluster.

Two details from CAPH's own docs are worth knowing before you start. The token secret defaults to the name hetzner for every cluster, which quietly becomes a footgun the moment you manage clusters across multiple Hetzner projects from one management cluster — different projects, colliding secret names. And the --move flag on that secret is what lets the pivot work at all; miss it and your management cluster arrives without the credentials to manage anything.

What each model actually gives you:

Cluster API gives you declarative infrastructure as Kubernetes objects, self-healing machines (a dead node gets replaced by a controller, not by you), bare-metal support alongside cloud instances, and a credential that never leaves infrastructure you control. It is the right substrate for a fleet.

Cluster API has no opinion about anything above the cluster. Edka's four layers — provisioning, add-ons (metrics-server and cert-manager preconfigured for Hetzner), applications (Postgres via CloudNativePG with point-in-time recovery), and deployments (registry integration, autoscaling, secrets) — are all work CAPI deliberately leaves to you. That is not a gap in CAPI; it is a different scope.

The blunt version of the choice, from the HN thread itself: "Unless it's your core business, limit yourself to deploying applications on Kubernetes instead of managing Kubernetes itself." CAPI is how you manage Kubernetes well. A BYO-account control plane is a bet that you'd rather not.

The checklist before you paste the token​

What should a control plane offer before it earns an account token this blunt? Here is the testable version — every item is something you can verify before the paste, not after.

1. You can run the control plane yourself. A real OSI license and a self-host path mean the credential never has to leave your infrastructure. Edka is proprietary, and several HN commenters named exactly that as the trust limitation versus community Terraform modules like kube-hetzner or hcloud-k8s, where you can read every API call before you run it.
2. Envelope encryption if it is hosted. Edka encrypts sensitive data with Vault and AWS KMS before storage, per the maintainer's replies in the thread. That is the right shape. Ask, and expect a specific answer.
3. Outbound-only. An agent in your cluster that dials the control plane beats a control plane that dials into you. Nothing about the pattern requires inbound vendor access.
4. A published inventory of API calls. If the vendor documents which Hetzner endpoints it touches, you can diff that against your project's actual activity. If it doesn't, you have no way to notice drift.
5. The cluster outlives the subscription. Stock k3s or kubeadm, a plain kubeconfig, no proprietary CRDs in the data path. Cancel the account and you should still have a Kubernetes cluster — that is the entire point of BYO-account over closed PaaS, and it is worth confirming rather than assuming.
6. Control plane down ≠ apps down. Verify what a vendor outage actually does. If your workloads keep serving and only new deploys stall, the risk is bounded. If your ingress depends on their uptime, it isn't BYOC.
7. Rotation is a one-click operation, not a support ticket.
8. Someone is legally identifiable. The HN thread spent real energy on this: at launch the project was run by an individual freelancer rather than a registered company, and the maintainer responded by publishing registration details and updating the legal notices. That is the correct outcome — but it was the community, not the signup flow, that surfaced the question. It is a fair thing to ask about any vendor you hand a write credential to.

The pattern is right; the substrate isn't finished​

BYOC is clearly winning as an architecture. Vercel shipped it on AWS in June 2026, Pinecone and IBM watsonx.data run the same control-plane-here/data-plane-there split, and the appeal is easy to state: you own the servers, the bill, and the exit.

The uncomfortable part is that the pattern's safety rails were designed for clouds with a mature IAM system, and the hardware everybody actually wants to run this on is cheap European metal whose access model is one checkbox. Until Hetzner ships scoped tokens, the honest mitigations are the boring ones — separate projects, separate tokens, backups somewhere the compute token can't reach, and a control plane you could run yourself if you had to.

The projects that win this category will be the ones where "if you had to" is a documented Tuesday, not a hypothetical.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned through Cluster API into your account and your bill. Star the repo on GitHub or deploy your first app today.

Sources​

• Show HN: Edka – Kubernetes clusters on your own Hetzner account — Hacker News, 437 points, 130 comments
• Edka pricing — Free / Standard €180 / Pro €450, August 2026
• Generating an API token and Hetzner Cloud API reference
• cluster-api-provider-hetzner and CAPH preparation docs
• Vercel Ship 2026 recap — BYOC on AWS, June 16, 2026
• What is BYOC? A Developer's Guide for 2026 — Railway
• Hetzner price increase June 2026: CPX and CCX up to +176%
• Hetzner Cloud pricing calculator, August 2026
• Managing Kubernetes on Hetzner with Cluster API — Hetzner Community
• Security best practices in IAM — Amazon Web Services documentation.