Udash, the Updatecli DASHboard

Udash is the Updatecli Dashboard, a web application that collects and displays Updatecli reports, giving your team a centralised view of software update activity across all your repositories.

The chart deploys two workloads:

An optional Ingress routes:

• / → udash-front
• /api → udash-server

• Kubernetes 1.19+
• Helm 3.x
• CloudNative-PG operator (when cnpg.enabled: true, which is the default)

Install the CNPG operator before installing this chart, and use --wait to ensure the operator pod is fully ready (including its admission webhook) before proceeding:

helm repo add cnpg https://cloudnative-pg.github.io/charts
helm upgrade --install cnpg \
  --namespace cnpg-system \
  --create-namespace \
  cnpg/cloudnative-pg \
  --wait

Without --wait, the operator pod may not be ready when the chart creates the Cluster resource, causing: failed calling webhook "mcluster.cnpg.io": no endpoints available for service "cnpg-webhook-service".

If you prefer to bring your own PostgreSQL instance, set cnpg.enabled=false and supply the connection URI via secrets.database.stringdata.uri.

helm repo add updatecli https://updatecli.github.io/charts
helm repo update

helm install udash updatecli/udash

By default the chart provisions a CNPG Cluster and injects credentials automatically. Just install the CNPG operator first (see Prerequisites), then:

helm install udash updatecli/udash

Disable CNPG and supply your own connection URI:

helm install udash updatecli/udash \
  --set cnpg.enabled=false \
  --set secrets.database.stringdata.uri="postgres://user:pass@postgres:5432/udash?sslmode=disable"

Authentication is off by default: the API accepts unauthenticated requests and the frontend shows no login UI. Enable it with the auth block, which configures both components at once.

helm install udash updatecli/udash \
  --set auth.enabled=true \
  --set auth.issuer="https://auth.example" \
  --set auth.clientid="my-client-id" \
  --set "auth.audience[0]=https://udash.example/api"

Register udash-front as a User Agent / SPA client using PKCE. The redirect URI is derived from the browser origin and front.appBasePath rather than configured directly, so register https://<your front host><front.appBasePath> as both the allowed redirect URI and the post-logout redirect URI. helm install prints the exact URL for your values.

Accepted with or without a scheme — https:// is assumed when omitted. It must match the iss claim your provider puts in its tokens exactly, including any trailing slash: Auth0 issues one, Zitadel and Keycloak do not. A mismatch rejects every token.

The chart writes this to both sides — server.auth.visibility for the API and AUTH_VISIBILITY for the SPA. They must agree, and the frontend defaults the key to private where the API defaults to public, so letting the chart set both is the point. AUTH_VISIBILITY needs udash-front >= v0.25.0; older images ignore it and always ask for a login before showing data.

Udash has three permissions, in increasing order: viewer, publisher, admin. Publishing reports requires publisher. The server maps identity provider roles onto them through auth.roles:

auth:
  roles:
    claim: realm_access.roles          # where your provider puts the roles
    mapping:
      admin: ["udash.admin"]
      publisher: ["ci-bot", "udash.publisher"]
    default: viewer                    # nobody matched -> least privilege

Set auth.roles.claim in oidc mode. Only zitadel mode infers it. Left empty, the server reads no roles at all, every authenticated identity falls back to auth.roles.default (viewer), and nobody can publish. The server logs a warning saying so at startup.

auth.roles.mapping is keyed by Udash permission, not by provider role. Left empty it defaults to udash.admin / udash.publisher / udash.viewer.

With authentication enabled the API issues personal access tokens (prefix udash_pat_) that updatecli can use to publish. auth.roles.resolver decides what a token is allowed to do: snapshot (the default) freezes the permission its creator had at issue time, while zitadel re-reads the creator's current grants on use and therefore requires auth.mode: zitadel. auth.roles.cacheTTL bounds how long a resolved permission is reused.

Left empty, the frontend requests openid profile email offline_access (offline_access enables silent token renewal). Zitadel additionally requires the project audience scope urn:zitadel:iam:org:project:id:<PROJECT_ID>:aud, or the API rejects the token:

--set auth.scope="openid profile email offline_access urn:zitadel:iam:org:project:id:123:aud"

auth.mode=zitadel uses Zitadel's own authorization SDK instead of generic JWT validation, and needs a service account key. Provide it inline, or reference a Secret you manage yourself:

auth:
  enabled: true
  mode: zitadel
  zitadel:
    domain: my-instance.region.zitadel.cloud
    keyFile:
      existingSecret: my-zitadel-key
      key: key.json
  roles:
    mapping:
      admin: ["udash.admin"]

Access is granted through auth.roles rather than a single required role. In this mode the chart also points the SPA at auth.zitadel.domain, so auth.issuer is not needed.

The key is mounted into udash-server at /etc/udash-auth/, deliberately outside /etc/udash/, which the configuration ConfigMap already occupies.

Version requirements. Runtime auth configuration reached udash-front in v0.23.0; AUTH_VISIBILITY in v0.25.0. Releases up to v0.22.0 had authentication compiled into the bundle at build time, so they show no login UI regardless of these values. On the API side the oidc mode and the roles model need udash v0.17.1. The chart pins images that satisfy all of this.

Routes udash.example.com/ to the front and udash.example.com/api to the server:

helm install udash updatecli/udash \
  --set ingress.enabled=true \
  --set ingress.className=traefik \
  --set "ingress.hosts[0].host=udash.example.com"

Serves the front at app.example.com/updatecli and the API at app.example.com/api. The front ingress must strip the /updatecli prefix before forwarding to nginx so that the nginx container always receives paths starting with /. Configure the SPA base path to match via front.appBasePath.

nginx ingress controller (uses rewrite-target + use-regex):

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
  hosts:
    - host: app.example.com
  paths:
    front: "/updatecli(/|$)(.*)"   # regex captures the suffix to pass as $2
    server: "/api"                  # no rewrite needed; server handles /api natively

front:
  appBasePath: "/updatecli"  # must match the path prefix (without regex)
  apiBaseUrl: "/api"

Traefik — set ingress.traefik.stripPrefix.enabled: true and the chart creates the StripPrefix Middleware CR and wires its annotation into the Ingress automatically. Requires Traefik CRDs (traefik.io/v1alpha1) to be installed in the cluster:

ingress:
  enabled: true
  className: traefik
  hosts:
    - host: app.example.com
  paths:
    front: "/updatecli"
    server: "/api"
  traefik:
    stripPrefix:
      enabled: true   # creates the Middleware CR and injects the router annotation

front:
  appBasePath: "/updatecli"
  apiBaseUrl: "/api"

Note: front.appBasePath tells the SPA JavaScript router which path prefix to use for client-side navigation. It must always match the un-rewritten path (e.g. /updatecli). The API server does not need a strip-prefix because it handles /api natively.

Routes the front and API to different hostnames. Set front.apiBaseUrl to the absolute API URL so the browser knows where to reach the server:

front:
  apiBaseUrl: "https://api.udash.example.com/api"

ingress:
  enabled: true
  className: traefik
  hosts:
    - host: udash.example.com
  tls:
    - secretName: udash-tls
      hosts: [udash.example.com]
  server:
    host: api.udash.example.com
    tls:
      - secretName: udash-api-tls
        hosts: [api.udash.example.com]

Serves the front at domain.example/project and the API at api.domain.example/updatecli. Set ingress.traefik.stripPrefix.enabled: true and the chart automatically creates all needed Traefik Middlewares and wires their annotations:

• Front: StripPrefix /project → nginx receives /
• Server: StripPrefix /updatecli → AddPrefix /api → backend receives /api/*

Requires Traefik CRDs (traefik.io/v1alpha1) to be installed:

front:
  appBasePath: "/project"
  apiBaseUrl: "https://api.domain.example/updatecli"

ingress:
  enabled: true
  className: traefik
  hosts:
    - host: domain.example
  paths:
    front: "/project"
    server: "/api"
  traefik:
    stripPrefix:
      enabled: true   # creates Middlewares for both front and server automatically
  server:
    host: api.domain.example
    path: "/updatecli"

The chart renders:

helm uninstall udash

Authentication was reworked into a single top-level auth block, and the server-side schema was renamed to follow udash v0.17.1:

auth.mode: oauth is now rejected by the chart, because udash v0.17.1 renamed the mode to oidc and refuses to start on the old value rather than silently serving an open API. The chart fails the render with a message pointing at the rename.

New in this release: auth.roles.* (see Roles and permissions) and AUTH_VISIBILITY for the SPA. Both images are bumped — udash v0.17.1 and udash-front v0.25.0 — which is the minimum for the above.

Upgrading the server to v0.17.1 runs two new migrations on first boot (000012_create_api_tokens, 000013_alter_pipelineReports_attribution).

The <release>-auth Secret is no longer created. It was referenced by no workload, and none of its contents were secret — a public SPA publishes its client ID, issuer and audience to every browser that loads it. Only the Zitadel service account key gets a Secret now.

If you never set readonly: false, no action is needed. If you did, note that the previous release did not actually apply your OAuth settings: they were written as flat keys the server never read, so auth was effectively enabled with an empty issuer. Move them to the new block and authentication will work for the first time.

Autogenerated from chart metadata using helm-docs v1.14.2