Kwirth Plugins

What is a plugin?

A Kwirth plugin is a self-contained bundle that adds a new channel tab to the Kwirth front-end and, optionally, a backend component that runs alongside Kwirth's core. Plugins follow the same lifecycle as built-in channels: the user selects a cluster, opens a tab, and the plugin takes over rendering and data fetching.

Plugins are packaged as a .tgz file containing a CJS backend bundle (back.js), an IIFE frontend bundle (front.js), and a package.json manifest. Once installed, Kwirth hot-reloads them — no container restart required.

Autonomous plugins

Not every plugin observes cluster resources. An autonomous plugin needs nothing from the cluster — no namespace, pod or container — so it opens directly, without asking the user to pick a scope. It is a regular plugin in every other respect.

This is what lets you embed a standalone JavaScript application — a game, a dashboard, a small tool, an external widget — as a Kwirth channel, and have it inherit the framework's services for free: authentication, RBAC, persistence (ConfigMaps / Secrets / PVC / files), the real-time WebSocket, providers, theming and notifications. Build the app once; ship it as a channel and let Kwirth handle sign-in, permissions and state.

A plugin declares itself autonomous by setting cluster: false and resourced: false in its back-channel data — its only view becomes none, and Kwirth starts it once with no resource selection.

Pluviders: a plugin that also publishes

Some plugins run a back end of their own, always started, that produces genuinely valuable information — proactive alerts raised after investigating an incident, log messages already filtered down to what matters, an enriched picture of external traffic. Until now that information could only reach one place: that plugin's own front end.

A pluvider is a plugin that also publishes what it produces in-process, so any other plugin in the same Kwirth can subscribe to it — exactly the way channels already subscribe to the events or metrics providers. It is not a provider packaged next to a plugin: it is the same class, the same instance and the same information, reaching one more door.

Producers are addressed with a plugin: prefix (plugin:agora) and consumed with no new API at all — a channel subscribes to a pluvider exactly as it subscribes to a provider. The dependency is soft: if the producing plugin is not installed, the consumer still starts and still works.

Available plugins

Plugin interface

Every backend plugin must implement the IPlugin interface exported from @kwirthmagnify/kwirth-common-back:

Build your own plugin

Plugins follow a simple project structure. The backend compiles to CJS (dist/back.js), the frontend to an IIFE (dist/front.js) that registers on window.__kwirth_plugins__. Both are bundled with esbuild.

plugins/my-plugin/
  src/
    back/index.ts     ← implements IPlugin
    front/index.tsx   ← registers on window.__kwirth_plugins__['my-plugin']
  build.mjs           ← esbuild script
  package.json        ← includes id, displayName, version, description

The frontend bundle receives backendUrl and accessString as props so it can make authenticated API calls without importing from Kwirth core:

// src/front/index.tsx
import MyPluginPanel from './MyPluginPanel'
window.__kwirth_plugins__ = window.__kwirth_plugins__ ?? {}
window.__kwirth_plugins__['my-plugin'] = MyPluginPanel

// Props your component receives:
// { backendUrl: string, accessString: string, clusterName: string }

See the echo plugin in plugins/echo/ for a complete working example, and the full API reference in the developer docs.