ArgoCD + Testkube = Better Together

GitOps made your cluster state declarative and auditable. Testing is the piece it tends to leave behind, and that is the gap this closes.

GitOps reconciles state, but it can't gate on quality

Running GitOps for application and infrastructure operations brings real benefits: version control, collaboration, and reliable rollbacks. What a pure GitOps setup does not give you is a way to act on test results. Reconciliation keeps the cluster matching Git, but it has no native concept of "hold this release until the tests pass."

Teams end up bolting test logic onto pipelines or skipping the gate altogether, which leaves quality outside the same declarative, version-controlled model that governs everything else. Testkube closes that by treating tests as first-class Kubernetes resources, so they sit in Git and run through the same reconciliation flow.

Built on the constructs GitOps already uses

Testkube stores the definition of every test execution, for any testing tool, as Kubernetes CRDs. You can define those executions through an easy GUI or with the YAML tooling you already use, including Kustomize, Helm, and VS Code. Putting test definitions in CRDs makes them version-controlled artifacts like any other Kubernetes resource, and it opens the definition process to the whole team, which is the shift-left workflow most GitOps organizations are after.

Triggers that fit a GitOps flow

Testkube test executions can be triggered however your workflow needs: manually, on a schedule, through CI/CD integrations, or by watching changes to the underlying Kubernetes resources. That means you can run tests wherever they belong in a GitOps setup: during CI while artifacts are built, in reaction to high-level reconciliation events in ArgoCD or Flux, or at the Kubernetes level when a reconciled resource changes.

Scaling without the scripting

Once a test is triggered, it scales without custom orchestration code, for both load and functional testing at large scale. Testkube leans on Kubernetes resource allocation, scheduling, and scaling to do that work, so you do not maintain a separate scaling layer. However the run was triggered, Testkube then gives you one central UI for troubleshooting and reporting, agnostic to the testing tool and to the CI/CD or GitOps pipeline that set it off.

Using Testkube with ArgoCD and Argo Workflows

The table below shows how Testkube enhances testing in GitOps scenarios.

Why teams run this on Testkube

A pure GitOps setup is excellent at keeping the cluster in sync with Git, and weaker at deciding whether a change is safe to promote. Testkube fills that without pulling you out of the model: tests are CRDs in Git, triggers hook into ArgoCD and Flux reconciliation, scaling rides on Kubernetes itself, and results land in one place regardless of tool. You keep the GitOps benefits, version control, collaboration, rollbacks, and gain the quality gate they leave out.

Bring testing into the GitOps model

Your cluster state already lives in Git, declarative and auditable. Your tests should too. Testkube defines tests as CRDs, triggers them on the reconciliation events you already run, and reports every result in one place, so quality becomes part of the same workflow instead of a bolt-on beside it.

Test faster, ship with confidence, and stay in control.