Kubestack sunsets catalog and kbst.xyz module registry; users must migrate by December 31, 2026

Kubestack is retiring both its catalog and the module registry that serves it. According to an announcement published on dev.to, the catalog repository on GitHub and the registry at kbst.xyz are deprecated effective immediately, and the registry will be shut down entirely on December 31, 2026. Anyone provisioning platform features from the catalog needs to migrate to a new pattern, which Kubestack calls platform feature modules, before existing module sources stop resolving.

What is changing

The catalog repository and the kbst.xyz registry will no longer publish new module versions, and no further upstream releases will be packaged for them. The catalog is explicitly no longer the recommended way to add new platform features.

The registry keeps serving the versions that already exist until the end of 2026, so terraform init continues to work during the transition and teams control their own migration timing. After the shutdown date, resolving any kbst.xyz module source will fail, and repositories that still reference the registry will no longer initialize. The existing catalog documentation pages remain online for reference but will not be updated.

How to check whether you are affected

The announcement describes the affected case precisely: a repository containing module blocks whose source points at the registry, for example a nginx module sourced from kbst.xyz/catalog/nginx/kustomization at version 1.3.1-kbst.1.

A single grep finds every reference:

grep -rn "kbst.xyz/catalog" *.tf

If the search comes back empty, the change does not affect you. Teams that pin framework and module versions and cache providers and modules internally have somewhat more breathing room, but the announcement still advises migrating: with no new catalog module versions being published, features provisioned from the catalog stop receiving updates of any kind.

The replacement: platform feature modules

Kubestack has moved away from repackaging upstream projects into versioned catalog modules. Under the new default, a repository holds a small local Terraform module that deploys the feature's upstream source directly — either a Helm chart rendered with helm template into a committed manifests/upstream.yaml, or a plain YAML manifest fetched from upstream.

Both the rendered manifests and the module live in the user's repository, are owned like the rest of the platform, and receive updates straight from upstream with no repackaging step in between. The module still wraps the same kustomization overlay module type and the same configuration inheritance model as the catalog modules, so per-environment configuration carries over almost one to one. Notably, Kubestack expects an AI coding agent to scaffold and maintain these modules, following a published Kubestack skill.

Migrating without recreating resources

The migration is designed to be agent-driven: users are instructed to have their agent learn the Kubestack skill first, then ask it to migrate each catalog module. The agent scaffolds the local module under modules/<feature_name>/, creates one binding file per cluster, carries over the existing per-environment configuration, and asks the user to run the helm template command that produces the new upstream.yaml.

Two details keep the migration safe for resources already running on clusters. First, each binding file includes a moved block that adopts the catalog module's Terraform state. Without it, the changed module address would cause Terraform to destroy and recreate every resource of the feature; with it, the migration appears in the plan as an in-place move. Second, the rendered upstream.yaml must keep each resource in its existing namespace under its existing name, and identity-affecting configuration is carried over unchanged.

Kubestack recommends following the normal GitOps workflow: one feature module per pull request, with the Terraform plan reviewed before promotion. A correct plan shows the module move without any destroy-and-create pairs for that feature's resources. A step-by-step migration guide with example files is available, and problems it does not cover should be raised as GitHub discussions.

Why it matters

The deadline is hard: once kbst.xyz goes dark, terraform init breaks for any repository still pointing at it, which can halt pipelines and block fresh clones of affected repos. Even teams that escape the immediate breakage through pinned versions and internal caches are left on frozen features with no upstream fixes or security updates. The sunset is also a snapshot of where infrastructure tooling is heading — away from curated, repackaged module catalogs toward vendoring upstream sources directly into your own repository, with AI agents handling the scaffolding and maintenance.