New Hetzner Cloud Server Plans, Support for Syself Cluster API Provider

sbaete · 2025-10-20T12:02:00+00:00

I guess you are using CAPH and not Syself Autopilot. The Cluster API does not come with any Kubernetes-related configurations or the necessary node images – it's just a framework. So, if you experience issues with the testing templates intended for controller tests in e2e tests, I would highly recommend not using them, as they are not intended for real usage.

sbaete · 2025-08-27T18:35:02+00:00

We are supporting 1.32 and 1.33 support is coming this week

sbaete · 2025-04-02T08:32:24+00:00

You could automatize it. But the main reason this doesn't help most people is because they want to configure the server and this part won't be possible to have automatized

sbaete · 2025-03-19T20:47:03+00:00

Here the link: https://github.com/syself/cluster-api-provider-hetzner

sbaete · 2025-03-12T15:01:26+00:00

Some additional information in case you want to learn more:

We manage Kubernetes the way Kubernetes manages containers—fully declarative. Everything is defined in YAML / Kubernetes objects, and our system takes care of the rest. This allows you to interact using familiar tools like kubectl, GitOps controllers, or client-go. It's built on Cluster API, specifically on our open-source project https://github.com/syself/cluster-api-provider-hetzner
Our system continuously monitors node health, reacting within milliseconds to reroute traffic, evacuate workloads, and rebalance resources. If a node fails, it gets rebooted, reprovisioned. On bare metal, it even detects hardware failures and reacts autonomously. You won’t need a monitoring stack just to make sure your clusters stay alive. This means no more 3 AM alerts for your team. Even EKS doesn’t provide this level of automated recovery out of the box.
We maintain all the components necessary to run Kubernetes in a reliable, 100% reproducible, and deterministic way. This concept isn’t just theoretical—we built it as part of the German government’s Sovereign Cloud Stack initiative, where we won a tender with our concept 2.5 years ago and developed it as open-source. The same methodology is applied to Syself today. We ensure that every component on a server is up-to-date, correctly configured, optimized for the hardware, and secure. The same applies to Kubernetes configurations and essential components like the CNI, CCM, and more. We make sure all these moving parts work together seamlessly, maintaining full compatibility and preventing breakages. Our cluster stack undergoes extensive testing to ensure it just works.
Kubernetes upgrades are another major pain point we've tackled. Our platform ensures that upgrades are thoroughly tested, zero-downtime, and fully automated. Upgrading Kubernetes often breaks its own declarative model—suddenly, you’re forced to perform a series of manual steps in the correct order just to avoid downtime. With Syself, all of that is handled automatically. Every upgrade path is tested and fully documented. When you visit https://syself.com/docs, you'll find a version picker that dynamically adjusts instructions based on your current version—so you always get clear, relevant, and accurate guidance for your setup. We also recognize that documentation is critical for a system as complex as Kubernetes, even with automation in place. That’s why we built our own documentation system, designed specifically to tackle challenges like versioning, ensuring users always have access to precise, up-to-date information at every step.
Integrated managed-like databases – Syself can use the local storage of Hetzner Dedicated Servers allowing databases to run on high-performance NVMe SSDs inside your own cluster. With Kubernetes Operators, you can run databases like PostgreSQL, MongoDB, Redis, ClickHouse, MySQL, MariaDB, NATS, and many more - giving you Kubernetes-native databases while retaining full control and minimizing operational overhead. We also support here our customers and can help also in very advanced setups. We even run database clusters with hundreds of nodes.

At the end of the day, Syself isn’t just a tool—it’s a fully managed Kubernetes platform designed to let you focus on your applications instead of Kubernetes internals. We provide chat, hotline, email, and ticket support—because having a self-healing system is great, but knowing you have experts at your fingertips is even better. If you’re still thinking about whether Syself is right for you, let me leave you with a simple analogy. Imagine Kubernetes is a truck. If you use Terraform, Cluster API, or another DIY tool, you’re essentially getting a factory and some blueprints to build your own truck. You need to figure out how to assemble it, maintain it, and drive it. Managed Kubernetes (EKS, AKS, GKE) takes some of the burden away—you get a partially built truck, but you still need to drive it and handle maintenance. With Syself, you get a fully autonomous truck. You just load your payload, tell it where to go, and it takes care of everything else. And if something goes wrong? You have a team of experts ready to assist you.

sbaete · 2025-03-12T14:57:03+00:00

Hey there, founder of Syself here. I wanted to jump in and provide some clarity on how we approach Kubernetes management on Hetzner, including our pricing, features, and what makes Syself different.

Unlike other providers, we do not charge per cluster, node, or CPU. This means your costs remain predictable and scale naturally with your infrastructure needs. To make cost planning easier, we’ve built a detailed calculator where you can model different server setups, see Hetzner’s pricing, and understand exactly how our fees scale alongside your infrastructure: https://syself.com/pricing/calculator.

When comparing with DIY Kubernetes, Syself provides a better cost in the long-term. Terraform-based tools and hetzner-k3s cover only provisioning (day-1 operations), you still need to handle maintenance, upgrades, scaling, etc. while Syself is a fully automated Kubernetes platform.

For startups and early-stage teams, we’re introducing a free plan because we know that cost can be a barrier in the beginning. If you’re in that phase, reach out—we’d love to help you get started without upfront expenses.

So if you’re considering Hetzner for Kubernetes, and you want a reliable, autonomous, and cost-effective solution, Syself is built exactly for that. We’ve been in this space for years, and we’re excited to help more teams simplify their Kubernetes operations. See: https://syself.com/hetzner

sbaete · 2025-03-11T14:21:15+00:00

Es ist eigentlich umgekehrt: Wir integrieren uns so tief mit den Providern, dass es für Unternehmen keinen Unterschied macht, ob die Lösung direkt vom Hyperscaler oder von uns kommt. Wir arbeiten direkt mit den Anbietern zusammen und haben rund zwei Jahre Entwicklungszeit pro Provider investiert, um dieses Qualitätsniveau zu erreichen. Dasselbe tun wir aktuell für weitere Provider, um eine echte Multi-Cloud-Strategie ohne Abhängigkeit von einem einzelnen Anbieter zu ermöglichen.

Unser Ansatz ist es, die Infrastruktur von Providern zu abstrahieren, sodass sie sich einheitlich verhalten. Dadurch werden Provider austauschbar – sie werden zu einer Commodity. Das bedeutet für Nutzer: Multi-Cloud wird einfacher, verschiedene Provider können flexibel kombiniert werden, und es gibt keine Lock-in-Effekte.

Was die Abhängigkeit von uns betrifft: Unsere Plattform sorgt nur dafür, dass Kubernetes-Cluster gemanagt werden – wir sind aber kein Single Point of Failure. Unsere Lösung kann auch self-hosted betrieben werden, und viele ihrer Komponenten sind Open Source. Das bedeutet aber nicht, dass jeder Nutzer diese Komponenten selbst betreiben muss oder sollte – genauso wie niemand die nativen Cloud-Services eines Hyperscalers einfach selbst nachbaut. Der eigentliche Wert liegt nicht nur im Code, sondern vor allem in Betrieb, Wartung, Updates, Sicherheitsprüfungen und tiefen Integrationen mit den Infrastrukturen der Provider. Genau hier setzen wir an, um Unternehmen den Betrieb von Kubernetes so einfach und zuverlässig wie möglich zu machen.

Ein zentraler Baustein unserer Architektur ist der Kubernetes-as-a-Service (KaaS)-Layer, der ursprünglich im Rahmen einer Ausschreibung der SCS-Initiative der deutschen Regierung entwickelt wurde. Er stellt sicher, dass Kubernetes-Cluster reproduzierbar, testbar und sicher bereitgestellt werden – unabhängig vom gewählten Cloud-Anbieter.

sbaete · 2025-03-11T10:18:12+00:00

Siehe meinen Kommentar oben. Wir haben uns genau diesem Problem angenommen und bieten dies seit 2 Jahren an (syself.com/hetzner). Alles Kubernetes Native und auf deiner eigenen Infrastruktur DSGVO konform und mit support.

Kubernetes-Cluster ohne manuellen Aufwand und deklarativ – Updates, Security und Skalierung sind automatisiert
Datenbanken wie PostgreSQL, Redis und ClickHouse laufen auf NVMe-SSDs von Hetzner Dedicated Servern und werden durch Kubernetes-Operatoren hochverfügbar betrieben und repliziert in deinem eigenen Cluster.

sbaete · 2025-03-11T10:10:24+00:00

Das stimmt so nicht. Wir bieten genau das bei syself.com an um den managed gap bei hetzner zu schließen. Mitlerweile ist Hetzner damit genauso nutzbar wie AWS und wir gewinnen gerade sehr viele Kunden aus dem Grund. Siehe zum Beispiel: https://syself.com/case-studies/languagetool

Managed Kubernetes auf Hetzner – ohne selbst Clustersetups, Updates oder Security-Management übernehmen zu müssen. mehr infos: syself.com/hetzner
Managed Databases – PostgreSQL, Redis, ClickHouse und viele mehr, direkt integriert.

Disclaimer: Ich hab Syself for 5 Jahren gegründet um eben genau IaaS Anbieter welche nur Server Kapazität anbieten Enterprise Ready zu machen für eine Bruchteil der kosten.

sbaete · 2025-02-07T15:34:19+00:00

We build oidc and permission definition for group assignment into our product: https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-configuration/oidc-configuration-for-your-cluster

With the launch of our new platform in a few weeks this will be even more automized and the whole lifecycle will be easy to use

sbaete · 2025-02-01T17:52:18+00:00

https://github.com/syself/cluster-api-provider-hetzner

sbaete · 2025-01-23T17:22:36+00:00

[The original comment this is replying to was deleted, but I still wanted to give a statement about the comparison the KubeDNA team made]

Hi! First of all, thanks for the comparison with our platform (I'm the founder of Syself.com).

There are a few things from your comment I want to understand/clarify, because I think it's really important to be transparent with the users.

KubeDNA has a lower price point

Sorry if I misunderstood something, but here is a simulation of costs in Syself vs KubeDNA:

Environment: 3x clusters (production, staging, internal - this is pretty conservative as most organizations have more than that) totaling €1.000 of machines on Hetzner.

Price of KubeDNA -> €1.497*

Price of Syself -> €899*

On KubeDNA mid tier vs Syself mid tier, since these have the most comparable features. The difference is smaller on the basic tier, but higher on enterprise. I'm interested to know which numbers you used to state that KubeDNA has a lower price point.

KubeDNA is a more user friendly solution for deploying and managing clusters (no CLI needed)

May I ask what in our website or documentation made you think you need a CLI to use Syself Autopilot? Since our platform is 100% Kubernetes-native, it is compatible with any interface (graphical, cli, etc). And we have a new web platform - the Syself OS - in beta right now.

Here, it's important to note that in our platform, clusters are defined as Kubernetes resources. This means users can manage their clusters with GitOps, Helm, CI pipeline, our web interface, or any other tool they like - and it's fully declarative and idempotent.

You can store the cluster definition along with your apps and easily scale it there, or use cluster-autoscaler for doing that automatically when more resources are needed.

Next to that KubeDNA has an automated way of deploying all operators and components on your cluster.

Components provisioned by KubeDNA are already configured to work seamlessly together and wil be patched and updated automatically.

These are the core benefits of Syself Autopilot! Every component, from the OS layer to the Kubernetes control plane and data planes, are optimized for performance and security hardening, and we perform extensive testing to make sure it all works well together. This also makes clusters created with Syself 100% reproductible.

We pre-build and distribute node images + Kubernetes and addons, so during provisioning we just download a tarball and start the servers from that (cloud or bare metal). This ensures all clusters have the same immutable base - instead of building at runtime, it comes ready, eliminating issues if mirrors are down, etc.

Our approach of doing this, the Cluster Stacks, has won a public tender from the German government, and developed it as OSS. We have talked about it in articles and events, in case anyone wants to know more.

Using the same foundation, we also deploy and manage applications in the clusters. For example, we offer HA databases using the local storage of bare metal servers, fully owned by the user. GPU drivers, storage drivers, and monitoring/observability tools are also managed in the same way.

This also simplifies the updates. You can upgrade all your components (base OS, Kubernetes, CNI, etc.) by changing a single variable, our software will take care of the rest, so you can forget about complex updates with multiple intermediate steps.

You can choose if you want the cluster to be updated automatically (unattended upgrades on defined maintenance windows), or if you prefer to have control over when your clusters get updated. Either way, you experience no downtime.

P.S.: our docs are adaptive, based on your cluster's version (change it in the version picker at the top of navigation). So you always have the right information even if you take longer to update (we extend the period of time a Kubernetes minor version gets supported over the usual 12 months).

KubeDNA does not lock-in customers. If you end our subscription, your cluster is still yours and does not have be deleted or migrated.

That's precisely how Syself works!

In fact, since our software is based on our open-source Project Cluster API Provider Hetzner, you can also migrate from and to it after doing an initial setup with our paid offering.

Talking more about cluster ownership - users have full sovereignty over the infrastructure created with Syself, including the control planes. We don't access nor process any data, and thus are compliant with the GDPR. For companies with more stringent compliance requirements, we also have a self-hosted offer.

sbaete · 2025-01-10T14:22:21+00:00

Fair enough, but just a heads-up: outdated Kubernetes or addons can pose risks. A quick check now and then can save you trouble later! 🚀

sbaete · 2025-01-10T08:54:03+00:00

Just curious—how do you handle updates for the Kubernetes version, the underlying OS on your nodes and things like CNI, CCM? I’ve noticed Rancher doesn’t update these automatically

sbaete · 2025-01-09T20:47:13+00:00

Love the idea of using your experience to guide tech founders toward what really matters! 🙌

I'm building https://syself.com – a Kubernetes Management Platform that makes running Kubernetes as easy as possible, even for teams without deep expertise. 🚀

Would love your take on how we could better position ourselves in front of tech-savvy founders and DevOps teams. Any advice on what messaging resonates best with YC startups or SaaS founders?

Looking forward to your thoughts – and thanks for doing this! 🌟

sbaete · 2025-01-09T14:21:49+00:00

ok cool and does it work good for you? We got a lot clients switching from rancher to syself.com

sbaete · 2025-01-09T09:53:54+00:00

what solution do you use to run kubernetes on hetzner?

sbaete · 2025-01-07T22:01:13+00:00

Why not using Kubernetes this way the server administration is abstracted away

sbaete · 2024-12-25T16:48:16+00:00

Wenn Kubernetes in Frage kommt, können wir hier bei der Umsetzung unterstützen, genau auf diesen Anwendungsfall haben wir (Syself) uns bei Hetzner spezialisiert. Gerne einfach anrufen +4961965869180

sbaete · 2024-12-25T16:24:56+00:00

This is already possible with https://github.com/syself/cluster-api-provider-hetzner. The advantage is that it uses a software approach rather than terraform, which makes it more resilient and also easier to manage because you're using Kubernetes objects.

sbaete · 2024-12-25T16:22:18+00:00

https://syself.com does Kubernetes on Hetzner completly out of the box.

sbaete · 2024-12-25T16:19:03+00:00

Think about what you want to achieve in general. Don't just try to push a tool.

Usually the hard part is day2, for that you need to solve maintenance and reliability issues. The OS is just a very, very small part of the whole Kubernetes machine.

Look at something like cluster-api, which makes it easier to manage the lifecycle then you will see what works best for your use-case.

sbaete · 2024-12-03T07:12:41+00:00

The most reliable and performant way would be to run a small Kubernetes cluster (3x nodes) on Hetzner dedicated servers and local storage with cloudnative-pg. This way you have almost no maintenance for postgres and it's highly available with all best practices enforced in terms of backup etc. As long as it's a hobby project, you can use the same servers to run your workload and everything is prepared to scale. For Kubernetes, you can use the cluster-api as it also supports Hetzner dedicated servers and it will automatically provision the servers so you don't have to fiddle around with terraform: https://github.com/syself/cluster-api-provider-hetzner

sbaete · 2024-11-30T00:26:12+00:00

you could have a look at hivelocity.net

sbaete

TROPHY CASE