Flagger

Visit Website

Introduction

Flagger is a progressive delivery tool that automates the release process for applications on Kubernetes. It reduces the risk of a new version by gradually shifting traffic to it while measuring metrics and running conformance tests, then promoting or rolling back automatically.

Unlike tools that replace the Deployment object, Flagger works alongside it. You keep a normal Deployment and, optionally, a horizontal pod autoscaler, and create a Canary resource that points at it. Flagger then creates the extra objects it needs, such as primary and canary Deployments, ClusterIP services and mesh or ingress routes, and drives the analysis from there.

The README lists three deployment strategies: canary releases, A/B testing and blue-green mirroring. Canary moves traffic by weight; A/B testing routes users by HTTP headers or cookies, which suits front-end changes where a user should stay on one version; blue-green runs conformance tests against the new version before switching.

Analysis uses metric checks and webhooks. Built-in checks cover request success rate and latency from Prometheus, and custom metric templates can query other providers. Webhooks let Flagger call a load tester or acceptance tests during the rollout, so a canary can be exercised with synthetic traffic even when real traffic is low.

In the quality loop, Flagger belongs at the release and production stages. It is part of the Flux family and fits GitOps workflows naturally, though it also works with plain kubectl. It integrates with several service meshes and ingress controllers, and can send notifications to chat tools when a rollout advances or fails.

The source code is at fluxcd/flagger on GitHub under the Apache-2.0 licence, with about 5,400 stars; the most recent commit was on 1 September 2026.

Start with conservative analysis settings, such as small traffic steps and generous thresholds, then tighten them once you trust the metrics.

Features

1. Canary releases: Weighted traffic shifting with configurable step size, interval and maximum weight.
2. A/B testing: Header- or cookie-based routing to keep specific users on the canary.
3. Blue-green: Run conformance tests on the new version before switching all traffic.
4. Metric analysis: Success-rate and latency checks, plus custom metric templates.
5. Webhooks: Call load tests, acceptance tests or manual gates during analysis.
6. Automatic rollback: Failed checks beyond a threshold roll traffic back to the primary.
7. Mesh and ingress support: Works with several service meshes and ingress controllers for routing.
8. HPA awareness: Scales canary and primary workloads with the autoscaler.
9. Alerting: Notifications to chat tools on promotion or failure.
10. GitOps native: Declarative Canary resources that live in Git with the rest of the app.

Pros

1. Keeps your Deployment: No need to rewrite workloads into a new resource type.
2. Built-in test hooks: Webhooks make it easy to combine canaries with automated tests.
3. Free to use: Open source under the Apache-2.0 licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 1 September 2026.
5. Community: About 5,400 GitHub stars.

Cons

1. Kubernetes only: Not useful outside Kubernetes clusters.
2. Routing prerequisites: Most strategies need a supported mesh or ingress controller.
3. Generated objects: Flagger creates primary and canary resources, which can confuse people reading the cluster.
4. Metric quality: Bad thresholds lead to either noisy rollbacks or missed regressions.

Usage and Links (Example)

A minimal Canary resource:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata: { name: podinfo, namespace: test }
spec:
  targetRef: { apiVersion: apps/v1, kind: Deployment, name: podinfo }
  service: { port: 9898 }
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange: { min: 99 }
        interval: 1m
      - name: request-duration
        thresholdRange: { max: 500 }
        interval: 1m

Practical tips:

1. Add a load-test webhook so analysis has traffic even at quiet times.
2. Keep threshold low enough that a real regression rolls back quickly.
3. Use A/B mode for UI changes so users do not flip between versions.

Resources:

• Flagger website
• GitHub repository

Pricing

Flagger is free and open source under the Apache-2.0 licence.

Recommended for?

1. Flux and GitOps users who want progressive delivery with the same toolkit.
2. Teams with a service mesh or supported ingress for traffic shifting.
3. Services with clear SLOs for success rate and latency.
4. Not ideal when you need releases outside Kubernetes.

Conclusion

Flagger automates the careful parts of a Kubernetes release: small traffic slices, metric checks, test hooks and rollback. Because it wraps your existing Deployment, adoption is less invasive than switching resource types.

Choose it if you live in the Flux and GitOps world or prefer an operator that leaves your manifests intact; pair it with load-test webhooks and honest SLO thresholds.

On CheckOps, Flagger is filed under the Release & CI gates and Production monitoring & observability stages. Related tools listed here include Argo Rollouts, LaunchDarkly, Flagsmith, Prometheus, K6 and Chaos Mesh. When comparing them, weigh the licence, the languages and platforms each supports, whether it is self-hosted or managed, and how cleanly it slots into your existing CI pipeline. Details on this page were checked against the official website, documentation and repository on 11 November 2026.