[Feature][Grafana][config-ui] Gaps when running DevLake with a managed PostgreSQL and an external Grafana

This is a tracking issue for several separate gaps, so pick one item and work only on it. For the Grafana side, start in grafana/scripts/entrypoint.sh, where DATABASE_SSL_MODE and the hard-coded admin user are read, and check docker-compose-dev-postgresql.yml and env.example for the missing pass-through. For the config-ui side, start in nginx.conf for the external-Grafana redirect and in config-ui/routes/onboard/step-4.tsx and components/card.tsx for the Check Dashboard button. Done means the chosen item works as described with defaults unchanged.

Search before asking

• I had searched in the issues and found no similar feature requirement.

Use case

We run DevLake in Kubernetes with a managed PostgreSQL (TLS with a
corporate CA, sslmode=verify-full) and want to use a managed / external
Grafana. Data sources are GitHub, GitLab, Jira and SonarQube.

The backend handles this setup fine (DB_URL is passed unchanged to pgx, so
sslmode=verify-full&sslrootcert=… works). The gaps are in the dashboard image
(grafana/scripts/entrypoint.sh) and in the config-ui. This issue collects
them in one place, so that the small PRs below can refer to it.

Description

Verified on main @ 4ad2f66df, PostgreSQL mode only. We do not run MySQL,
so MySQL paths are left unchanged and untested.

A. Dashboard image ↔ managed PostgreSQL over TLS (one small, additive PR planned)

• DATABASE_SSL_MODE is read by entrypoint.sh (default disable), but
  docker-compose-dev-postgresql.yml / env.example do not pass it
  through (follow-up to #9207). Proposal: GRAFANA_DATABASE_SSL_MODE
  → DATABASE_SSL_MODE, default disable.
• The PostgreSQL datasource payload has no sslRootCertFile /
  sslCertFile / sslKeyFile, so verify-ca / verify-full against a
  private CA fails. Proposal: optional DATABASE_SSL_ROOT_CERT
  (+ _CERT / _KEY) → jsonData.tlsConfigurationMethod: "file-path".
• The API calls use a hard-coded admin: user. Renaming the admin via
  GF_SECURITY_ADMIN_USER silently breaks datasource creation, because
  the POST status is not checked. Proposal: ${GF_SECURITY_ADMIN_USER:-admin}
  plus a status check with a log message.
• The entrypoint deletes all datasources on every start ("clean
  slate"). This is destructive when the Grafana state is shared (GF_DATABASE_*,
  several replicas, manually added datasources). Proposal for the PR: an
  opt-out DATASOURCE_CLEAN_SLATE=false. The default stays true, so
  the current behaviour is unchanged.

B. config-ui ↔ Grafana links (one small bug-fix PR planned)

• With USE_EXTERNAL_GRAFANA=true, nginx.conf returns
  302 "${GRAFANA_ENDPOINT}" and drops the path and query, so every
  /grafana/d/<uid>/… deep link lands on the Grafana home page. Proposal:
  append the remaining path + $is_args$args.
• Onboarding "Check Dashboard" (GitHub / GitLab,
  routes/onboard/step-4.tsx, components/card.tsx) calls
  window.open(import.meta.env.DEVLAKE_DASHBOARD_URL_*). The released
  image is built without a .env and the code has no fallback, so the
  button opens an empty tab. The example values in config-ui/env.example
  point to the MySQL UIDs (KXWvOFQnz, msSjEq97z), while the PostgreSQL
  dashboards use …-pg. Proposal: a DB-independent fallback (e.g.
  /grafana/dashboards?query=GitHub), or hide the button when the
  variable is empty. Also document the PostgreSQL UIDs.

C. Open points, no PR planned for now (feedback welcome)

• Clean slate, alternatives to the opt-out: (i) delete only the DevLake
  datasource (UID devlake-postgres-api / devlake-mysql-api), or
  (iii) switch to file provisioning with env interpolation instead of the
  API.
• Root-level dashboards ClaudeCodeAdoption*.json, Incidentio.json,
  Linear.json and Rootly.json reference the MySQL datasource
  devlake-mysql-api, but are also shipped in PostgreSQL mode, where they
  show datasource errors. Moving them to dashboards/mysql/ (plus
  PostgreSQL variants), and adding a dashboard-check rule against files
  directly under dashboards/, would fix this.
• DEVLAKE_GRAFANA_PATH / DEVLAKE_DASHBOARD_URL_* are build-time only
  (Vite envPrefix). With relative /grafana/… links and the redirect
  fix from B this is fine for us. Runtime configuration (e.g. an
  env-config.js generated by nginx.sh) would only matter for setups
  with different dashboard UIDs or a non-default Grafana org. Noted here
  for completeness.

Related issues

• #5009 — config-ui image support for optional/external Grafana (introduced USE_EXTERNAL_GRAFANA)
• #9207 — Grafana against an external database via Compose (GRAFANA_DATABASE_*)
• #4286 — deploying DevLake in a production setting

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

I will open the PRs for A and B one after another and link them here. They
are small and additive, and the defaults are unchanged.

Code of Conduct

• I agree to follow this project's Code of Conduct