Updates & Maintenance

SeqDesk updates itself from the admin panel. This section explains the mechanism in enough detail that you can predict what happens when something goes wrong, because the honest summary is: the application code is trivially reversible; the database is not.

The mental model

A packaged install is a release layout. Each version lives in its own directory under releases/, and the live application is whichever one the current/ symlink points at:

<root>/
  current -> releases/1.1.125
  releases/1.1.124/
  releases/1.1.125/
  settings.json          # shared, symlinked into every release
  data/  pipelines/  pipeline_runs/
  backups/

An update never edits the running tree. It downloads and verifies the new release, unpacks it into a staging directory, installs its dependencies there, and only then flips current/ in a single atomic operation. If anything fails before that flip, the running version was never touched. If anything fails after it, the flip is reversed.

Rolling back is therefore just pointing current/ at the previous release directory. There is no file restoration step and no .update-backup/ directory.

What is not reversible

Migrations run with prisma migrate deploy, which is forward-only. Once a release has migrated the schema, moving the current/ symlink back does not un-migrate it.

SeqDesk mitigates this in two ways, and you should know both:

• A pre-migration logical backup. Before migrations run, the updater takes a best-effort pg_dump -Fc into <root>/backups/pre-update-<timestamp>.dump. That dump is your restore point. It is best-effort: if pg_dump is not available the update proceeds without one and the failure message says so.
• A data-loss abort. Record counts for sequencing orders, samples, studies and users are snapshotted before and after the migration. If any count drops, the update aborts and reverts the symlink — but the schema is already migrated, and the abort message names the backup to restore.

Everything else — your database contents, settings.json, data/, pipelines/, pipeline_runs/ — is shared at the install root and survives both updates and rollbacks untouched.

Where to start

• Routine update? Automatic Updates walks the flow from Check now to restart, with every safeguard and error the routes actually produce.
• Something is broken and you need the previous version back? Manual Update & Rollback covers the one-click rollback, the manual symlink swap, and what to do about the database.
• Not sure whether the install is healthy? Run seqdesk doctor first — it reports on the layout, the current/ symlink target, database connectivity and the HTTP endpoint.

Neighbouring sections

• Installation — how the release layout is created in the first place, and what the seqdesk launcher can and cannot do afterwards.
• Configuration — settings.json lives at the install root and is symlinked into each release, which is why an update never loses it.
• seqdesk doctor — the diagnostic to run before and after any update that misbehaves.