Skip to main content
🛠 This page is for engineering teams self-hosting their own Lightdash instance. If you’re on Lightdash Cloud, upgrades are handled for you automatically.
Lightdash uses semantic versioning in the form major.minor.patch. Each segment signals how significant the changes are and what level of care you should take when upgrading.

​
How Lightdash versioning works

  • Patch versions (x.x.PATCH) are small fixes. These are safe to pick up as part of routine upgrades.
  • Minor versions (x.MINOR.x) introduce new features or bigger changes that are backwards incompatible. Review the release notes before upgrading.
  • Major versions (MAJOR.x.x) introduce breaking changes. You must read the upgrade guides below before upgrading.
Major version bumps can happen because the API or the self-hosted architecture has changed substantially. Expect to make configuration, infrastructure, or integration changes when moving between major versions.
Before upgrading a production deployment, check the release-safety signal for your upgrade span — it tells you whether a rolling update is safe and whether there are required stops on the way.Then follow the upgrade runbook for the step-by-step sequence, the migration command reference, and the recovery and rollback paths.

​
Monitor security advisories

GitHub Security Advisories are the canonical source for published Lightdash vulnerabilities. Docker Hub and Docker Scout can provide supplemental findings, but pulling an image does not subscribe your team to security notifications and existing containers do not update automatically. DevOps teams can opt in to automated monitoring by polling GitHub’s public repository-advisories API every six hours:
The endpoint does not require authentication. Follow the Link response header when it is present and use ETag with If-None-Match to avoid downloading unchanged results. Persist each advisory’s ghsa_id, updated_at, and a hash of its normalized content, then alert when an advisory is new or either value changes. The content hash is necessary because GitHub can update affected-product metadata without advancing updated_at. A non-null withdrawn_at means the advisory was withdrawn. Compare your deployed version against each applicable vulnerabilities[].vulnerable_version_range with a SemVer library. Treat an advisory without patched_versions as affected until the advisory says otherwise. The advisory’s html_url is the canonical remediation guide. You can obtain the running version from the unauthenticated health endpoint:
If your deployment manifest pins lightdash/lightdash:<version>, you can use that version instead. See the Lightdash security policy for a cache-aware polling example and the complete operator contract.

​
Local deployments

If you’re running Lightdash on your own laptop using Docker, you just need to instruct Docker to pull the latest version of Lightdash:
Now restart Lightdash and you’ll be upgraded to the latest version. For a security update, pull the advisory’s fixed version explicitly and verify the deployed container was replaced.

​
Kubernetes/helm deployments

If you install Lightdash into kubernetes using our community helm chartsyou need to update your helm chart repository and upgrade your deployment.
For a production deployment, follow the full sequence in the upgrade runbook: back up, check the span, upgrade, then watch migrations land.

​
Update the Lightdash CLI

Your Lightdash CLI version should match the version of Lightdash you’re running. After upgrading your deployment, make sure anyone using the CLI also upgrades it — otherwise commands like lightdash preview and lightdash deploy may behave unexpectedly. See Upgrading your Lightdash CLI for instructions.

​
Upgrade guides

​
Upgrading from Version 0 to Version 1

Coming soon.