Exposing Argo CD with Traefik IngressRoute

Exposing Argo CD with Traefik: when a single host is enough

If Traefik already fronts your cluster and your platform team needs both the Argo CD web UI and the argocd CLI, a single host is often the simplest answer. Argo CD's ingress guide documents Traefik v3 with an IngressRoute custom resource that routes gRPC traffic using the h2c scheme. Traefik can serve TCP and HTTP on the same port, so the UI and the CLI's gRPC calls can share one hostname without separate hosts or path rules. The guide is the natural next read before you write any manifests: Argo CD: Ingress configuration.

This pattern fits best when Traefik is the only edge controller you operate, when one certificate and one DNS record for the Argo CD hostname are preferred, and when your security team wants a single routing policy to review. It fits less well when a separate gRPC hostname is required by a load balancer, a web application firewall or a network policy that treats browser and API traffic differently. In that case, separate routes or hostnames are easier to reason about. Confirm the Traefik v3 chart version your cluster runs and check that its IngressRoute CRDs are installed before you rely on the documented manifests.

Before you commit to one host, check three things with your team. First, confirm that the argocd CLI reaches the server through the same hostname your browsers use, including from CI runners and jump hosts. Second, decide where TLS ends, because a single host means the TLS choice applies to both protocols at once. Third, test the CLI login and a sync from a non-browser client after every Traefik upgrade, since a routing change can break gRPC while the UI still loads. Ask your Traefik maintainer which middleware and timeout settings they apply to long-lived gRPC streams.

Which IngressRoute and TLS options fit your setup

This table compares the main routing and TLS choices for publishing Argo CD through Traefik v3, including single versus separate routes, where TLS ends, and how certificates are issued. Read each row against your client access needs, and confirm the exact configuration keys in the Argo CD ingress guide before you build.

Choice	When it fits	What it requires	Main trade-off
Single IngressRoute for web and gRPC	One hostname serves the browser UI and the argocd CLI, and you want one route to maintain	Traefik must route both HTTP and gRPC traffic on the same host, with the gRPC backend declared using the h2c scheme	Fewer objects to manage, but a routing mistake affects both the UI and CLI at once
Separate routes for web and gRPC	The CLI or automation needs different hostnames, paths or middleware than the browser UI	Two IngressRoute resources, a clear naming convention, and DNS records for each hostname	More configuration to keep consistent, with more places for drift
TLS terminated at Traefik	You want certificate handling centralized at the ingress and Argo CD running without its own TLS listener	Traefik certificate configuration and a backend that accepts plain traffic, set through server.insecure	Traffic between Traefik and the Argo CD pods is no longer encrypted unless you add a separate control
TLS passthrough to Argo CD	Argo CD must keep its own TLS, for example to meet a policy that forbids decrypting at the edge	Argo CD serving TLS on its own certificate, and a TLS route matched by SNI in Traefik	Traefik cannot inspect HTTP, so per-path middleware such as header rules is unavailable
server.insecure enabled	TLS ends at Traefik and the Argo CD API server listens without TLS inside the cluster	Setting the server.insecure option in the Argo CD configuration, then confirming the Traefik backend scheme matches	A mismatch between the backend scheme and the listener is a common cause of failed CLI logins
Certificates from cert-manager	The cluster already runs cert-manager and you want renewal automated	A cert-manager issuer that your team can reach and a certificate tied to the Argo CD hostnames	Issuer access and renewal monitoring become part of the operations runbook
Certificates from an internal CA	Certificates must be issued under your organization's private PKI or policy	CA root trust installed for the browser and for CLI clients, plus a documented renewal process	Clients outside the trust chain will reject the certificate, so distribution is a dependency

Setting up the Traefik IngressRoute for Argo CD

This sequence takes Argo CD from a cluster with Traefik to a single hostname that serves both the web UI and CLI gRPC traffic, with the TLS mode chosen up front and checked at each step.

Confirm Traefik v3 and its CRDs
The platform engineer checks that Traefik v3 is running in the cluster and that the IngressRoute custom resource definitions are installed. Run kubectl get crd and look for the Traefik IngressRoute kinds, then confirm the controller pods are healthy with kubectl get pods -n traefik. Confirm the Traefik entry point you plan to use for HTTPS is reachable from the network where your users and CI runners sit. The step is done when the CRDs are listed and the controller reports ready. If the CRDs are missing, install Traefik with its CRDs before continuing, and check the Traefik v3 documentation for the exact install method your platform team uses.
Set the Argo CD server configuration
Decide where TLS ends before editing anything. If Traefik terminates TLS, the Argo CD API server must serve plain HTTP inside the cluster, which is set through the server.insecure key in the argocd-cmd-params-cm ConfigMap. If you pass TLS through to Argo CD, leave that key unset and expect the certificate to come from Argo CD. Apply the change, then restart the argocd-server deployment so the new setting loads. The check is that kubectl get configmap argocd-cmd-params-cm -n argocd -o yaml shows the intended value and the server pods roll over cleanly. Confirm the exact key names against the Argo CD ingress guide for your installed version before you apply them.
Create the IngressRoute with the h2c backend
Write an IngressRoute that matches one hostname and sends traffic to the argocd-server service. The Argo CD ingress guide documents routing gRPC with an h2c scheme on the backend, so the service definition for the gRPC path uses that scheme while web traffic uses HTTP. Traefik can handle both protocols on the same port without separate hosts or paths, so keep one host for the web UI and the CLI. Apply the manifest with kubectl apply, then check with kubectl get ingressroute -n argocd that the route is accepted and shows the expected host. Traefik logs will show any route that fails to bind.
Provision the certificate and DNS record
Issue a certificate for the Argo CD hostname from the certificate source your organization uses, such as an internal CA or a cert-manager issuer, and store it as a TLS secret referenced by the IngressRoute. Create the DNS record that points the hostname at the Traefik entry point, using the address your network team assigns. If you chose passthrough in step two, the certificate lives on the Argo CD side instead. The step is done when dig or nslookup resolves the hostname to the Traefik address and a TLS handshake with openssl s_client presents the expected certificate chain. Confirm with your security team which CA and renewal process applies.
Verify the web login
Open the Argo CD hostname in a browser from a client on the intended network. The login page should load over HTTPS with the certificate you issued, and the login with the admin account or your configured SSO should succeed. Check the browser certificate details to confirm the issuer and hostname. If the page loads but the application list fails, review the Traefik access logs and the argocd-server logs for routing errors. The step is done when you can sign in and see the applications view without warnings about the certificate.
Verify the argocd CLI login against the same host
From a workstation or CI runner that uses the CLI, run argocd login with the same hostname used for the web UI. Add the grpc-web option only if your path requires it, and confirm the TLS flags match the certificate you issued. A successful login followed by argocd app list shows that gRPC calls traverse the same IngressRoute and reach the API server. If the login hangs or reports a protocol error, check the h2c backend setting from step three and the server configuration from step two before changing the hostname. The step is done when the CLI lists applications through the shared host.

Security controls for an Argo CD ingress behind Traefik

Traefik is the entry point for both the Argo CD web UI and its gRPC CLI traffic, so the controls at that edge decide who can reach the API and what leaks in responses. The cards below cover authentication, admin access, transport, network reach and the repository risk that sits behind the ingress.

JWT-only API authentication

Argo CD authenticates API requests only with JSON Web Tokens, so the ingress does not need to carry a second login mechanism for API calls. Confirm that your Traefik routes do not add basic authentication or header shortcuts that bypass the token check, and that every client, including automation, obtains and presents a token. Review token lifetimes with your identity team before exposing the endpoint widely.

Disabling the built-in admin user

The admin user is intended for initial setup only. Once local users or SSO are configured, set admin.enabled to false so that the shared password stops being a path into the UI through the ingress. Check that at least one SSO-based administrator can sign in and that break-glass access is documented before you turn the admin account off.

TLS between Traefik and Argo CD

Traefik can terminate TLS for clients while Argo CD keeps its own encrypted channels, and the security documentation notes that TLS covers traffic between Argo CD's components. Decide where TLS ends for the gRPC path and the web path, and document it. If Traefik reaches the API server over plaintext inside the cluster, record that as an accepted design decision with your security team.

Credential redaction in responses

Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs. This limits what a user who can read the UI or API learns about repository and cluster secrets. Still, confirm that Traefik access logs and any ingress-level debug output do not record request bodies or authorization headers, since those logs sit outside Argo CD's redaction.

Restricting access to approved networks

Limit who can reach the Argo CD host and gRPC endpoint by applying source-range or allow-list middleware in Traefik, or by enforcing the same rule at the network perimeter. Typical approved sources include corporate egress ranges, CI runners and administrator jump hosts. Test the rule with the CLI as well as the browser, because a restriction that blocks gRPC by accident breaks pipelines without a clear error.

Repo-server exposure to untrusted repositories

The repo-server runs Helm and Kustomize against repository content, so a malicious or careless repository can influence what gets rendered and how files are read. The ingress cannot fix this, but it shapes the risk. Limit which repositories Argo CD can reach, restrict who can create applications through projects, and review out-of-tree file references before approving changes.

Questions teams ask before exposing Argo CD with Traefik

How much effort does exposing Argo CD through Traefik take?

The effort is usually small compared with the platform work around it, and it depends on how many decisions are still open. The IngressRoute itself is a short manifest, but the time goes into agreeing the hostname, where TLS ends, whether the CLI can reach the gRPC endpoint through the same host, and how the change is tested. Traefik v3.0 is the documented baseline in the Argo CD ingress guide, so confirm your Traefik version against it before you start. Ask any partner for a written scope that lists the hostnames, certificate source, test cases and the Argo CD version covered, because that list is what drives the quote.

Can our in-house team expose Argo CD with Traefik without outside help?

A team that already runs Kubernetes ingress and manages Traefik can usually do the core configuration in-house. The parts that most often need experienced review are the gRPC scheme, TLS handling on both protocols and the link to SSO and RBAC, since a working login page does not prove the CLI works. Confirm that your team can read the Argo CD ingress guide, test argocd login from a workstation outside the cluster, and roll back a route quickly. If any of those gaps exist, a fixed-scope engagement can cover the build and hand over runbooks.

What access and inputs do we need to provide for the Traefik work?

Plan to provide the following before work starts:

Read and write access to the namespace where Argo CD runs, plus permission to create IngressRoute and certificate objects
DNS control for the chosen hostname, so records can point at the Traefik entry point
Certificates from your internal or public CA, or a decision to use Traefik's certificate handling
Network policy rules that allow the Traefik pods to reach the Argo CD server service and the users' and CI runners' networks to reach Traefik

Confirm the exact permissions with your security team, because they vary by cluster and change control rules.

Does Traefik routing affect how SSO works with Argo CD?

Routing does not change how identity works, but a wrong callback URL will break SSO after the route goes live. Argo CD builds its redirect and callback addresses from the URL you configure, so the public hostname, scheme and port must match what the identity provider expects. Check the user management documentation for the settings that apply to your provider, and confirm that the hostname in your OIDC or Dex configuration is the one served by Traefik. Also remember that the admin user should only be used for initial setup and disabled with admin.enabled set to false once SSO works.

How does a Traefik route interact with Argo CD high availability?

Traefik should send traffic to the Argo CD server service, which is designed to run with more than one replica in a high availability install. The HA documentation says the HA manifests need at least three nodes because of pod anti-affinity rules, and that IPv6-only clusters are not supported. Confirm that health checks and the service endpoints in your Traefik configuration only target ready pods, so a restarting replica does not drop sessions. Test a rolling restart of the server during a maintenance window to see how the CLI and browser sessions recover.

What should we do if argocd login fails behind the Traefik proxy?

Start by checking whether the CLI is reaching the gRPC endpoint with the h2c scheme, because a browser-only test does not exercise that path. Confirm that the IngressRoute routes the gRPC traffic as the Argo CD ingress guide describes, that the hostname matches the one you pass to argocd login, and that the certificate is trusted by the workstation or CI runner. Then check that the Argo CD server is not also terminating TLS in a way that conflicts with Traefik. Collect the Traefik access log and the server logs for the failed request before changing settings, so you can see which hop rejected it.

What recurring work comes after the Traefik route is live?

The recurring work is mostly certificate renewal, Traefik upgrades, and Argo CD upgrades that may change how the server expects traffic. Argo CD publishes a release cadence where a minor release ships four times a year and only the three most recent minor versions receive patch releases, so plan a review of the route after each upgrade you adopt. Ask any partner whether ongoing support, upgrades and testing are included in the quote or offered as a separate retainer, since that choice changes the annual cost.

Limits to confirm in your environment before go-live

The Traefik pattern for Argo CD depends on a few versions and network facts that only your environment can confirm. Each item below is a check to run before go-live, not a settled fact about your cluster.

Traefik version in use

The documented pattern uses Traefik v3.0 with an IngressRoute CRD for gRPC over h2c. Confirm the Traefik version your cluster actually runs, and whether your Helm chart or distribution pins an older or newer release. Check the CRD API group and version on your cluster before writing manifests, because they change between major lines. Treat v3.0 as the documented baseline, not a guarantee for your version.

Examples against your Argo CD release

The ingress guide examples are written for a specific Argo CD line, and the project only patches its three most recent minor versions. Compare the manifest examples with the Argo CD version you plan to deploy, and check the current patch lines on the releases page. If your version is outside a supported line, confirm whether the examples still apply before copying them.

IPv6-only cluster support

The Argo CD high availability documentation states that IPv6-only clusters are not supported. If your cluster, load balancer or node addressing is IPv6-only, the Traefik entry point and the Argo CD components cannot be assumed to work together. Confirm your addressing model with the platform team and the Argo CD release you plan to run before any routing design is finalized.

Network policies for the gRPC path

The Argo CD CLI uses gRPC over the same host as the UI, so every hop on that path must allow it. Check that network policies permit traffic from the Traefik pods to the Argo CD server service on the server port, and that the CLI's client network can reach the Traefik entry point. Test with the argocd CLI from a real client network, not only from inside the cluster.

Protocol handling at the edge

Upstream load balancers, cloud firewalls and corporate proxies sometimes downgrade HTTP/2 or strip the headers that gRPC needs. Confirm that every layer in front of Traefik passes HTTP/2 through to the entry point and does not terminate or rewrite the connection. Ask your network team to confirm this in writing, because a failure here often looks like a generic login or timeout error.

TLS termination and certificate scope

Decide where TLS ends and confirm that the certificate covers the single host used for both the web UI and gRPC. Confirm how your certificate authority issues and renews certificates for that host, and whether internal clients trust that authority. Verify the chain with an external client before go-live, because the CLI fails differently from a browser when trust is missing.

Keeping the Traefik route working through Argo CD upgrades

Argo CD ships a minor release once every three months, and only the three most recent minor versions receive patch releases. That cadence means the Traefik route for the web UI and gRPC CLI traffic will be exercised by a new Argo CD version several times a year, and it must be retested each time rather than assumed to keep working. Treat the IngressRoute and its Argo CD Service settings as part of the upgrade change, not as infrastructure that sits outside it. Confirm which minor versions your team has committed to patch, and schedule an upgrade before your current minor leaves that window.

Assign ownership of the IngressRoute explicitly. The platform or cluster team usually owns the Traefik objects, the TLS secret and the Middleware, while the team that runs Argo CD owns the server.insecure setting and the Service it points to. Keep the IngressRoute manifest in the same Git repository as the rest of the Argo CD configuration, or in a repository with a named owner and review rules, and change it through pull requests. Pin the Traefik v3 chart or image version alongside the Argo CD version so that a change to either one shows up as a single reviewable diff. Record which Traefik version the route was last verified against.

After any 3.x upgrade, recheck the path a user and a CLI actually take. Load the web UI over HTTPS, confirm that the argocd login command succeeds through the gRPC route, and check that the h2c scheme still reaches the server port. Review the Argo CD 2.14 to 3.0 upgrade notes for changes that affect access, since they change RBAC for update, delete and logs operations, which can make a previously working CLI or service account fail even when routing is intact. Use the Argo CD upgrade notes for 2.14 to 3.0 as the checklist source, and confirm any other minor upgrade against its own notes in your environment.

Official sources for Argo CD ingress and releases

Where is the official Argo CD guide for exposing it through Traefik?

The official reference is the Argo CD ingress configuration guide in the operator manual. It documents the Traefik v3.0 setup with an IngressRoute resource, including how gRPC traffic is routed with the h2c scheme. Read it before writing your manifests, because the examples there show the settings Argo CD expects for both the web UI and the CLI's gRPC calls. Compare its examples with the version of Argo CD you plan to install, since the flags and ports you need depend on that version. Keep a copy of the guide's commit or version in your change record so reviewers can trace which instructions your configuration followed.

How often does Argo CD release new minor and patch versions?

The Argo CD release process page states that a minor release ships four times a year, roughly once every three months. Only the three most recent minor versions receive patch releases, so older lines stop getting fixes on a fixed schedule. Plan your upgrade calendar around that rule rather than waiting for a security advisory. Confirm the current support window on the release process page before you commit to a version, because the project may update its policy. Your operations team should track which minor line you run and when it leaves the patch window.

Where can I find the current Argo CD patch releases?

The argoproj/argo-cd releases page on GitHub lists each published version with its release notes. At the time of the supplied facts, the page showed patch releases v3.5.5 (marked latest), v3.4.11 and v3.3.16, with v3.6.0 in release candidate. Those labels change as new versions ship, so check the page on the day you plan an install or upgrade. Use the release notes to confirm whether a patch touches ingress, gRPC or TLS behavior before you update a Traefik-fronted installation. Record the exact tag you deploy so you can match it to the manifests and images.

Which Argo CD release line should my Traefik setup target?

Target a minor line that still receives patch releases and that your Traefik version supports. Choose the newest line that your team can test and operate, then pin the patch version in your manifests or Helm values. Check the release process page for the current list of patch-eligible lines, and check the release notes for any changes that affect ingress or TLS. Avoid running a release candidate in production. If your environment requires a specific Traefik release, confirm compatibility in your own lab first, since the ingress guide and the release notes are the authoritative sources, not third-party blog posts.

How do I confirm that my Traefik routing matches the official guide?

Compare each setting in your IngressRoute with the ingress configuration guide, paying attention to the gRPC route, the h2c scheme, and the service port Argo CD exposes. Confirm that the web and gRPC paths resolve to the same host, and that TLS settings match the option you chose. Test the CLI with a login and a list command, and test the UI in a browser. Keep the guide version next to your manifests in Git so a reviewer can see which instructions the configuration was built from.

Does Argo CD publish its own paid edition or vendor support plan?

Argo CD is released under the Apache License 2.0, and the project itself does not sell a paid edition. The license and project status are listed on the CNCF project page for Argo, which records that Argo was accepted at the Incubating level on March 26, 2020 and moved to Graduated on December 6, 2022. Support for your environment comes from your own team, from a commercial vendor you choose, or from a services partner such as DeployOpen, which can plan, implement and support the installation. Ask any provider which versions they cover and what they will do during an upgrade.

What should I check in official sources before an Argo CD ingress change?

Check four things in order. First, confirm the Argo CD version and its patch status on the release process page and the GitHub releases page. Second, read the ingress configuration guide for the Traefik example that matches your version. Third, review the release notes for the version you plan to deploy, looking for changes to ingress, TLS or server flags. Fourth, record the sources and versions in your change ticket. This keeps the review traceable and gives your auditors evidence of which vendor instructions the team followed.

How DeployOpen scopes and delivers Argo CD ingress work

DeployOpen plans, builds, documents and supports Argo CD ingress inside your own clusters and networks, with the Traefik routes, TLS choices and access checks agreed before work starts. The result is a published Argo CD UI and gRPC CLI path that your team can operate after handover.

How we scope

The written scope names the Argo CD hostname, the Traefik version, and whether web and gRPC share one host.
It records which TLS termination model applies and which certificate source and renewal process your team uses.
Engagements are fixed-scope, and ongoing support for later Traefik or Argo CD upgrades is available as a retainer.

How we build

We configure the IngressRoute for the web UI and the gRPC CLI using the h2c scheme for gRPC traffic.
We align the Argo CD server settings with the chosen TLS model so routing and certificates do not conflict.
We test UI login, CLI login and gRPC calls from the networks your users will actually use, then record results.

How we hand over

You receive the manifests, the routing configuration and a short runbook describing each route and certificate.
We walk your platform team through the checks, the failure symptoms we tested and the rollback steps.
Documentation stays in your repository so changes to ingress go through the same review as other Argo CD configuration.

How we support

Support covers Traefik and Argo CD upgrades, with routing checks repeated after each version change.
Certificate renewal and routing changes are reviewed against the written scope before they reach production.
Confirm with us during scoping which support hours, response channels and retainer terms apply to your environment.

Exposing Argo CD with Traefik