Keep GitOps.
Drop the control plane.
GitOps is a contract, not a tool: desired state in Git, something reconciles reality against it, drift gets corrected. Nothing in that contract says the something has to be seven pods in every cluster you operate.
The controller was supposed to be the easy part
ArgoCD and Flux both do their job well. The cost is not the tool - it is everything you end up running and owning around it.
A control plane in every cluster
ArgoCD is seven pods per cluster - server, application controller, repo server, redis, applicationset, notifications, dex. Roughly 500-800 MB of RAM on every cluster you run, forever.
You operate the operator
Version upgrades, CRD migrations, SSO wiring, RBAC mapping, repo-server capacity. The GitOps controller becomes a service your team is on call for.
Credentials that expire at the worst time
API tokens between your platform and the controller have to be created, cached, refreshed, and rotated. An entire class of "deploy failed because auth expired" incidents exists only because of that hop.
Debugging the abstraction, not the release
At 3am you are reading an Application CR, a sync wave, and a repo-server cache when what you actually want to inspect is a Helm release.
Secrets glue nobody owns
helm-secrets, external-secrets, or a Vault sidecar, each with its own failure mode - and an AGE key sitting on the cluster because the repo server needs it there.
A repo layout that lives in one person's head
App-of-apps or ApplicationSets, per-environment values, a promotion model, and conventions that were never written down. Onboarding means learning all of it first.
What replaces it
The agent that already runs in your cluster drives Helm directly. Same contract, one less system in the delivery path.
The engine is the agent you already run
Ankra's native engine drives Helm directly from the in-cluster agent: install, upgrade, reconcile, roll back. No extra controller, no API hop, no token lifecycle between them.
Standard Helm releases, not a proprietary format
Releases land in the helm.sh/release.v1 Secrets every Helm tool understands. helm list, helm history, helm get manifest, and helm rollback all work - even if Ankra's control plane were unreachable.
Git stays the source of truth
Every change is a commit in your repo, with standard Helm charts and Kubernetes manifests. Rollback is a revert. Leaving takes nothing with it, because nothing was ever locked in.
Drift detection you can monitor
A sweep every 60 seconds diffs live resources against the rendered manifest, self-heals when sync_policy.self_heal is on, prunes orphans with auto_prune, and publishes a heartbeat so a dead reconciler cannot hide.
Sync windows and retry policy survived the move
Cron expression, duration, timezone. Outside the window an operation returns immediately as cancelled with an explicit reason, instead of silently queueing into your Friday evening.
SOPS without leaving the key on the cluster
The agent fetches the encrypted values file, pulls the key for that single render, decrypts, and hands Helm the plaintext. The private key is never stored on the cluster.
Adoption, not reinstallation
The part everyone fears about switching delivery engines is the switch. Here is what it actually looks like, one addon at a time.
Import the cluster - ArgoCD keeps running
One Helm command installs the Ankra agent into the cluster you already have. Nothing is uninstalled and nothing is taken over. Your existing controller keeps reconciling everything it owns while you evaluate.
Describe the stack you already deploy
Your charts, values, and repo stay exactly as they are. A Stack captures what runs where and in what order, so the dependency graph and promotion model stop living in a wiki page and start living in a versioned object.
Move one addon at a time, by adoption
Migration runs per addon with helm upgrade --install --take-ownership. Helm adopts the live resources: UIDs do not change, no pod is recreated, no traffic blips. The only on-cluster mutation is Helm's own ownership metadata.
Stop paying the tax - on your schedule
When the last addon is on the native engine, Ankra clears its managed credentials and steps away. It deliberately does not uninstall your controller: plenty of teams deliver their own applications through the same instance. Your ArgoCD, your call.
Same repo, same charts, same drafts and approvals. Seven fewer pods per cluster, one fewer credential lifecycle, and every deployment question now has a plain helm answer.
What you keep
We held the migration until the answer to "what do I lose?" was almost nothing. One honest gap remains: multi-source applications are single-source only on the native engine today.
Before and after
| Task | Self-run ArgoCD / Flux | With Ankra |
|---|---|---|
| Delivery controller per cluster | 7 pods, 500-800 MB RAM | None - the agent does it |
| Upgrading the GitOps engine | Your change window, your risk | Managed for you |
| Inspecting a deployment | Application CR + sync waves | helm history / helm get manifest |
| Drift correction | Controller resync, if configured | 60s sweep, self-heal per addon |
| Secret decryption | Plugin on the repo server, key on cluster | Agent-side sops --decrypt, no stored key |
| Rolling back a bad release | git revert + wait for sync | git revert, or helm rollback directly |
Read before you migrate
The long-form versions of everything above, including the parts we have not finished yet.
GitOps Without ArgoCD: Inside Ankra's Native Deployment Engine
Why we removed seven pods from every cluster, how the reconcile loop works, and what the migration does to live resources (nothing).
Read itAnkra vs DIY GitOps (ArgoCD + toolchain)
An honest accounting of what building your own platform on ArgoCD or Flux actually costs once it works end to end.
Read itSecrets Belong in Git. Plaintext Does Not.
SOPS and age in a GitOps repo, and where the decryption key should - and should not - live.
Read itDrafts, Approvals, GitOps
The propose-review-record contract that stayed identical through the engine swap, because it never lived in ArgoCD.
Read itStop operating the thing that operates your deploys
Import a cluster in five minutes. Keep your repo, your charts, and your controller running until you decide otherwise.