Updating

Updating

Whichever way this was installed — the "Docker only, minimal footprint" choice or a full checkout (see Installation Guide), Docker or Local Node.js process — updating later is the same one command, run from the install directory:

cd /opt/fondwaypoints   # or wherever this was installed to
./update.sh

update.sh is always there next to .deploy-state.json, regardless of footprint — the wizard writes it during install (see scripts/lib/footprint.js), so there's nothing extra to fetch or remember before you can update.

What it does

update.sh reads .deploy-state.json to find out which footprint this install actually is, then:

Docker only, minimal footprint

Since there's no source checkout left to git pull in this case, update.sh instead:

1. Shallow-clones the latest release into a fresh scratch directory (installing git/Node.js first if either is missing — a Docker-only host may never have needed them before).
2. npm install in that scratch clone.
3. Runs node <scratch>/scripts/update.js --mode minimal --final-dir <install dir>, which — via the same trimToMinimalFootprint the wizard used for the original install — resolves the image again per whichever source is recorded in .deploy-state.json (pull, normally, or a rebuild from the fresh scratch clone on a CPU that can't run the published amd64-only image — see Installation Guide), regenerates the (self-contained, no build context) docker-compose.yml and nginx/nginx.conf.template at the install directory in case either changed upstream, brings the stack up, and deletes the scratch clone again once done.

Full checkout

1. Refuses to continue if git status --porcelain shows local changes — commit or stash them first, so an update can't silently overwrite something you edited by hand.
2. git fetch --tags (unshallowing first if this was a --depth 1 clone, so any release tag is reachable, not just whatever commit was at HEAD when first installed), then checks out the newest v* release tag — or origin/master if no release tags exist yet.
3. npm install (dependencies may have changed).
4. Runs node scripts/update.js --mode full, which reads .deploy-state.json/.env and re-runs the exact same bring-up code the wizard used originally (scripts/lib/bringUp.js): docker compose ... up -d --build/pull for Docker, or npm run build-css + systemctl restart for Local Node.js process.

Either way, .env, certs/, and anything else you customized at the install directory are left alone — only the application code/image and the generated compose files are refreshed.

Automatic updates

The setup wizard's "Enable automatic updates" checkbox (off by default) installs a weekly cron entry — 0 3 * * 0, every Sunday at 03:00 — running update.sh --auto, which suppresses interactive output and appends to logs/update.log instead (see scripts/lib/bringUp.js's installAutoUpdateCron). Nothing else changes: it's the exact same update, just unattended. crontab -l shows the entry once installed; crontab -e to remove it if you'd rather go back to manual-only.

You can also just run ./update.sh --auto by hand any time — the only difference from a plain ./update.sh is where the output goes.

Uninstalling

uninstall.sh is the reverse of install.sh — curlable the same way, and destructive:

curl -fsSL https://raw.githubusercontent.com/j5guy/fondwaypoints/master/uninstall.sh | bash -s -- --yes

It targets /opt/fondwaypoints by default (--dir/FONDWAYPOINTS_INSTALL_DIR to point at another install, same as install.sh), reads .deploy-state.json there to find the deploy mode/service name, then removes, best-effort:

• The Docker stack — containers, named volumes (uploads/logs/backups/mongo data), images, and the compose network. Works against either footprint: it builds the docker compose -f ... overlay list from whichever compose files actually exist at the install directory (all the overlays for a full checkout, just the one self-contained file for a minimal footprint), then does a second pass filtering by name (fondwaypoints*) to catch anything a mismatched project name would otherwise leave behind.
• The systemd service and its unit file, if this was a Local Node.js process install.
• The host nginx site config (and its sites-enabled symlink), if "Existing nginx" was enabled — then reloads nginx.
• The auto-update cron entry, if one was installed.
• The install directory itself, entirely — .env, certs/, the source checkout, all of it.
• Any leftover install.sh/update.sh scratch directories under /tmp from a run that didn't finish cleanly.

Drop --yes to get a confirmation prompt listing all of the above before it does anything. Ends with a verification pass (same idea as scripts/reset-for-testing.sh, which this is adapted from) confirming no Fond-Waypoints-related containers/volumes/images/networks or install directory are left.