Expose ArgoCD UI with Ingress (2026)

Argo CD’s UI is a powerful tool for visualizing and managing your Kubernetes deployments, but by default, it’s only accessible from within your cluster. To make it available to the outside world, you’ll typically use an Ingress controller. This isn’t just about convenience; it’s about enabling secure, managed access to your CI/CD pipeline.

Let’s see Argo CD running with an Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP" # Or HTTPS if ArgoCD is configured for it
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # If using cert-manager
spec:
  ingressClassName: nginx # Or your specific ingress controller class
  tls:
  - hosts:
    - argocd.example.com
    secretName: argocd-tls-secret # Kubernetes secret containing your TLS certificate
  rules:
  - host: argocd.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 80

This Ingress resource tells your Ingress controller (like Nginx, Traefik, or HAProxy) to:

• Listen for requests on argocd.example.com.
• Forward those requests to the argocd-server service within the argocd namespace.
• Use port 80 on that service (Argo CD’s UI typically runs on HTTP internally, even if you expose it via HTTPS externally).
• Optionally, manage TLS certificates using cert-manager and store them in argocd-tls-secret for secure HTTPS access.

The core problem Argo CD’s Ingress solves is bridging the gap between the internal Kubernetes network and the external world, providing a single, stable entry point for users to interact with their deployments. It leverages the capabilities of an Ingress controller to handle load balancing, SSL termination, and path-based routing, abstracting away the complexities of direct service exposure.

Internally, Argo CD’s UI is served by a deployment named argocd-server. This deployment exposes a service, also named argocd-server, which is a ClusterIP service by default. This means it’s only reachable from within the cluster. The Ingress resource acts as a sophisticated proxy, selecting specific traffic (based on hostname and path) and directing it to this internal argocd-server service. The Ingress controller itself is a separate deployment that watches Ingress resources and configures its own routing rules accordingly.

The key levers you control are:

• Hostname (host): This is the public-facing domain name users will type into their browser.
• Path (path): While typically / for the main UI, you could route specific Argo CD API endpoints or even different Argo CD instances to different paths if needed.
• Service Name and Port (backend.service.name, backend.service.port.number): This points to the internal Kubernetes service that actually runs the Argo CD UI.
• TLS Configuration (tls): This section is crucial for enabling HTTPS, specifying the domain, and indicating the Kubernetes secret where the certificate and private key are stored.
• Ingress Class (ingressClassName): This tells Kubernetes which specific Ingress controller should manage this Ingress resource.

When Argo CD is configured to use HTTPS internally (which is good practice), the backend-protocol annotation might need to be set to HTTPS if your Ingress controller is also performing the TLS termination and you want the connection between the Ingress controller and the argocd-server service to be encrypted. However, it’s common to have the Ingress controller handle TLS termination (decrypting traffic from the client) and then communicate with the backend service over plain HTTP, especially if the connection is within a trusted network.

The most surprising thing is that Argo CD’s Ingress configuration doesn’t directly involve Argo CD’s own settings; it’s entirely managed by Kubernetes Ingress resources and the Ingress controller. Argo CD itself is unaware that it’s being exposed via an Ingress; it just listens on its configured port, and the Ingress controller directs traffic to it.

Once you have your Argo CD UI exposed via Ingress, the next logical step is to secure it further with authentication and authorization mechanisms, ensuring only authorized users can access and manage your deployments.