Skip to main content
Mangrove is one binary with the dashboard built in. Upgrading means building a new binary and swapping it in. Running apps keep running throughout.

Upgrade

Why copy then move, instead of copying straight over the binary: the running process still has the old file open. Overwriting it in place can crash it or fail with “text file busy”. A mv within one filesystem is atomic: the old process keeps its file until it exits. Build the dashboard before the binary. A binary built first embeds the old dashboard (or none at all). On a small box, build somewhere with disk to spare, not in a RAM-backed /tmp.

What happens on restart

  • Database migrations run automatically at startup. They only move forward; there are no down migrations.
  • Apps are untouched. Containers keep running and Caddy keeps routing to them while Mangrove restarts.
  • Sessions survive. Nobody is signed out.
  • Open dashboard tabs pick up the new version on their next full page load.

Roll back the binary

If the new version ran a migration, the old binary may not understand the new schema. Take a backup before upgrading across anything that changes the database, and restore it if you need to go back.

Unit files

If an upgrade changes files in deploy/systemd/, copy them over and reload systemd before restarting:
Or re-run sudo ./setup.sh, which does all of the above and is safe to repeat.