upgrade-basilisk

name	upgrade-basilisk
description	Upgrade the basilisk binary on Basilisk mainnet RPC nodes from the snapshots server and restart the blockchain service. Use when asked to "upgrade basilisk", "update basilisk binary", "deploy new basilisk", or similar.
allowed-tools	Bash, Read

Upgrade Basilisk RPC Node

Replaces /data/bin/basilisk on a Basilisk mainnet RPC host with the latest build from https://snapshots.play.hydration.cloud/basilisk and restarts blockchain.service. The snapshots URL always serves the current release build.

Known hosts

Basilisk mainnet RPC nodes (basilisk-mainnet-rpc-01..03):

• 147.135.255.106
• 141.95.2.178
• 146.59.47.189

If the user says "all basilisk RPC nodes" or doesn't specify, ask which host(s) — don't assume all three.

Prerequisites

• SSH access as user Mrq with passwordless sudo on the target host. The user's local SSH key must already be authorized.
• Outbound HTTPS from the host to snapshots.play.hydration.cloud.

Layout on each host

• Binary: /data/bin/basilisk (owner basilisk:basilisk, mode 750)
• Service: blockchain.service (systemd, runs /usr/local/bin/run_node.sh as user basilisk)
• Wrapper: /data/bin/run_node.sh — usually doesn't need touching during a binary swap

Workflow

Step 1 — Inspect the host

ssh Mrq@<HOST> 'sudo ls -la /data/bin/basilisk; sudo -u basilisk /data/bin/basilisk --version; sudo systemctl is-active blockchain.service'

Record the current version so you can report old → new in the summary.

Step 2 — Download new binary to a staging path and verify

ssh Mrq@<HOST> 'sudo curl -sSfL -o /data/bin/basilisk.new https://snapshots.play.hydration.cloud/basilisk \
  && sudo chmod +x /data/bin/basilisk.new \
  && sudo chown basilisk:basilisk /data/bin/basilisk.new \
  && sudo -u basilisk /data/bin/basilisk.new --version'

If --version fails or prints garbage, abort — the binary is corrupt or unsupported on the host.

Step 3 — Back up, swap, restart

ssh Mrq@<HOST> 'set -e
DATE=$(date +%Y%m%d-%H%M%S)
sudo cp -p /data/bin/basilisk /data/bin/basilisk.bak-$DATE
sudo mv /data/bin/basilisk.new /data/bin/basilisk
sudo chown basilisk:basilisk /data/bin/basilisk
sudo chmod 750 /data/bin/basilisk
sudo systemctl restart blockchain.service
sleep 5
sudo systemctl is-active blockchain.service
sudo -u basilisk /data/bin/basilisk --version'

cp -p preserves the original mode/owner on the backup. Keeping .bak-<timestamp> files in /data/bin/ is the rollback path — mv it back and restart if anything goes wrong.

Step 4 — Verify the node is syncing

After restart, tail the journal briefly to confirm the node is importing blocks and connecting to relay-chain RPC peers:

ssh Mrq@<HOST> 'sudo journalctl -u blockchain.service -n 30 --no-pager'

Look for:

• Parachain id: 2090
• [Relaychain] Trying to connect to next external relaychain node followed by a successful connection
• [Parachain] Imported #<N> lines within ~1–2 minutes

Step 5 — Multiple hosts

If upgrading multiple hosts in one request, run Steps 2–3 in parallel (one Bash call per host, sent in the same message). The hosts are independent — there's no coordination requirement.

Reporting

Summarize per host: old version, new version, backup filename, service state. Mention any non-fatal warnings in the journal (e.g. deprecated CLI flags) so the user can clean them up in run_node.sh later.

Rollback

ssh Mrq@<HOST> 'sudo mv /data/bin/basilisk /data/bin/basilisk.failed-$(date +%s) \
  && sudo cp -p /data/bin/basilisk.bak-<TIMESTAMP> /data/bin/basilisk \
  && sudo systemctl restart blockchain.service \
  && sudo systemctl is-active blockchain.service'