Argo CD Upgrades & Support
Last reviewed by Tyler Eastridge
AceMQ keeps self-hosted Argo CD inside the project's patch window and running at scale: upgrade plans across clusters, controller, repo-server and ApplicationSet tuning, and 24/7 cover with a 15-minute emergency response. The project patches only its three newest minor versions, so a version stays supported about nine months (3.3 shipped on 2 February 2026 and reached end of life on 3 November 2026). AceMQ engineers lead each engagement with partner GitOps specialists and supply no Argo CD builds or patches.
A senior engineer, not an SDR. No sales sequence attached.
Without a managed-platform contract or a GitOps team of your ownFor production incident cover, see AceMQ Argo CD 24/7 support.
Customers
Partners
The Problem
Eight Argo CD problems that platform teams bring to AceMQ, from a minor that has left the patch window to a controller that cannot keep up with the clusters it owns. If one describes your week, that is where the review starts.
Argo CD 3.3 reached end of life on 3 November 2026 and some clusters still run it
Several Argo CD instances each run a different Argo CD version and nobody keeps the list
The application controller runs out of memory or falls behind as clusters and applications are added
The upgrade notes for the next minor list breaking changes and nobody has read them against the settings and ApplicationSets in use
The repo server times out when many applications render at once from the same Git repositories
The install was applied from a manifest long ago and nobody knows what was patched on top of it
Cluster credentials, SSO and RBAC for an instance with production access are held by one person
The Argo CD configuration has never been exported and restored on a spare cluster
A good fit if you run self-hosted Argo CD in production across several clusters, have an instance on a minor near the edge of the patch window, or want a written view of controller load and upgrade order before the next minor ships.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Argo CD.
How it breaks, and the fix
The application controller reconciles every application on the clusters assigned to it. When one replica owns too many clusters it uses more and more memory, reconciliation falls behind, and applications on those clusters show stale status.
One controller shard, three clusters, two falling behind
One Git repository, one application controller, three clusters
One controller reconciles the applications on three clusters. Sync status is current, memory has headroom and a Git change reaches the clusters in the time the team expects.
More clusters and applications are added. The controller's memory climbs and its queues back up. Applications on clusters A and B show stale status and slow syncs, and nobody knows whether the cluster or Argo CD is the cause.
Clusters are spread across controller replicas, memory limits are sized to the measured load and repo-server capacity is checked. Status is current again, and adding a cluster no longer slows the others.
The Argo CD project's high-availability guide describes the fix: shard the clusters across several application controller replicas by raising the replica count and repeating it in the ARGOCD_CONTROLLER_REPLICAS environment variable, then choose a distribution method. Legacy mode distributes by UID and is non-uniform, round-robin distributes equally, and consistent-hashing reduces reshuffling when shards or clusters change; the guide documents the last two as experimental, so the choice is a decision to test, not a default to copy. Repo-server capacity and Redis are the other places that fall behind, and every upgrade changes some of these settings: each minor has its own upgrade note with breaking changes, which is why the first AceMQ deliverable is a written version and scale review.
Our Services
AceMQ runs five Argo CD service lines: upgrade planning and execution, scale and performance tuning, multi-cluster and ApplicationSet operations, a fixed-scope health check, and backup, recovery and security. Any of them can roll into 24/7 on-call with a 15-minute emergency SLA.
Minor-to-minor upgrades across one instance or a fleet, planned against the project's three-minor patch window.
Why the controller is slow or out of memory, and what to change: sharding, repo-server capacity and Redis, sized to your cluster and application counts.
Running many clusters from one or several Argo CD instances without drift, surprise prunes or one person holding the credentials.
The fixed-scope entry engagement: a written report on the state of your Argo CD that your own team can act on, with or without AceMQ afterwards.
A configuration you can restore and a clear line from each CVE to the version that fixes it.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ Argo CD support gives you an AceMQ engineer and a 15-minute first response when Argo CD or a sync is failing in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes still come from the Argo CD project's supported releases: AceMQ does not produce builds or patches.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Argo CD engagement runs in four stages: a scoping call with a quote within 1 hour, a written version and scale review, an upgrade order and test plan you approve, then upgrade windows and on-call. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: how many instances and which minors, how many clusters and applications, HA or not, how Argo CD is installed and who is on call today. A quote request is answered within 1 hour.
Scoped per estate
A fixed-scope read-only review: versions against the three-minor window, controller replicas and sharding, repo-server and Redis capacity, sync policies and ApplicationSet generators. Findings are written and ranked by production risk before anything changes.
Scoped per estate
A written plan: the upgrade notes read for every minor hop, a rehearsal on a non-production instance, the order of instances and a rollback boundary for each. You approve it before the first window.
Ongoing
Upgrade windows run with your team, on-call response with a 15-minute P1 SLA, and a written review after each window or incident.
A senior engineer, not an SDR. No sales sequence attached.
Typical engagements
Typical Argo CD engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Platform Engineering Team
A typical engagement to check a fleet of Argo CD instances against the project's three-minor patch window and to plan the upgrade order, the rehearsal and the controller sizing for the instances that move.
Kubernetes
Mid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
DockerKubernetesSaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
PrometheusSolutions
AceMQ covers Argo CD end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Argo CD on your infrastructure and fully managed Argo CD on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Argo CD for you.
Compare the four Argo CD support tiersSide by side
Argo CD is open source and the project patches only its three newest minor versions. A managed platform moves the control plane to a vendor. Self-hosting keeps it in your network and leaves the upgrade calendar to you. AceMQ supports the self-hosted case and sells no managed platform. Each row below answers one question about the choice.
| Question | Self-hosted, no outside cover | Managed Argo CD platform | Self-hosted with AceMQ |
|---|---|---|---|
| Who runs the control plane? | Your team, in your clusters. | The platform vendor, as a service. Akuity, built by the creators of Argo CD, is one such vendor. | Your team, in your clusters, with AceMQ engineers on call and in the change windows. |
| Who patches? | You do, from the upstream releases. A version outside the three newest minors gets no fix. | The vendor, under its own terms. | You apply upstream releases and AceMQ plans and runs the upgrades. AceMQ supplies no builds or patches. |
| Who answers at 3am? | Your own on-call, with the project's issue tracker. | The vendor, under the support plan you buy. | An AceMQ engineer within 15 minutes, 24/7. |
| What does it cost? | Cluster resources and engineer time. | A subscription priced by the vendor. Read its pricing page. | Your cluster resources plus an AceMQ contract quoted per estate. Quote requests are answered within 1 hour. |
| Where do credentials and data live? | Inside your network. | Check what the vendor hosts, what connects out and how your clusters authenticate to it. | Inside your network. AceMQ works through access arrangements you control. |
| When does it fit? | A small fleet whose engineers follow every release. | You do not want to run the control plane at all. | You want the control plane in your network and a second team on the upgrade calendar and the night shift. |
For the support windows of the other open-source tools in your stack, read open-source support windows compared, or Kubernetes support options for who covers Kubernetes itself.
One partner, not five
Argo CD rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on Kubernetes support options and support windows, plus the AceMQ services around Argo CD: Kubernetes, Docker, Prometheus and Grafana.
FAQs
Five answers on Argo CD from AceMQ: how long a version is patched, managed platform or self-hosted, what AceMQ does for versions the project has dropped, why the controller is slow, and what is out of scope.
Still have questions about Argo CD? Email an Expert
The project patches only its three newest minor versions, and it ships a new minor roughly every three months. As of 4 November 2026 those are 3.4, 3.5 and 3.6. Argo CD 3.3 shipped on 2 February 2026 and reached end of life on 3 November 2026, about nine months. The project's schedule lists 3.7 for 2 February 2027 (planned, not promised), which would move 3.4 out of the window. CVEs are patched on all supported versions.
Both are sound. Akuity, built by the creators of Argo CD, sells a managed Argo CD platform with enterprise support, which suits teams that do not want to run the control plane. Self-hosting keeps the control plane and credentials inside your network, and it leaves you responsible for the upgrade calendar. AceMQ supports the self-hosted case and does not resell any managed platform.
No. AceMQ produces no Argo CD builds or patches, and the project's fixes ship only in its supported minors. For a version past end of life the fix is the upgrade, and AceMQ plans and runs it, one minor at a time with the upgrade notes read and a rehearsal first.
Usually one controller replica owns too many clusters. The project's high-availability guide describes sharding clusters across controller replicas, with a choice of distribution methods (legacy, round-robin and consistent-hashing, the last two documented as experimental). Repo-server capacity and Redis are the other usual suspects. The version and scale review measures which one it is before anything is changed.
No. AceMQ runs, upgrades and supports Argo CD itself and reviews your sync policies, projects and ApplicationSets. Writing application manifests, Helm charts or CI pipelines, and changing application code, are outside this service.
Yes. AceMQ works on Argo CD in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Argo CD environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Argo CD is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Argo CD estate, tells you what cover fits, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email an Argo CD Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
