Moving Dashboards from Docker to K8s

[HaruspexSan]

Hi everyone,

For my Master’s Thesis, I’m building a BI pipeline where users develop dashboards in Local Docker and deploy them to Production K8s (Helm) via Git. This makes developing on branches easier.

Current (Brittle) Process:
Manual UI Export → Add folder in repo → Mounted via ConfigMap → sed used in an init script to swap DB credentials.

The Goal:
A "Single Source of Truth" where dashboards are imported automatically without manual string manipulation or GUI intervention.

Questions:

Environment Parity: How do you handle differing SQLAlchemy URIs between environments? Is there a best practice for using environment variables or consistent UUIDs?

Import Automation: For K8s, is it better to use initContainers with the Superset CLI or sync via the API?

Tooling: Are there recommended CLI tools or GitHub Actions for managing "Dashboard-as-Code"?

Overall: is there a smarter way to do this?

[cookesan]

I would base this on Superset's import/export bundle flow, not on editing exported files with sed.

A practical GitOps shape is:

superset export_dashboards -f dashboards.zip
superset export_datasources -f datasources.zip

Commit those bundles, or commit the unpacked YAML if your workflow validates the bundle structure. In Kubernetes, run the corresponding import from an init job or release job after migrations and before users start relying on the dashboards:

superset import_datasources -p /path/datasources.zip -u admin
superset import_dashboards -p /path/dashboards.zip -u admin

The key is to make environment-specific things stable outside the dashboard JSON/YAML: database connections, secrets, SQLAlchemy URIs, and ownership. Import datasources/databases first, then dashboards. Avoid rewriting UUIDs or IDs unless you have a deterministic migration step and tests, because those identifiers are how the exported objects refer to one another.

For Helm, keep secrets in Kubernetes secrets or extraSecretEnv, and put import commands in a controlled job/hook rather than a long-running web pod startup script.