GitOps Workflows

Kupe Cloud uses managed Argo CD for application delivery, but the workflow is still standard GitOps. Git holds the desired state, Argo CD reconciles it, and promotion happens by changing Git rather than by applying manifests directly to the cluster.

Default workflow

Update manifests, Helm values, or Kustomize overlays in Git.
Open a pull request and review the change.
Merge the change for the target environment.
Let Argo CD reconcile the Application.
Validate rollout health, routing, logs, and metrics.
Promote the same change to the next environment through Git.

Recommended repository shape

Kupe Cloud does not require a specific repo layout, but the most maintainable setups keep environment differences explicit.

Typical patterns include:

one repo per application, with environment overlays or values files
one Argo Application per environment
small, deliberate differences between dev, staging, and prod

For example:

my-app/
  base/
  overlays/
    dev/
    staging/
    prod/

Promotion model

A simple promotion model works well for most teams:

Deploy first to a development cluster.
Validate the change with real traffic, logs, and metrics.
Promote by pull request into the next environment.
Let Argo CD reconcile the destination cluster.
Repeat the same process for production.

This keeps promotion auditable and makes it clear which Git change reached each environment.

Sync policy choices

Argo CD supports several sync modes. The right choice depends on how tightly you want Git to control the cluster.

Policy	Behavior	Typical use
Manual sync	Changes wait for approval in Argo CD	Production changes with stricter release control
Auto sync	New Git commits sync automatically	Fast-moving development environments
Auto sync + prune	Resources removed from Git are deleted from the cluster	Mature GitOps setups that want clean reconciliation
Auto sync + self-heal	Manual drift in the cluster is corrected automatically	Teams that want Git to remain authoritative

Manual sync is often the safest starting point for production. Development and staging usually benefit from more automation.

Drift management

Drift happens when the live cluster no longer matches Git.

Common causes include:

manual kubectl apply changes
emergency hotfixes made directly in the cluster
resources created outside the Argo-managed source

When selfHeal is enabled, Argo CD will correct that drift automatically. When it is disabled, drift remains visible in the Argo UI until you sync again.

The cleanest model is to treat Git as the source of truth and avoid direct changes in managed namespaces wherever possible.

Rollback workflow

On Kupe Cloud, the safest rollback is usually a Git revert:

Revert the commit that introduced the issue.
Merge the revert through the normal review path.
Let Argo CD reconcile back to the previous known-good state.
Validate health, traffic, logs, and metrics before promoting again.

This keeps rollback history visible and avoids hidden changes that never made it back to Git.

Validation after each change

After every deployment or promotion, check:

Argo CD app status is Synced and Healthy
workload rollout completed successfully
service endpoints are ready
HTTPRoute is accepted if the app is externally exposed
logs and metrics look normal for the change window

If the change affects user traffic, validate the route and application behavior before promoting it any further.