Running a node means babysitting releases: spotting a new version, downloading, verifying, swapping the binary, restarting, and hoping it comes back up. I wrote a small, self-contained tool that does all of that on a schedule and is built so it can’t leave a node down. Sharing it here in case it’s useful to other operators.
Repo + docs: GitHub - vvmmaann/nym-node-autoupdate: Safe auto-updater for nym-node: systemd timer, checksum-verified, auto-rollback · GitHub
Install (run as root):
curl -fsSL https://raw.githubusercontent.com/vvmmaann/nym-node-autoupdate/main/nym-node-autoupdate.sh -o nym-node-autoupdate.sh && sudo bash nym-node-autoupdate.sh
What it does
- Installs a systemd timer that checks hourly and updates only when a new STABLE release is out (skips pre-releases).
- Auto-detects your role (mixnode / entry / exit gateway) and shows you what it found before touching anything — nothing to configure by hand.
- Updates
nym-node on every role; on gateways it also updates the QUIC bridge and the exit-tunnel iptables rules (network-tunnel-manager).
Why it won’t break your node
nym-node is SHA-256 verified and refuses to install without a checksum.- After each swap it health-checks the service and auto-rolls-back if it doesn’t come back up.
- Firewall changes are snapshotted and reverted if the tunnel stops passing traffic.
Handy
- Read-only check anytime (no root):
./nym-node-autoupdate.sh check
- Opt out of any part via
/etc/nym-node-autoupdate.conf
- Remove:
sudo nym-node-autoupdate.sh uninstall
Trust model (stated plainly)
The QUIC bridge and the tunnel-manager script ship no upstream checksum, so those steps trust GitHub + the nym org — same as updating them by hand. nym-node itself is checksum-gated. Set NTM_ENABLED=0 to skip the firewall part.
I’m running it on my 4 nodes (2 gateways + 2 mixnodes). Feedback and PRs welcome.
2 Likes
Update - a few things landed since this went up.
The big one: it now has a Telegram companion, Nymi. Link a node (nym-node-autoupdate.sh link @yourtelegram) and Nymi pings you the moment the updater does something worth knowing - your node updated, a health-check rollback fired, or the node went offline - plus release / stake / stress alerts and an on-demand /status. It also adds a /update button that force-updates a node right now instead of waiting for the hourly timer. The node never holds a bot token - it authenticates with a per-node secret it generates itself. Full writeup: Nymi - my auto-updater, my checker, and a 3-year-old mascot walk into a Telegram bot.
Now works on systemctl --user nodes. If your nym-node runs as a lingering non-root user under systemctl --user rather than a system unit, the updater detects and drives it correctly now, instead of only seeing system-scope units.
NTM stays correct across releases (exit gateways). On a release that touches tunnel/firewall behavior, the updater now reads the operator changelog (not the dev one) to decide whether to re-run network-tunnel-manager - still pinned to the release commit, still snapshot-and-rollback protected.
Safety pass. Removed the changelog command auto-execution outright: the updater no longer evals anything fetched from the network - changelog commands are only surfaced for you to run by hand. Nymi’s calls are HTTPS-only and secret-authenticated. The whole thing (updater + Nymi) went through a security review.
Get the new stuff - update the script and link your node in one line:
curl -fsSL https://raw.githubusercontent.com/vvmmaann/nym-node-autoupdate/main/nym-node-autoupdate.sh -o /usr/local/sbin/nym-node-autoupdate.sh && chmod +x /usr/local/sbin/nym-node-autoupdate.sh && /usr/local/sbin/nym-node-autoupdate.sh link @yourtelegram
then press Start in @nyminodebot. Fresh installs ask for your @nick at the end and do it for you.
Repo (README now covers Nymi): GitHub - vvmmaann/nym-node-autoupdate: Safe auto-updater for nym-node: systemd timer, checksum-verified, auto-rollback · GitHub
1 Like
I have just installed the autoupdater and also added the telegram integration. Looks very nice so far.
Thanks for providing this tool!
1 Like
Welcome! Share any thoughts, bugs and improvements about it anytime!
Security update: pairing to Nymi changed
Since the updater now ties into Nymi and can be told to force-update from Telegram, the way a node links itself to you was the weak point, and it’s been reworked.
What changed. It used to link a node to you by a Telegram handle sent from the node (link @nick). The problem: anyone who knew a node’s public IP could send that and claim it. That’s gone. The new command is nym-node-autoupdate pair @yourhandle, run on the node, and it proves control by the pairing request coming from the node’s own IP. One step, on the box, and only after that can the bot force-update it. From the bot side, /addnode stays watch-only (alerts, no control); pairing is what unlocks force-update.
What still holds (unchanged, but worth stating in a security note): nym-node is SHA-256 verified against the release’s own checksums and refuses to install on a mismatch (or on no checksum, unless you explicitly override); the swap is atomic; a health check runs after restart with automatic rollback if the service doesn’t come back; a lock file prevents overlapping runs; and nothing fetched from the network is ever executed (changelog commands are surfaced for you to run by hand, never run for you).
Honest on the trust boundary. nym-node has that independent checksum verification. The QUIC bridge and the exit-gateway tunnel manager are fetched over HTTPS from the Nym GitHub and run without an independent checksum, which is the same trust as running Nym’s documented install by hand; where possible that fetch is content-pinned to a commit SHA, the tunnel step is opt-out, and any firewall change it makes is snapshotted first and reverted if an egress probe fails afterwards.
1 Like