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 update without the in-app flow, re-run the SeqDesk installer against the existing install directory. It downloads the latest release, stages it, and activates it the same way the in-app updater does:

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

This is the supported manual update path — do not hand-extract tarballs or copy files over a live release.

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 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