Sidero has stopped actively developing its Talos Cluster API providers, which is concerning for anyone using them to create and manage Kubernetes clusters. Is anyone currently relying on these providers in production, and do you think the community will maintain them long term? I'm especially interested in the risks of continuing with them, possible alternatives, and whether moving to Omni or another Cluster API-based approach makes sense.
5 Answers
For an internal Kubernetes-as-a-service project, Cluster API is still a reasonable foundation, but I would avoid tying the whole design to one provider. Alternatives include using a different infrastructure provider, evaluating projects such as Gardener or Kamaji, or running Talos workers with an independently managed control plane. The best choice depends on whether bare-metal support, automated upgrades, or control-plane management is the primary requirement.
Sidero’s explanation is that Cluster API and Talos solve somewhat different problems. Cluster API is primarily designed around provisioning clusters on cloud or virtualized infrastructure, while Talos has increasingly focused on bare-metal operations and full lifecycle management. Their newer platform avoids needing a separate management cluster and supports features such as in-place upgrades, which were difficult to fit into the older provider model.
The separate management cluster has always felt like one of the more awkward parts of a Cluster API setup, especially for smaller internal platforms.
Omni appears to be the strategic direction because it integrates Sidero’s tooling without depending on a separate Cluster API management cluster. Its Terraform support may be useful for infrastructure-as-code workflows, but switching should be evaluated carefully if its upgrade model or operational assumptions do not fit your environment. A provider being officially recommended does not automatically make it the right replacement for every deployment.
There are practical reasons to be cautious. The provider was not commercially successful enough for Sidero to keep funding it, and maintaining compatibility with both Talos and Cluster API would require substantial effort. Community forks may appear, but I would not assume they will provide dependable long-term support without a clear maintainer and an active user base.
The providers are being transferred to the Kubernetes community, so they may continue under community ownership. That said, transfer does not guarantee active maintenance. Future compatibility work, especially around upcoming Cluster API changes, will depend on whether enough users and companies are willing to contribute time or funding.
That seems like the key distinction: the code may remain available, but organizations depending on it should still plan for ownership, support, and upgrade work themselves.
Some teams are also maintaining public forks of the Talos providers, so it is worth checking their activity and release process before deciding whether to migrate immediately.