#Updating

#Per install route

#The version check

--version prints build information and, when a newer release exists, one more line:

labdash --version
# labdash 1.4.2 (2026-07-18, commit a9f3c21)
# 1.5.0 is available

That check is a single request, cached, and it never blocks startup.

#Settings and pinned views

The settings file holds connection details, so a new binary reads the file you already have and never rewrites it without you asking.

Your pinned views, collapsed groups, sort order and last view live in the state file, which labdash owns. It migrates that file silently between versions. A state file it cannot read resets with a note rather than a startup error, and the worst case is that you pin your tabs again.

A settings file that no longer parses produces a pointed error naming the file, the line, the field, and the values allowed there. You can check one without launching the dashboard, which is how a platform team validates the file it ships to its developers:

labdash settings validate ./settings.yml

It exits non-zero on a bad file.

#Rolling back

Every release publishes signed checksums and an SBOM. Downgrading is the same command with a version pinned:

brew install labdash@1.4.2
go install github.com/giancarlosisasi/labdash/cmd/labdash@v1.4.2

Your credential store, settings file and pinned views survive a downgrade. The keyring service name, the settings directory name, and the credential file name are frozen identifiers. Changing one would make every user silently appear logged out, with no error to explain it.