Updating

Licence status, current version and whether an update is waiting, plus links to support, documentation and the extension manager.

The check, the changelog for the pending version, and the button that downloads it.

Every published version for this product, selectable from a list. Hidden entirely if the notes could not be fetched.

Stops and removes the backend, frontend and cron apps from PM2, then proves the frontend port (3000) and the backend port (NEXT_PUBLIC_BACKEND_PORT, default 4000) are actually free and scans for a backend process PM2 does not own. If either check fails it exits non-zero and the update stops before touching anything — a second backend on the same database during a schema migration is far worse than a failed update.

It then puts the maintenance server on those two ports: 503 JSON for anything under /api/, a 503 HTML page for everything else, both with Retry-After: 300. Port 4001 is deliberately left unbound so the migration step can use it.

pnpm stop:all removes the maintenance server too, which closes the ports entirely instead of serving a page — use it only when you want the site to be visibly down.

Runs pnpm install -r --no-frozen-lockfile, then verifies that every declared dependency and every executable the rest of the chain shells out to actually resolves, and repairs the tree if they do not.

This is not belt-and-braces. When a release changes dependency resolution, pnpm rebuilds the root store but leaves backend/node_modules in place, and its links now point at store paths that were just replaced. A dangling link is not an empty directory — it looks present and fails at require() time, so the symptom is the backend dying on Cannot find module 'bullmq', one package per restart, with nothing saying "your install is incomplete".

If it cannot produce a working tree it stops the update rather than let a schema migration run against a backend that cannot boot. The message tells you which of the three usual causes to check: a full disk, something still running and holding files open, or a damaged pnpm store.

Sequelize applies the schema during boot, so the migration step is a boot. It runs backend/dist/index.js directly — not under PM2, so nothing can restart it behind your back — with the scheduler switched off and boot restricted to the schema phase, on the first free port from NEXT_PUBLIC_BACKEND_PORT + 1 upward (4001–4020 on a default install).

It then waits for GET /api/settings to answer, which is the observable that says initialisation finished, and kills the process. The cap is 180 seconds. A very large schema legitimately needs longer:

node scripts/updator-migrate.js --timeout=600000

If it exits early or never becomes ready, nothing is seeded and the site stays on the maintenance page — which is the correct place to stop, because the alternative is seeders writing through models the database does not match yet.

Schema behaviour is controlled by DB_SYNC in .env: lazy (the default) syncs only what changed, using the fingerprint in backend/.sync-hash; none authenticates without altering anything; always forces a full ALTER sync, which is the escape hatch when the schema has drifted outside Sequelize. force drops and recreates every table and destroys all data — never set it on a live install.

Writes the rows the code expects to exist: permissions, roles, deposit gateways, notification templates. It runs through the new models, which is exactly why it comes after the schema step and never before it.

Rebuilds frontend/.next. This is not optional and it is not skippable to save time.

Every NEXT_PUBLIC_* value is inlined into the browser bundle when the frontend is built. NEXT_PUBLIC_SITE_URL is the origin every client-side API call uses and the hostname in the next/image allowlist. An un-rebuilt frontend serves the previous release's pages against the new backend, and if you also changed the domain, the browser calls the old one and images 400.

The backend needs no equivalent step: backend/dist ships pre-built inside the release package.

Clears maintenance mode and starts the three PM2 apps from production.config.js: backend on NEXT_PUBLIC_BACKEND_PORT, frontend on 3000 (hardcoded — it is not moved by .env), and cron on 4001 with CRON_MODE=only. Nothing should ever connect to 4001; the port exists only so the scheduler process does not collide with the backend.

Setting CRON_MODE=inline in .env drops the cron app entirely and schedules jobs inside the backend process instead, so you will see two apps rather than three.

The chain stopped at one of its links. Read the last error it printed — every failure mode above prints what to check. Nothing is left half-applied: the schema step will not have seeded, and the extraction step rolls itself back.

To bring the site straight back up on whatever code is currently on disk:

pnpm start

The extractor snapshots every file it overwrites into .update-backup-<timestamp> at the project root before writing, and restores the lot if any single file fails. There is nothing to undo by hand — the tree is the pre-update one. Fix the cause (almost always a full disk or a permissions problem on the project tree) and download again.

Delete a leftover .update-backup-* directory only after you have confirmed the platform is healthy on the new version.

78 is EX_CONFIG, used by the platform for "this box is not configured to run this". It means one of two things: Redis is unreachable, or Node is on an unsupported major version. Supported majors are 22, 24 and 26 — the range is fixed by the prebuilt WebSocket binaries the backend ships, not by preference. Every PM2 config treats 78 as a stop rather than a crash, so the app will sit there stopped instead of looping.

An incomplete dependency install, not a bad release. Re-run pnpm updator; the install step detects and repairs dangling links. If it recurs on every run, you almost certainly have two different pnpm versions on the machine fighting over the same node_modules — which -a pnpm will show them.

A leftover from a previous version that the release deleted. Run pnpm clean:stale --check to see it, then pnpm clean:stale to remove it, and rebuild with pnpm build:frontend.