1) What are the limitations of the scaling you do? Can I do this programmatically? I.e. send some requests to get additional pods of a specific type online?

2) What have you done in terms of security hardening? you mention hardened pods/cluster, but specifically, did you do pentest? Just follow best practice? Periodic scans? Stress tests?

I would have never guessed that there's an overlap between the circle of people wanting to run a prod workload on a K8s cluster and folks that need a GUI to set up and manage a K8s cluster would be that big but looks like I might be wrong.

Is there are plans to support Gitlab and gitlab registry (or any registry) ?

It's not the smoothest thing I've ever used, but it's all self hosted and everything can be fixed with some Terraform or SSH.

Great to see some managed Kubernetes on Hetzner!

So in reality you would pay €20 per month for the standard plan and also extra for control plane nodes.

Also, with this Terraform module I can setup a similar setup without paying any extra fee for your service: https://github.com/hcloud-k8s/terraform-hcloud-kubernetes/tr...

The Terraform module takes care of ingress, certificates, metrics etc

Anyway, congrats for shipping

But the TF and other tools are using the API to add and kill nodes, if you could pass a class of nodes to those tools that they know can't create but are able to wipe and rebuild, this would be ideal.

My theory is that with terraform and a container based infra, that it should be pretty easier with Claude Code to migrate wherever.

From there it was much easier just using it for whatever I wanted, including K3S

For me it does not pass the smell test. No physical address, no idea who is running it, no idea if company is indeed registered or not. The pricing FAQ at least talks about VAT and I assume it is EU VAT but could be anything.

We considered reaching out in May, but held back because we want to run on bare metal.

Any chance to get this provisioned on bare metal at Hetzner?

We have K8S running on bare metal there. It's a slog to get it all working, but for our use case, having a dedicated 10G LAN between nodes (and a bare metal Cassandra cluster in the same rack) makes a big difference in performance.

Also, from a cost perspective. We run AX41-NVMe dedicated servers that cost us about EUR 64 per server with a 10G LAN, all in the same rack. Getting the same horsepower using Cloud instances I guess would be a CCX43, which costs almost double.

I do notice that this deploys onto their cloud offering, which we've (https://lithus.eu) found to be a little shaky in a few places. We deploy clients onto their bare metal line-up which we find to be pretty rock solid. The worst that typically happens is the scheduled restart of an upstream router, which we mitigate via multi-AZ deployments.

That being said, there is a base cluster size under which a custom bare-metal deployment isn't really viable in terms of economics/effort. So I'll definitely keep an eye on this.

https://www.reddit.com/r/hetzner/comments/18yhy89/seems_like...

Feels like there should be a PV daemon that can do local, and transparent migrations and is lightweight enough to run on a single machine. Once my PV has been migrated to Ceph, the proxy could configure itself away from that job.

Join the waiting list here: https://shipacademy.dev

That way we can use Raku as a scripting language for deployment.

I created for me some scripts to add node (Hetzner instance with Ubuntu) in a Docker Swarm, and I would really love to find something as you did but for Docker Swarm

Setting up kubernetes yourself with k3s and deploying a HA database with cnpg is so simple nowadays. It works great until some day you face an issue that you can't fix without diving deep into the details e.g. debugging your CNI or the implementations of specific operators to understand reconciliation errors. I faced countless of these issues such as:

- your Postgres CNPG failed during failover and can't recover on it's own - Postgres WAL archiving suddenly doesn't work anymore after an update. - Cluster networking on some nodes doesn't work anymore due to an incompatibility of kube-proxy and Cilium after an update

Unless it's your core business I'd limit myself to deploying applications on Kubernetes instead of managing Kubernetes itself. At least for use cases where reliability matters.

There are some reasonably priced managed Kubernetes offerings out there. For example syself (https://syself.com) built a managed Kubernetes on Hetzner. The prices are super reasonable. For 300 Euros per month you can enjoy Hetzner prices with an experience that beats AWS.

Nowadays, Hetzner has many Kubernetes providers. One that I really like is Syself.com. They provide production-ready Kubernetes including self-healing, bare-metal support, OIDC integration and many more.

As a cloud and migration expert, I have evaluated them and they turned out to perform very well.

A similar approach I’ve been using is using Syself (running it for about half a year now with no issues). They contributed the Cluster API provider for Hetzner, which is obviously Chad. Of course, I wish CAPI were a bit less involved, but that’s exactly where external help makes sense. I am totally fully sold on CAPI, but then again always need your base cluster.

I still want to set up CAPI on my own, but still preferred having “someone else” host the control plane. With CAPI, though, you have the flexibility to do either.

Also Talos and Omni are cool and pretty chill on Hetzner. Fantastic tools. Still though I just like the "raw-ish" feel to kubeadm and CAPI feels the most "native" solution.

In terms of addons, I have my very curated yaml manifestos. And ArgoCD Application sets. That part is hard for me to replace, but that should defenitely be married with a UI.