6 · Update a running cluster

Two scripts keep a cluster current — they are not interchangeable:

	Keeps	Use when
update.sh	secrets, databases, WireGuard, topology — everything	shipping a new version
deploy.sh	nothing (clean slate: fresh secrets, wiped DBs)	lost or broken state

Update — master and workers, same command

update.sh downloads the latest release tarball from R2 itself, auto-detects master vs. worker, rebuilds, and restarts. No rejoin, no data loss.

On the master:

sudo /opt/gridweave/deploy/update.sh

It rebuilds the Compose services + the Ray-head image and re-applies the k8s manifests.

On each worker (same command):

sudo /opt/gridweave/deploy/update.sh

It rebuilds the worker, vLLM, and proxy images and restarts the Gridweave systemd units.

• A worker update bounces running endpoints on that node (they need a stop
• start to pick up the new worker image) — update before pre-warming, not after.
• SKIP_R2=1 skips the download and rebuilds from the files already on disk (pre-release testing).

Re-deploy from scratch

Every deploy.sh run tears the master and every control VM down to a clean slate (containers, volumes, network, WireGuard, k3s + KubeRay + the RayCluster, CometBFT) and redeploys — it never reuses a stale .env, Postgres volume, or WG config, so re-running after a broken/partial deploy just works. GPU nodes re-join afterward (guide 1).

Remove a single worker

On that node — one script deregisters it from the master (WireGuard peer + Ray worker group), stops the k3s agent, and brings the tunnel down. Images are kept for a fast re-join; add --uninstall to remove k3s and all images too:

sudo /opt/gridweave/deploy/leave-node.sh

Full decommissioning (master or worker): see Removing Gridweave.