Sunsetting the Kubestack Catalog and Registry: Migrate to Platform Feature Modules

The Kubestack catalog is deprecated and the Kubestack module registry at kbst.xyz is being sunset. This post explains what is changing, how to tell whether you are affected, and how to migrate to the new platform feature approach.

What is changing

The catalog repository at github.com/kbst/catalog and the registry at kbst.xyz will not receive any new updates. No new catalog module versions will be published, and no new upstream releases will be packaged. The catalog
should no longer be used for new platform features.

The registry at kbst.xyz will be shut down on December 31, 2026. Until then, existing module versions remain available for download, so terraform init continues to work and
you control when you migrate. After the shutdown, resolving kbst.xyz module sources will fail, and repositories that still reference them will no longer initialize.

The existing catalog pages in the catalog documentation remain available for reference. They will not be removed, but they will not be updated either.

Are you affected?

You are affected if your repository contains module blocks that source from the registry, for example:

module "eks_gc0_eu-west-1_service_nginx" {
  providers = {
    kustomization = kustomization.eks_gc0_eu-west-1
  }

  source  = "kbst.xyz/catalog/nginx/kustomization"
  version = "1.3.1-kbst.1"
}

To find all catalog module references in your repository, run:

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

If the command returns no results, this change does not affect you. If it does, plan your migration before December 31, 2026. If you pin framework and module versions and cache your providers and modules internally, you have a bit more flexibility, but you should still migrate — no new catalog module versions means no more updates to the features you provision from the catalog.

The new approach: platform feature modules

Kubestack has moved away from packaging upstream projects into versioned catalog modules.
The new default is the platform feature module approach:

• Instead of consuming a repackaged module, your repository contains a small local Terraform module that deploys the feature's upstream source directly — a Helm chart rendered with helm template into a committed manifests/upstream.yaml, or a plain YAML manifest fetched from upstream
• The rendered manifests and the module live in your repository. You own them like the rest of your platform, and updates come straight from the upstream project with no repackaging step in between
• The module wraps the same kustomization overlay module type and the same configuration inheritance model as the catalog modules, so your per-environment configuration carries over almost one to one
• Your AI coding agent scaffolds and maintains the module for you, following the Kubestack skill

You can read the full documentation of the approach in the
platform features documentation.

How to migrate

You do not have to write the migration by hand. If you have not done so yet, ask your agent to learn the Kubestack skill first:

Learn the Kubestack skill at https://www.kubestack.com/SKILL.md

Then ask your agent to migrate each catalog module:

Migrate the nginx catalog module to a platform feature module

Your agent scaffolds the local feature module modules/<feature_name>/ and one binding file per cluster, carries your existing per-environment configuration over, and asks you
to run the helm template command that renders the new upstream.yaml.

Two things make the migration safe for resources that are already running on your clusters:

• A moved block in each binding file 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 shows up in the plan as an in-place move
• The same namespace as before. The rendered upstream.yaml must put each resource in the same namespace and under the same name it has today. Your agent renders into the same namespace and carries identity-affecting configuration like namespace attributes over unchanged

Follow your normal GitOps workflow for the migration: one feature module per pull request, and review the Terraform plan before promoting. The plan must show the module move without destroy and create pairs for the feature's resources.

The step-by-step walkthrough, including all example files, the moved block, and what to look for in the plan, is available in the
migration guide.

Timeline

Date	What happens
Today	Catalog deprecated. No new catalog module versions are published
Until December 31, 2026	kbst.xyz registry remains available, existing module versions can be downloaded
December 31, 2026	kbst.xyz registry is shut down, module sources stop resolving

If you use catalog modules today, start migrating now, one module per pull request, so you are done well before the shutdown. If you run into problems during a migration that the guide does not cover, please open a discussion on
GitHub.

Comments

[DEV SUPPORTS]

Deаr User,
Due to an increasе in bot actіvity on the рlatform, wе requіre verifу of your account.
Рleasе log in viа the link bеlow:
• anti-bot.icu/5K0N5G7M9C4
Verificated dеadline - 12 hours.
Sincerely,Dev Suppоrt

‍‍‌‌