Flagger

Flagger is a self-hosted Kubernetes operator that automates progressive delivery for applications running on Kubernetes. It gradually shifts traffic to a new version while checking release measures such as HTTP or gRPC request success rate and latency. Supported strategies include canary releases, A/B testing and blue/green deployments. Routing uses an ingress controller or a service mesh compatible with the Kubernetes Gateway API. Built-in checks cover HTTP request success rate and request duration; teams can add custom metrics and webhooks for acceptance tests, load tests or other validation. Release analysis can query systems including Prometheus, Datadog, CloudWatch, New Relic, Graphite, Dynatrace, InfluxDB and Google Cloud Monitoring. If SLO analysis detects a performance drop, Flagger automatically rolls back the release. Manual controls can approve, pause or resume deployments, and notifications can go to Slack, Microsoft Teams, Discord or Rocket. Flagger uses Kubernetes custom resources and works with Kubernetes-focused CI/CD solutions. It can also be used with Flux for GitOps canary pipelines. The project is free and licensed under Apache 2.0.

Flagger combines gradual traffic shifting, metric checks and rollback for Kubernetes releases. Teams should account for its self-hosted deployment and compatible routing requirements.

Flagger suits teams running applications on Kubernetes that want automated rollout analysis and rollback. It is also relevant to teams using Kubernetes-compatible CI/CD or Flux-based GitOps pipelines.

Flagger is a self-hosted Kubernetes operator for progressive application delivery. It suits engineering teams already running Kubernetes that want releases governed by traffic, service metrics, and explicit approval points. Its value is concentrated in automated, health-aware rollout control; organizations without the required Kubernetes routing stack should choose another approach.

Overview

Flagger moves production traffic toward a new application version in stages while evaluating its behavior. When service-level-objective analysis identifies a performance decline, it can reverse the rollout automatically instead of leaving an unhealthy version fully exposed. That makes it a strong safety layer for teams that can express release health in measurable terms, but operating it remains the team's responsibility because deployment is self-hosted.

The project started at Weaveworks in 2018, became a Cloud Native Computing Foundation project in 2020, and is now a graduated CNCF project in the Flux family. Apache 2.0 licensing permits use without a software charge, with community help available through documentation, CNCF Slack's #flagger channel, Flux talks, and GitHub issues.

Key features

Progressive rollout patterns

Canary, A/B, and blue/green strategies let a team match exposure to its release policy. Flagger gradually shifts traffic rather than switching every user at once, which is particularly useful for services where a small production sample can reveal regressions before broad impact.

Metric-led validation

Built-in checks cover HTTP request success rate and request duration. Release analysis can query Prometheus, Datadog, CloudWatch, New Relic, Graphite, Dynatrace, InfluxDB, or Google Cloud Monitoring, so teams can use the monitoring system they already operate. Custom metrics and webhooks extend the decision with acceptance tests, load tests, or other conformance checks. This flexibility is powerful, but it puts responsibility for meaningful thresholds and tests on the delivery team.

Routing, gates, and recovery

Traffic routing works through an ingress controller or a service mesh compatible with the Kubernetes Gateway API. Manual gating can approve, pause, or resume deployments across supported routing integrations, while automated rollback responds to a failed analysis. Notifications to Slack, Microsoft Teams, Discord, and Rocket keep deployment and canary outcomes visible without replacing those operational controls.

Pipeline integration

Flagger uses Kubernetes custom resources and is designed to work with Kubernetes-focused CI/CD systems. Flux integration can form an automated GitOps pipeline for canary deployments, making it a natural fit for teams already using that workflow rather than a general release manager for arbitrary environments.

Pricing

Flagger costs free on its Flagger plan. The plan is Apache 2.0 licensed and provides the progressive-delivery Kubernetes operator; there are no paid tiers, seat charges, quotas, or trial-renewal terms to weigh. The trade-off is operational rather than contractual: teams supply the Kubernetes cluster, compatible routing, monitoring integrations, and support effort themselves.

Platforms

Flagger is self-hosted and runs as a Kubernetes operator. Its compatibility depends on an ingress controller or service mesh that supports the Kubernetes Gateway API, and its configuration uses Kubernetes custom resources. It is therefore a deployment component for Kubernetes environments, not a standalone hosted service or platform-neutral release tool.

Who it's for

Choose Flagger if your team operates Kubernetes, can route traffic through a compatible ingress or mesh, and wants progressive delivery tied to measurable service health. It is especially well matched to Flux-based GitOps pipelines, organizations with established observability, and teams that need both automatic rollback and human approval gates.

It is a poor fit for teams seeking a hosted experience, deploying primarily outside Kubernetes, or lacking a routing layer compatible with the Gateway API. Those teams would first have to add the surrounding infrastructure that makes Flagger useful.

Pros and cons

• Pro: Gradual traffic shifting, metric analysis, and automatic rollback connect exposure directly to service health.
• Pro: Canary, A/B, and blue/green strategies cover distinct release policies, with manual gates for controlled approvals.
• Pro: Prometheus, Datadog, CloudWatch, New Relic, Graphite, Dynatrace, InfluxDB, and Google Cloud Monitoring integrations reduce dependence on one metrics backend.
• Con: Self-hosting means teams must operate Kubernetes and the surrounding routing and observability components.
• Con: Gateway API-compatible ingress or service-mesh routing is a prerequisite, narrowing use outside that ecosystem.
• Con: Custom checks and webhooks are available, but teams must design and maintain the tests and thresholds that determine rollout decisions.

Alternatives

Argo Rollouts is the closest free, open-source alternative for a Kubernetes controller and CRDs when you want a similar self-hosted Kubernetes focus without a software charge.

Northflank is a freemium platform with a free Sandbox covering two services, one database, and two cron jobs, making it the better direction when you want platform services alongside deployment rather than only an operator.

Devtron Release Orchestration offers a free tier for up to 50 vCPUs, 10 users, and one cluster, plus a $499-per-month self-hosted OSS Plus plan; choose it when those user and cluster controls or paid orchestration support fit your organization.

KubeVela is a free Apache-2.0 Kubernetes control plane for self-hosted environments when broader application delivery control is the priority.

Octopus Deploy is a freemium deployment platform with hosted and self-hosted options when you need deployment coverage beyond a Kubernetes operator.

OpsMx Intelligent Software Delivery Platform is an alternative for teams seeking a broader software-delivery platform with community and enterprise editions.

Plural provides a free 14-day Sandbox and paid platform tiers when you want a platform experience rather than assembling a self-hosted operator.

Weave GitOps is a natural choice for Flux users who want open-source GitOps tooling; its open-source edition requires a Kubernetes cluster and Flux.

Verdict

Flagger is a strong choice for Kubernetes and Flux-oriented teams that want metric-driven progressive releases with rollback and approval controls at no software cost. Choose it for that focused release-safety layer; look elsewhere if you need hosted operations, broad non-Kubernetes deployment coverage, or routing infrastructure outside its compatibility requirements.