[Idea] Swarm IP heartbeat to SuperAdmin + route53 sync (reachable across EC2 IP changes)

[johnson-johns-codes-openez]

Summary

When a swarm's EC2 instance restarts (stop/start, maintenance, or recycling), AWS can assign it a new public IP. The swarm then becomes unreachable at its previous address, and its route53 record (see #516 / #484) points to a stale IP until someone fixes it manually.

Proposal: each swarm reports its current public IP to SuperAdmin once every 5 minutes. SuperAdmin stores the last-known IP per swarm and, if it changed, updates the swarm's route53 record. Swarms stay reachable across IP changes with zero manual intervention.

Proposed steps

1. Heartbeat sender in the swarm: a small service similar to the existing cln / down / btc / sphinx / tome binaries under src/bin/ that every 5 minutes:
   • resolves the instance's public IP (EC2 instance metadata service, with a fallback for non-EC2 environments)
   • POSTs it to SuperAdmin (/swarm/heartbeat with swarm id + public IP)
2. Heartbeat endpoint in SuperAdmin (src/bin/super/routes.rs): accepts the heartbeat, stores last_ip + last_heartbeat_at per swarm, and compares the IP against the previously stored one.
3. route53 update (src/bin/super/route53.rs): when the reported IP differs from the stored IP, upsert the A record for the swarm's domain, reusing the route53 helpers already in place for swarm setup.

Storage

Keep last_ip and last_heartbeat_at on the swarm record, persisted the same way other swarm state is stored in SuperAdmin.

Notes

• The heartbeat doubles as a liveness signal and could later feed into the alerts described in superadmin: Alerts for ec2 or services going down #553.
• This exact task is also posted on Sphinx Bounties (250,000 sats, https://bounties.sphinx.chat/bounties/cmlkyjw7u0005ky04n7c43jdh). It has been assigned there since Feb 2026 with no visible completion; if the current assignee is no longer active, I would be glad to implement it and open a PR.

Pros / Cons

• Pros: no manual intervention after IP changes; complements superadmin: Alerts for ec2 or services going down #553 alerting; small, contained change
• Cons: adds a lightweight 5-minute heartbeat request per swarm; requires one new SuperAdmin endpoint

[johnson-johns-codes-openez]

Quick self-correction after digging into the repo — good news: this feature already exists in master, which changes the useful question to "is the bounty stuck?".

What I found:

• Swarm side: src/cron_jobs/public_ip.rs + src/service/public_ip.rs (commits 4477365 2026-02-13, 4966c9d 2026-02-16) — each swarm checks its public IP via EC2 metadata every 5 min (cron 0 */5 * * * *) and reports changes to superadmin.
• Super side: /super/update_child_public_ip route + src/bin/super/service/child_swarm/update_public_ip.rs (d5ee441 2026-02-16, f3a8e83 2026-02-17) — superadmin updates the route53 A record on IP change, with later fixes: concurrency (3b79540 2026-04-09) and Route53 domain restoration with tests (41b9411 2026-06-09).

So on bounties.sphinx.chat:

• "swarm service discovery" (250k sats) — implementation appears complete in master.
• "review and deploy" (100k sats, log group tags and migration #609) — PR merged 2026-02-21.

Both are still listed as ASSIGNED (since Feb 2026) with no payout. Looks like the close/payout side of the workflow stalled rather than the work itself — worth a check on your end.

If either of those needs a final review, closing out, or leftover follow-up work, happy to help. One optional follow-up I noticed: the bounty text says "ping its own IP to superadmin once every 5 minutes" — the current implementation only pings on IP change. A true periodic heartbeat would also give a liveness signal that could feed the #553 alerts; that's a small change I can put up as a PR if useful.