Upgrading

Upgrading

HashTasker upgrades are binary swaps. Database schema changes are applied automatically on startup.

Procedure

1. Read the changelog's Upgrade Notes for every version between yours and the target.
2. Build the new binaries (make build in Server/), or download a release.
3. Back up the database:

   cp /opt/HashTaskerGo/hashtasker.db /opt/HashTaskerGo/hashtasker.db.bak

4. Upgrade the server first:

   sudo systemctl stop hashtasker-server
   sudo cp hashtasker-server changelog.md /opt/HashTaskerGo/
   sudo systemctl start hashtasker-server
   sudo journalctl -u hashtasker-server -n 50 --no-pager

   Copy changelog.md too, or the in-app Changelog page will show the old one.
5. Upgrade each worker:

   sudo systemctl stop hashtasker-worker
   sudo cp hashtasker-worker /opt/HashTaskerGo/
   sudo systemctl start hashtasker-worker

6. Hard-refresh the browser (Ctrl+Shift+R) to drop cached assets.

Stopping a worker kills its running hashcat processes, so upgrade workers between jobs where possible.

Compatibility

• New server, old workers: works in push mode. Workers ignore fields they do not know.
• New workers, old server: works. Missing fields default safely.
• NFS mode requires every worker to be v1.3.0 or later. See Wordlist Modes.

Version-Specific Notes

Version	Note
v1.3.2	Webhook message text uses -- instead of an em dash. Build uses make instead of build.sh.
v1.3.1	First start rebuilds the users table once to drop a legacy email constraint. Back up first.
v1.3.0	Adds wordlist_mode (server) and wordlists_path (worker). Push remains the default.
v1.2.0	Enables 45-day job auto-delete, which applies retroactively on first start.

Rolling Back

Stop the server, restore hashtasker.db.bak, put the old binary back, and start it. Schema additions from a newer version are harmless to older binaries, but the backup is the safe path.