Last week we at Sidero Labs added deprecation notices to the READMEs of our two Cluster API (CAPI) providers: the bootstrap provider (CABPT) and the control plane provider (CACPPT).
The notices were accurate, but a README notice was the only thing most people saw, and a README change is not an announcement. That gap left the community to fill in the story themselves, and some of what got filled in is wrong. This post is the announcement we should have written, including the parts that might be a bit uncomfortable for us.
What is actually happening
Headline: we are not killing the Talos Linux Cluster API providers. We are ending Sidero's development and commercial support of them, and handing them to the people who have, in practice, been carrying them already. A community-driven migration of the providers to kubernetes-sigs is underway, in public, right now.
To be concrete about what changes and what doesn't:
- The repositories stay up, and the code stays open source.
- Existing support contracts that cover these providers are honored, unchanged.
- Sidero will keep providing hosting and continuous integration (CI) infrastructure for the projects until the providers complete their move to kubernetes-sigs.
- Sidero will no longer develop new features, and new Sidero support contracts won't cover the providers.
Why now?
Given Omni has been out for a few years, and we have continued to update the CAPI providers for new versions of CAPI and Talos - why stop now? Because we are a small company, with a smaller engineering team, and big ideas and goals. CAPI providers took a disproportionate amount of time for the use they received, and certainly compared to the revenue associated with them.
The key to success is to say no to things. We are trying.
Correcting the record
An often-shared (and incorrect) technical claim about the deprecation is that the commit which added the notice "also disabled the integration." It didn't. It disabled the integration tests.
Those end-to-end tests ran on Sidero's own cloud account, using Sidero's encrypted credentials, on Sidero's bill. The same commit removed those credential files, so the tests that depended on them stopped running. That is not breaking the integration on the way out. It's the first necessary step of decoupling the project from our infrastructure: a community contributor is already migrating the test suite to infrastructure that requires no Sidero credentials at all, which is exactly what an independently maintained project needs.
The part that we got wrong
The direction here is not new. Back in 2023 we wrote about why Omni doesn't use Cluster API: CAPI's model was replace-the-machine-to-change-it, while Talos Linux is built for API-driven, in-place management. We chose to invest in the tools that fit, namely Omni and our Terraform provider.
But that same 2023 post also promised that our providers would "continue to be maintained and improved". That promise is the part we failed, not by walking away, but by going ambiguous. We kept cutting releases and reviewing some contributions, but no pull request ever got a final decision. Four different people independently submitted CAPI version upgrades because we never said which one would land, or whether any would. If you contributed during that time, you were investing in a project whose direction we had already decided and never wrote down, and we’re sorry for it.
The honest lesson is that we were signaling "maintained" through our actions while planning "community-owned" in our heads, and never wrote the second part down. We're fixing that now.
The handoff
The good news, and the reason this post can be more than an apology, is that the community these providers need already exists. The contributors who kept CAPI version support moving this year did it in public, with code. These become community-owned projects in fact, not just in label, and our job is to hand over the keys properly. Four commitments:
- A clean queue. Every open pull request on both repos gets an answer: merged, closed with a reason, or explicitly handed to the incoming maintainers. Nobody should inherit a year of silence. This starts now.
- Commit and release rights. Maintainership is open to the contributors who have been doing the work. If that's you, raise your hand on the migration tracking issue. The repos stay where they are until the migration completes so nothing breaks, and maintainers will be announced on the repositories themselves as they accept.
- A long-term home. Our goal is to move the providers to a vendor-neutral home in the Kubernetes organization, and that's the migration already underway (see the migration tracking issue). It's real work (contributor license agreements, repository restructuring) so we can't promise a date. But this is an active effort, not an aspiration.
- Continuity in the meantime. Until the providers move to the Kubernetes org, hosting and CI stay on us so nothing breaks mid-handoff.
What this means for you
If you run Talos Linux clusters with the CAPI providers today, nothing stops working. Your clusters are fine, the providers are open source, and maintenance is passing to people who run them in production themselves. If you have a Sidero support contract that covers the providers, it still does.
If you're choosing tooling now: our recommendation and our investment is Omni for managed cluster lifecycle, and the Terraform provider for declarative infrastructure workflows. That's where our engineering goes, and we've written about how full lifecycle management works without Cluster API if you want the technical case.
And to say the quiet part loudly, because several people in last week's threads raised it: Talos Linux is open source and stays open source, forever. Our commercial products (management, enterprise builds, support) are built around Talos Linux, not by closing it. If our communication last week made anyone doubt that, that's on our communication, and I'd rather over-say it than leave it implied.
What happens next
All of this happens in the open, because operating in the open is the habit we're correcting. Over the coming weeks the open pull requests on both repositories will get answers — you'll see it in the queues, not in a press release. Maintainers will be announced on the repositories as they accept. Progress on the Kubernetes-org move gets posted as it happens, including the boring parts.
If you've contributed to these providers and been met with silence: I'm sorry, and your work is being read now. If you want to help maintain them, say so on the migration tracking issue or find us in the Talos Linux community Slack. And if we go quiet again, call us on it. This post is a commitment, and commitments are checkable.
Justin Garrison
Hannah Augur