RBG

What it is

RBG (Role-Based Group) is a Kubernetes CRD-based API for orchestrating distributed inference workloads that don't fit the standard Deployment/StatefulSet model. Modern LLM serving increasingly splits work across roles — a prefill node, a decode node, a router, a KV-cache server — that need to discover each other, scale independently, and stay coordinated as a single logical unit. RBG models this as a "group" of roles, handling service discovery and lifecycle management between them natively, instead of forcing you to hand-roll sidecars, headless services, and init-container discovery scripts for every new inference architecture (disaggregated prefill/decode, PD-mesh, speculative decoding pipelines, etc.).

If you're running single-replica model servers behind a Deployment, you don't need this. If you're running multi-role, multi-node inference topologies, RBG is solving a real gap in vanilla Kubernetes primitives.

Who builds it and why

28 contributors, active commit history through mid-2026. This is a project built by people running distributed inference in production, not a research prototype — the "multi-role collaboration" framing in the API design suggests direct experience with the operational pain of disaggregated serving architectures (separate prefill/decode pools, KV-cache routing) that have become common with large context windows and high-throughput LLM serving. Founding org and governance details are not publicly available — no CNCF sandbox/incubation status listed, so treat this as an independent open-source project rather than a foundation-backed one for now.

Production readiness signal

• 254 GitHub stars — small community, early-stage adoption. Not a signal of instability by itself, but it means fewer battle-tested deployment patterns to reference and a thinner pool of public troubleshooting history.
• 28 contributors — healthy for a project this size; suggests it's not a single-maintainer risk.
• Latest release v0.7.0 — pre-1.0. Expect API changes between minor versions. Do not assume CRD schema stability across upgrades.
• Active commits through 2026-06-29 — actively maintained, not abandoned.
• CNCF maturity: not publicly available — no foundation backing to fall back on for governance, security process, or long-term maintenance guarantees. That risk sits entirely with the maintainers and your team's ability to read the source when something breaks.

Bottom line: this looks like a legitimate, actively developed project still in its early maturity curve. Fine for teams that can tolerate API churn and want to be close to the bleeding edge of inference orchestration. Not yet in "boring infrastructure" territory.

Who should use this

• Platform teams running disaggregated LLM inference (separate prefill/decode/router roles) on Kubernetes and currently maintaining custom glue code for service discovery between roles.
• Teams already comfortable operating CRDs and controllers who want a purpose-built abstraction instead of extending StatefulSets/Deployments themselves.
• Organizations experimenting with novel multi-role inference topologies who need the API to be flexible rather than opinionated.

Who should NOT use this

• Teams running single-model, single-role inference (one container, N replicas, load-balanced) — a Deployment + HPA does this fine, RBG adds complexity you don't need.
• Risk-averse production environments that require CNCF-graduated tooling or vendor support contracts — there's no foundation backing and no visible commercial support option here.
• Teams without in-house Kubernetes controller/CRD expertise — pre-1.0 software with a small contributor base means you'll likely need to read source or file issues, not lean on Stack Overflow.
• Anyone needing strict API stability guarantees for long-lived production systems — v0.7.0 means breaking changes are still likely before 1.0.

Alternatives

• KServe / KServe ModelMesh — more mature, CNCF-adjacent inference serving on Kubernetes, but weaker native support for multi-role disaggregated topologies.
• Ray Serve (on KubeRay) — handles distributed multi-actor serving with a mature scheduler, at the cost of adopting the Ray runtime instead of staying Kubernetes-native.
• Hand-rolled StatefulSets + headless Services — the status quo RBG is replacing; more control, significantly more operational overhead per new topology.

Pricing

Fully open source, Apache-2.0 licensed. No paid tier, no commercial entity identified. You run it, you maintain it, you fix it when it breaks.