The community-plugins repository is a place where members of the community can collaborate to develop, maintain, and share plugins. This initiative was originally driven by the need to separate plugin maintenance from the backstage/backstage core repository.

This repository is designed to provide plugin maintainers with tools and workflows to efficiently manage and publish Backstage plugins.

👉 Check out the Community Plugins documentation for a full list of all plugins in this repository, including ownership and package details.

Plugins created by the wider Backstage community are welcome to be published in the community-plugins repository. When you contribute a plugin to this repository, you agree to follow specific guidelines, including a standardized release process. This allows plugin owners to leverage established processes and the collective knowledge of the Backstage community-plugins community.

For those seeking full autonomy over their plugin's development and release lifecycle, self-hosting remains a supported and valid option. The decision to either contribute to the community repository or self-host will depend on whether you prefer to manage the development of the plugin independently or develop the plugin as part of a community-driven process. Both approaches are valued within the Backstage ecosystem and contribute to its growth.

Plugins that are key to the functionality and operation of Backstage will continue to reside in the backstage/backstage repository - ensuring the central components that underpin the platform are centrally managed and maintained.

If you're considering contributing a new plugin, start with the Contributing a New Plugin guide to understand whether community-plugins is the right fit and how the proposal process works. Once your proposal is accepted, follow the guidance in CONTRIBUTING.md to set up your workspace.

The community-plugins repository is formed by a set of workspaces. A workspace holds a plugin or a set of plugins based on a specific topic. For example, catalog, kubernetes, and TechDocs can be referred to as workspaces.

Each plugin belongs to a workspace and workspaces are portable enough to be moved to its own repository if desired. Each plugin workspace has its own changesets and isolated releases.

Plugins depend on other plugins via regular npm dependencies, regardless of whether the other plugins are core plugins, other plugins within the repository, or external plugins.

Although the community repository isn't technically a yarn workspace, it functions as a repository with multiple yarn workspaces, with each workspace possessing its unique .changesets directory.

Whenever a new changeset is introduced, a fresh "Version packages ($workspace_name)" PR is produced. Merging a Version packages PR will trigger the release of all the plugins in the workspaces (provided changesets have been added), and also update the CHANGELOG files.

A number of plugins that originally resided in backstage/backstage monorepo have moved to this backstage/community-plugins repository.