Argo Workflows retains old/form login domain name after Nebari domain change

[mwengren]

Hi all,

I migrated my Nebari v2025.10.2 deployment from an internal development domain to a public domain name with an associated SSL certificate.

Generally, everything went well and I'm able to use most of the Nebari services.

However, the login button in Argo workflows is still trying to redirect to the original domain for auth. The URL pattern in the browser when clicking the 'Login' button is as follows:

some.development.domain.noaa.dev/auth/realms/nebari/protocol/openid-connect/auth?client_id=argo-server-sso&redirect_uri=

Where the redirect_uri is an escaped URI string pointing to the same original Nebari domain.

How do I manually update Argo to use my new domain?

FWIW, the nebari deploy command ran successfully with the following output with my new public DNS included (which I removed to post here), so there was no indication of an issue there:

Nebari deployed successfully
Services:
 - argo-workflows -> https://<new.domain.name>/argo/
 - conda_store -> https://<new.domain.name>/conda-store/
 - dask_gateway -> https://<new.domain.name>/gateway/
 - jupyterhub -> https://<new.domain.name>/
 - keycloak -> https://<new.domain.name>/auth/
 - monitoring -> https://<new.domain.name>/monitoring/

Not sure if this is related (doesn't seem so IMO, although my Argo page pops up the same 'token not valid' error), xref'ing anyway: #1861.

[viniciusdc]

Hey @mwengren, there's definitely some caching or a missing update in a ConfigMap on the Argo pod. Do you have kubectl or k9s access in this cluster?

[viniciusdc]

If you do, can you first make sure the IngressRoutes are up to date with the new domain?

kubectl get -n dev ingressroutes.traefik.containo.us \
  -o jsonpath='{range .items[*]}{.metadata.name}{" => "}{range .spec.routes[*]}{.match}{"\n"}{end}{end}'

You should see the new domain reflected in the Host(...) rules. If the IngressRoutes look correct, then the stale value is probably coming from a ConfigMap/env var consumed by the Argo pod.

[viniciusdc]

If nothing seems wrong there, I’d try deleting the current Argo pod and letting Kubernetes recreate it, so the new pod can pick up the latest ConfigMap changes if any were missed.

If the error still persists after the pod restarts, I’d check the argocd client in Keycloak next, especially the configured redirectUri / valid redirect URI fields, to make sure the new domain is included there.

[mwengren]

Hi @viniciusdc, yes, the ingress routes look correct to me. Thanks for that query... would have taken me awhile to figure that out!

Deleting the pod did the trick. I still receive the token error message mentioned in #1861 prior to logging in, but otherwise login now redirects to Keycloak correctly.

Thanks for the quick troubleshooting help!