Skip to Content
Updates & MaintenanceManual Update & Rollback

Manual Update & Rollback

SeqDesk does not keep a .update-backup/ directory. Instead, every release lives in its own directory and the live application is whichever release the current/ symlink points at. Rolling back means pointing current/ at a previous release — there is no file restoration step.

Release Layout

A release-layout install is organized under a single root directory:

<root>/
  current -> releases/<active-version>   # atomic symlink to the live release
  releases/
    1.1.111/                             # previous release (kept for rollback)
    1.1.112/                             # active release
  data/                                  # shared, symlinked into each release
  pipelines/                             # shared
  pipeline_runs/                         # shared
  seqdesk.config.json                    # shared config, symlinked into each release
  start.sh                               # wrapper -> current/start.sh

The data/, pipelines/, pipeline_runs/ directories and seqdesk.config.json live at the root and are symlinked into each release, so they are shared across versions and survive updates and rollbacks. The root start.sh is a thin wrapper that cds into current/ and runs that release’s start.sh, which ends in exec node server.js.

Run seqdesk doctor to diagnose a broken install — it reports on the layout, the current/ symlink target, database connectivity, and the HTTP endpoint.

Rollback

From Admin → Settings → Software Updates, use Roll back release. This calls POST /api/admin/updates/rollback, which re-points current/ at the previously recorded release and restarts the application. The button is available whenever a previous release is recorded (it surfaces automatically after a failed update). Rollback is only available for release-layout installs.

If the in-app action is unavailable, re-point the symlink by hand:

Stop the server

# pm2
pm2 stop seqdesk
 
# user systemd service
systemctl --user stop seqdesk
 
# system systemd service
sudo systemctl stop seqdesk

From the install root, point current at the prior release directory:

cd <root>
ls releases/                       # find the previous version
ln -sfn releases/1.1.111 current   # atomic replace of the symlink

Restart the server

./start.sh

Or via your process manager (pm2 restart seqdesk, systemctl --user restart seqdesk, or sudo systemctl restart seqdesk).

Migrations are forward-only (prisma migrate deploy). If the release you are rolling away from applied new migrations, the schema is already migrated; rolling the application back does not revert the database. Restore a database backup if an older application version is incompatible with the migrated schema.

Manual Update

To start an update manually, use Admin → Settings → Software Updates, choose Check now, review the release, and choose Install update. That flow downloads, verifies, stages, migrates, and activates the new release.

Upgrading the npm launcher does not replace an already-installed application. The following command is configuration-only and deliberately skips the release download:

npx seqdesk@latest -y --reconfigure --dir <dir>

Use it only to reapply configuration. Do not hand-extract tarballs, copy files over a live release, or use --overwrite-existing as an update substitute. If the application cannot start, use the manual rollback above to restore the previous release, then retry the built-in update.

Database Considerations

  • SeqDesk updates never overwrite your PostgreSQL data directly.
  • Migrations are applied with prisma migrate deploy from the active release and are forward-only.
  • The update aborts automatically if sequencing order/sample/study/user counts drop after migrations, leaving the previous release active.

SeqDesk’s update and rollback flow — including the data-loss abort above — is covered by automated end-to-end tests that run before every release.

Backup Strategy

The release directories cover application code only. For full disaster recovery:

  • Database — back up PostgreSQL regularly with your own snapshot/dump strategy
  • Configuration — version-control the shared seqdesk.config.json
  • Sequencing data — the shared data/ directory is not managed by SeqDesk; use your own backup system
  • Pipeline outputs — back up the shared pipeline_runs/ directory if needed