Deployment shouldn't depend on who ran the script
In a lot of pipelines, deploying is an event — someone runs a job, it pushes changes to the cluster, and the cluster is now in whatever state that job happened to leave it in. If a change gets made by hand afterward, or a step fails halfway through, nothing corrects it. The cluster's actual state and what it's supposed to be quietly drift apart, and nobody notices until something breaks.
Vertro takes the opposite approach: Git holds the desired state, and controllers continuously reconcile the cluster toward it — not once, at deploy time, but constantly. Drift doesn't get to persist quietly, because something is always checking.
One authoritative owner per resource
Each layer of the stack has one authoritative management path, so there is no ambiguity about which system owns the declared state or which workflow should apply a correction.
| Resource class | Authoritative management path |
|---|---|
| GCP projects, IAM, cloud infrastructure | Terraform/Terragrunt through approved workflows |
| Namespaces, quotas, platform Kubernetes policy | Config Sync |
| Application Deployments, Services, routes | Argo CD using Helm packages |
| CI/CD workflow execution | GitHub Actions on private ARC runners |
Terraform doesn't touch Application Deployment objects. Argo CD doesn't provision cloud infrastructure. That separation is deliberate — it's what makes it possible to say with confidence which system is responsible when something needs to change, or when something goes wrong.
Pull requests as the actual governance boundary
Vertro generates infrastructure and deployment changes into Git and opens them as pull requests — not because that's a nice-to-have audit trail, but because it's the mechanism that makes review possible before anything executes. A request becomes a generated, deterministic change; a human (or an approval policy) reviews it; only then does execution happen.
Build once, promote the same artifact
Environment promotion is a common place trust breaks down — an Application gets rebuilt for staging, rebuilt again for production, and now "it worked in staging" doesn't actually guarantee the production build behaves the same way. Vertro's preferred model builds an artifact once and promotes that exact artifact through Environments via GitOps, so what passed testing is what actually reaches production.
Recoverable failure, not zero failure
Failures are going to happen — a workflow step fails, a reconciliation stalls, a rollout needs to be undone. What matters is whether the platform can say clearly what failed, what already succeeded, and whether it's safe to retry. Vertro avoids a single generic "rollback" button that hides which layer actually changed — recovery routes through the same Git history and the same authoritative management path for that resource, whether that's a Git revert, an Argo CD rollback, or a Terraform correction.
The full request lifecycle — Request, PR, Approval, Execution, Reconciliation — is covered in detail on how Vertro works.
Frequently asked questions
What's the difference between GitOps and a regular CI/CD pipeline?
A regular pipeline pushes changes imperatively — it runs a script that mutates the cluster. GitOps works in reverse: Git holds the desired state, and a controller continuously reconciles the cluster toward it. That means drift gets corrected automatically, and the cluster's actual state can always be traced back to a specific, reviewed Git change.
Does every infrastructure and deployment change go through a pull request?
Yes, for changes Vertro generates. Requests are validated, generated into Git, and opened as pull requests for review before execution — the same review discipline whether the change is a new Application, a configuration update, or a policy change.
Does GitOps mean developers need to learn Argo CD or Config Sync?
No. Developers work through familiar Git and pull-request workflows on their own Application repository. Argo CD and Config Sync operate behind that interface, reconciling desired state without requiring developers to operate the reconciliation tooling directly.
How does Vertro prevent configuration drift?
Vertro assigns one authoritative management path to each resource class. Config Sync continuously reconciles platform-owned Kubernetes configuration, while Argo CD continuously reconciles Application workloads. Google Cloud infrastructure is declared in Terraform and corrected through an approved Terraform execution when drift is detected. This prevents multiple systems from competing to manage the same resource.
Can we roll back a deployment?
Yes. Application recovery normally starts with a Git revert or an approved desired-state correction, after which Argo CD reconciles the cluster. An Argo CD rollback may be used operationally, but Git must remain aligned with the intended final state. Cloud infrastructure recovery follows the Terraform-managed path.
Does Vertro rebuild the Application image for each Environment?
No. The preferred model is building an artifact once and promoting that same artifact through Environments via GitOps, rather than rebuilding per stage — so what passed testing in one Environment is exactly what reaches the next.