Kuberik: Open-Source Kubernetes Progressive Delivery [N/A Stars]

What Is Kuberik?

Kuberik is a Kubernetes-native progressive delivery system built by the Kuberik project, and it is one of the best Kubernetes Progressive Delivery tools for platform teams and DevOps engineers running Flux on Kubernetes. It ships with a CLI plus six controllers across rollout, dashboard, Datadog, Prometheus, OpenKruise, and environment integrations, and it manages Rollout, RolloutGate, HealthCheck, and RolloutSchedule resources in-cluster.

Kuberik is designed for teams that want declarative release promotion instead of a pipeline server. The project’s own positioning is explicit: it fills the gap that Flux and ArgoCD leave open by moving deployment logic into Kubernetes CRDs and controller reconciliation, which keeps release state inside the cluster and out of Jenkins, Tekton, or custom DAGs.

Quick Overview

Who Should Use Kuberik?

• Platform teams running GitOps on Kubernetes who need staged promotion across dev, staging, and production without standing up a separate pipeline engine.
• SREs and release engineers who want health checks, deployment gates, and bake time encoded as resources instead of hidden in shell scripts.
• Teams using Flux, Datadog, Prometheus, or OpenKruise that need those signals to influence rollout promotion through native controller reconciliation.
• Small DevOps teams that need serious rollout control but do not want to maintain a large CI/CD control plane.

Not ideal for:

• Non-Kubernetes services that deploy to VMs, serverless platforms, or bare metal without Kubernetes CRDs.
• Teams that want a single imperative deploy command and do not want to operate extra controllers in the cluster.
• Orgs that do not use GitOps and do not want release promotion tied to Kubernetes reconciliation.

Key Features of Kuberik

• CRD-native progressive delivery — Kuberik models releases as Rollout, RolloutGate, HealthCheck, and RolloutSchedule objects. That gives you typed, inspectable release state with kubectl get and kubectl describe instead of opaque pipeline logs.
• Flux-aware promotion — Kuberik reads Flux ImagePolicy objects to discover candidate releases, then patches Flux source and kustomization resources to promote them. That makes it a natural fit for teams already using Flux as the GitOps engine.
• Multi-stage pipelines — You can promote changes across environments with explicit dependencies between stages. This is the right abstraction when production needs to wait for staging bake time, automated checks, and human approval.
• Gate-driven releases — Deployment gates can be scheduled, manually approved, or driven by custom conditions. That lets release managers coordinate freeze windows, regional launches, or traffic-shift policies without rewriting the controller.
• Health signal adapters — Datadog, Prometheus, OpenKruise, GitHub Deployments, and custom controllers can publish rollout health independently. Kuberik just consumes the resulting HealthCheck and RolloutGate resources.
• Canary and bake-time control — The rollout controller supports gradual exposure before full promotion, which is the correct primitive for validating error budgets, latency regressions, or bad config pushes.
• Day-2 tooling included — The repo ships a CLI, dashboard, structured controller logs, and a GitHub Action in the same release cycle as the controllers. That matters when your production workflow needs a real operator path, not just YAML.

Kuberik vs Alternatives

Pick Argo Rollouts if your org already standardizes on Argo and you want a widely known rollout controller with established patterns. Pick Flagger if your release strategy is centered on service-mesh or ingress traffic shifting rather than Kuberik’s CRD-first gate model.

Pick Flux CD if you only need GitOps reconciliation and do not need staged promotion logic. If your workflow is broader than rollout orchestration, Kuberik pairs well with djevops for broader DevOps automation and with OpenTrace when you need tracing evidence during rollout validation; teams browsing adjacent tooling can also browse all DevOps Automation tools.

How Kuberik Works

Kuberik works by pushing release logic into Kubernetes reconciliation loops. The core rollout-controller watches custom resources, evaluates gate and health state, and writes status back into the cluster so promotion becomes a declarative state machine instead of a CI job.

The data model is the real design choice here. A rollout declares stages, gates express whether progression is allowed, and health checks supply external evidence from systems like Datadog or Prometheus; Kuberik then reconciles those signals into a promotion decision. That separation keeps observability, approval policy, and release orchestration decoupled, which is exactly what you want when the cluster is already the source of truth.

Kuberik also treats Flux as a first-class dependency rather than a competitor. It reads Flux ImagePolicy resources to detect new versions and patches Flux source or kustomization objects to advance the deployment, which keeps image selection and rollout promotion inside GitOps primitives instead of bespoke scripts.

kuberik install --all
kubectl apply -f examples/canary.yaml
kubectl get rollout -A

The first command installs the CLI-facing release stack, the second applies a rollout manifest, and the third shows the controller state after reconciliation starts. Expect the rollout object to remain pending until gates, checks, and bake periods pass; if you are using the integrations, external systems will update HealthCheck and RolloutGate resources as their own signals change.

Pros and Cons of Kuberik

Pros:

• No central pipeline server — rollout logic runs in-cluster, so you do not need to keep Jenkins, Tekton, or a workflow engine alive just to promote releases.
• Native GitOps fit — Flux integration means Kuberik works with the release discovery and sync model many Kubernetes teams already use.
• Fine-grained promotion controls — stages, gates, schedules, and health checks provide explicit control over when traffic moves forward.
• Good operational visibility — the dashboard, structured logs, and CRD status fields make the current release state easy to inspect with standard Kubernetes tooling.
• Integration-friendly architecture — Datadog, Prometheus, OpenKruise, and GitHub Deployments can all feed the same rollout engine without hard-coding every signal into one binary.

Cons:

• Only makes sense on Kubernetes — if your platform is not Kubernetes-first, Kuberik adds abstraction without solving the real problem.
• More moving parts than a simple deploy script — controllers, CRDs, and optional integrations are operationally heavier than kubectl apply.
• Requires GitOps discipline — the best experience comes when Flux is already your release source of truth.
• External signals add debugging surface — when a gate blocks promotion, you may need to inspect Datadog, Prometheus, or custom controllers to find the root cause.
• Not the smallest footprint option — teams that only need basic canary traffic shifting may find Argo Rollouts or Flagger simpler.

Getting Started with Kuberik

brew install kuberik/tap/kuberik
kuberik install --all
kuberik version

That installs the CLI, deploys the core controller stack plus integrations, and confirms the binary is on your path. After that, apply one of the example rollout manifests or follow the repo docs to wire Kuberik into an existing Flux setup; the default install creates the kuberik-system namespace unless you override it.

If you only want the core controller, use kuberik install instead of --all, then add Datadog, Prometheus, or OpenKruise controllers only when your rollout policy actually depends on those signals. For Helm-based installs, the repo supports both a GitHub Pages chart repo and an OCI chart reference, which is useful when your cluster bootstrap is already standardized on Helm.

Verdict

Kuberik is the strongest option for Kubernetes GitOps teams that want progressive delivery without a central pipeline. Its main advantage is CRD-native promotion with Flux-aware release discovery and multi-signal gates; the caveat is that you are now operating several controllers in-cluster. If your organization is Kubernetes-first, Kuberik is worth standardizing on.