Stuck deploy? How to use feature flags in ArgoCD

The challenge of shipping code without breaking production

Deploying code to production environments is often a stressful moment for engineering teams. In practice, this means pushing new code to live servers serving real customers, where a tiny bug can cause system instability. To prevent a bad release from crashing the entire system, teams seek ways to mitigate risks, whether by applying strategies like zero-downtime deployment patterns or splitting traffic in a controlled manner. The problem is that rollbacks—reverting to the previous version—are often not fast enough once the damage is already done.

This is exactly where automation and state-control tools come into play. ArgoCD, a popular GitOps tool that keeps production synchronized with a code repository, helps automate delivery. However, merely updating configuration files in Kubernetes does not solve the logical problem of a broken feature. You need to separate the act of deploying code from the act of making it visible to the end user, and that is where integrating feature flags makes all the difference in daily operations.

What are feature flags and how they save your deploy

Feature flags act like light switches embedded directly in the application code. In practice, they allow you to ship a new piece of code to production while keeping it hidden from most people. If the system starts exhibiting unexpected errors, instead of going through the stress of building a new application version and waiting for the deployment cycle to finish, you simply turn off the switch via an admin dashboard, instantly reverting to the old behavior.

This approach completely changes the software development lifecycle. Engineers can merge ongoing code into the main branch without fear, knowing the feature stays inactive until the right moment. Furthermore, this technique serves as a foundation for safe testing, working alongside practices like controlled fault injection to validate system resilience. The main benefit is peace of mind, as the risk of downtime plummets when the master switch is literally a click away.

Canary deployments: testing the waters before diving

The concept of a Canary Deployment inherits its name from the historical use of canaries by coal miners to detect toxic gases underground. In software engineering, the idea is to release the new software version only to a very restricted group of users, such as internal employees or 2% of the total base. If the new version starts consuming excessive memory or throwing connection errors, only this tiny group is affected, drastically limiting the blast radius of the issue.

Automating this process requires traffic routing to work intelligently at the infrastructure edge. Continuous delivery tools manage this progression, increasing the traffic percentage to the new version step-by-step—for instance, moving from 5% to 25%, then 50%, and finally 100%. If system health metrics show anomalies at any stage, the system halts the process and rolls back automatically, ensuring the rest of the customers never notice a thing.

Orchestrating the process with ArgoCD and Argo Rollouts

To combine ArgoCD's declarative delivery with gradual releases, the community created Argo Rollouts, a Kubernetes controller that replaces traditional deployment objects with advanced strategies. Below is a practical configuration example of a Rollout that defines a canary strategy with automated analysis steps:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-application
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 10m}
      - setWeight: 50
      - pause: {duration: 30m}
  selector:
    matchLabels:
      app: my-application
  template:
    metadata:
      labels:
        app: my-application
    spec:
      containers:
      - name: app
        image: my-image:v2

In this practical example, the controller routes only 10% of traffic to the new version and pauses for ten minutes to monitor behavior. If everything runs smoothly, the access volume jumps to 50% for another thirty minutes before completing the total transition. This automation removes the human factor from repetitive decision-making, allowing the team to focus on solving business problems while the operator manages traffic with mathematical precision.

Mitigating real risks by combining tools

The true power of this architecture emerges when we combine percentage-based traffic routing with feature flags in the code. While Argo Rollouts ensures that infrastructure and application pods handle physical load smoothly, feature flags allow activating specific parts of business logic only for the canary users accessing the system at that exact moment.

This double layer of protection solves a classic dilemma: what if the code passes all infrastructure tests, but the new UI screen contains a usability flaw that confuses customers? With a feature flag placed strategically in the front-end or back-end code, you can disable the visual functionality without having to repackage container images. Operations gain unprecedented agility, dropping incident response times to near zero.

Final thoughts on safe and continuous delivery

Adopting gradual deployments and feature flags is not just a technical choice, but a profound shift in an engineering culture. When developers know that a bug won't take down the production system for hours, the fear of shipping new code disappears and delivery cadence naturally increases. Tools like ArgoCD provide the solid foundation needed to keep environments organized through GitOps, while smart release strategies handle the rest.

Investing time in the initial setup of these tools brings immediate returns in stability and operational confidence. Teams stop fighting middle-of-the-night fires and start focusing on creating real value for users. After all, the best infrastructure is the one that works invisibly behind the scenes, allowing innovation to happen with total security and predictability.