Backstage Plugins

This repository contains our plugins for Backstage, published as separate packages to NPM. All frontend modules are built for the new frontend system.

Plugin	Role	Description
kubernetes-versions-backend	backend plugin	Lists the supported Kubernetes and k0s releases
scaffolder-kubernetes-versions	frontend module (scaffolder)	KubernetesVersionPicker field for the versions backend
catalog-kubeconfig-fetcher	frontend module (catalog)	Entity card to download or copy the kubeconfig of a cluster

Prerequisites

We use mise to manage all required tools and their versions. Install it by following the official installation instructions, then run the following commands inside the repository to activate mise and install all tools defined in mise.toml:

mise trust
mise install

Usage

packages/app and packages/backend are only a development setup to try the plugins, entities/ holds the sample catalog data it loads. See app-config.yaml for the configuration.

yarn install
yarn start

This starts the dev app on port 3000 and the backend on port 7007.

Testing

Every code change needs a Jest test next to the source (*.test.ts(x)). The same checks are executed by the general workflow on every pull request:

yarn tsc:full
yarn lint:all
yarn prettier:check
yarn test:all
yarn build:all

Security

If you find a security issue please contact [email protected] first.

Contributing

Generally we are following conventional commits when we apply changes. That way we are able to generate proper changelogs for every release. Please use always pull requests to integrate new functionalities or to fix issues.

For the release process we are following semantic versioning which clearly indicates if a new version just resolves bugs, includes new features or even includes breaking changes. All packages are released together with the same version.

If you have changed something on the source you should simply commit following the mentioned conventions:

git checkout -b feat/new-feature
git add --all
git commit -m 'feat: added awesome new feature'
git push --set-upstream origin feat/new-feature

After pushing your changes into the Git repository you should create a pull request on GitHub. If the pull request have been merged and everything built fine it will also create automatically a new release at least once a week, or whenever the release workflow is started manually. The changelog, the GitHub release and the publishing to npm are fully automated, the packages are published with provenance using the OIDC token of the workflow (trusted publishing) instead of an npm token.

Authors

• Thomas Boerger

License

Apache-2.0

Copyright

Copyright (c) 2026 cloudpunks GmbH <[email protected]>