Skip to content
Brokkr

Welcome to Brokkr

Brokkr is a control plane for Kubernetes that lets you dynamically create and manage applications across clusters. Define what you need, fire it off, and the controller loop takes care of the rest — your applications get created, configured, and reconciled automatically.

Use Cases

Section titled “Use Cases”

While tools like FluxCD and ArgoCD excel at GitOps-based state management, Brokkr takes a different approach — it’s built for dynamic, on-demand application lifecycle management rather than static manifest synchronization.

On-Demand Application Provisioning

Section titled “On-Demand Application Provisioning”

A customer needs a new service spun up? A new tenant needs their own stack? Just create the deployment through Brokkr and it flows through the controller loop to your clusters. No manual kubectl, no CI round-trip. Brokkr’s generators and templates let external systems — CI/CD pipelines, customer provisioning systems, or internal tools — programmatically create Kubernetes resources through an API, without touching git repos or manifest files.

Dynamic Service Management

Section titled “Dynamic Service Management”

As your requirements change, Brokkr lets you define, reconfigure, and scale the services running across your clusters. Templates let you stamp out standardized configurations, and every agent runs its own reconciliation loop, continuously pulling its target state from the broker and applying it to its cluster. Resources drift? The agent corrects it. New deployment object pushed? The agent picks it up on the next poll. This suits environments where the set of applications changes frequently — multi-tenant platforms, on-demand infrastructure, and systems where what needs to run is determined at runtime, not at commit time.

Multi-Cluster Orchestration

Section titled “Multi-Cluster Orchestration”

Manage applications across multiple Kubernetes clusters from a single control plane. Target specific clusters with labels, push updates to all of them at once, and let each agent independently reconcile its own state. Brokkr handles the coordination so you can focus on what to deploy, not where and how.

Explore Brokkr

Section titled “Explore Brokkr”

When to Use Brokkr — and When Not To

Section titled “When to Use Brokkr — and When Not To”

Brokkr is a good fit when:

  • What needs to run is decided at runtime, by an API call — multi-tenant platforms, on-demand provisioning from CI or an internal portal, or any system that programmatically creates workloads.
  • You’re pushing the same workloads to many clusters and want label/annotation-based targeting from one control plane.
  • Your agents live in restricted or firewalled networks — the pull model means each agent needs only outbound connectivity to the broker, and an offline agent catches up when it reconnects.

Brokkr is probably not the right tool when:

  • You have a known, static set of manifests you’re happy syncing from a Git repository. Tools like ArgoCD and Flux are purpose-built for that and will fit better.
  • You want Git to be the source of truth for desired state — with pull-request review and Git history of every change. Brokkr’s source of truth is the broker (an API plus its database), so you trade Git’s review/history workflow for programmatic, runtime-driven control. Brokkr records changes in an audit log rather than in Git.

Working with Brokkr Day to Day

Section titled “Working with Brokkr Day to Day”

Once Brokkr is running, the recommended everyday workflow is the brokkr CLI: point it at a folder of manifests and run brokkr apply — it’s idempotent and CI-safe. A generator PAK applies for its own generator; the admin PAK adds --generator <name> to say which generator owns the stack. For programmatic use, the SDKs (Rust, Python, TypeScript) expose the same operations. The raw REST API sits underneath both.

For watching rather than changing, the broker also serves a read-only Operator Console at its own root URL — a browser view of the fleet, deployments, telemetry, work orders, and broker health that needs no credential of its own. Because it authenticates itself, anyone who can reach the broker’s port can read it: network reach is the console’s only boundary, which is worth knowing before you expose that port. See the Security Model.