HydraIssues

Summary

Issue #408 lists hydraneck under "Phase 2 — move with care" because its server is a
cx33 (4 cores / 8 GB), the largest in the Hydra stack. On inspection that framing is
wrong: hydraneck itself uses 28 MB. The 8 GB is for an unrelated TP-Link Omada
WiFi controller sharing the same box.

Splitting these apart moves hydraneck into Phase 1 and isolates the real decision.

Measured on hydraneck.experiencenet.com (2026-07-28, up 5d 23h)

Mem: 7751 MB total, 2702 MB used, 5048 MB available, load 0.06

Docker: omada-controller / mbentley/omada-controller:latest, up 6 days, healthy.

Server type confirmed via hcloud: hydraneck is cx33 (4 cores / 8.0 GB).
Note hydraneck/CLAUDE.md currently claims cx23 — that doc is stale and worth
correcting separately.

What this means

hydraneck is a Phase 1 service. At 28 MB it fits the hydraskin default profile
(512 MiB cap) with ~18x headroom, alongside the other lightweight Go binaries. It
has no special storage or network requirement beyond what any land service has.

The Omada controller is the actual open question and has nothing to do with the
Hydra migration except that it happens to be co-tenanted. It is:

• third-party, not ours to slim down
• Java with a 1 GB max heap plus MongoDB — realistically ~2.5-3 GB to run comfortably
• stateful (the Mongo database holds WiFi site config and historical stats)
• already containerised, as a Docker image

Options for the Omada controller

1. Run it as a scale on a hydraskin node. The hydraskin default profile already
   sets security.nesting: true, so Docker-in-Incus works. It would need a per-scale
   override (limits.memory 3GiB, and a larger root size for the Mongo data) and
   would dominate a Pi 5 8GB — better suited to an Intel N150 / 16 GB worker.
2. Move it to dedicated hardware. It manages physical WiFi APs, so hosting it at
   the venue it serves may be more sensible than in a datacentre.
3. Keep it on Hetzner and shrink the box once hydraneck moves off, since without
   hydraneck it no longer needs to be co-located with anything.

Whichever is chosen, the Mongo volume needs a migration plan — this is the one piece
here with real state.

Suggested next steps

• Move hydraneck itself in Phase 1 with the other Go services.
• Decide the Omada controller separately against the options above.
• Once hydraneck is off, re-evaluate whether that cx33 is still the right size.

Related

• #408 — Hydra stack migration (this splits hydraneck out of its Phase 2 entry)
• #406 — HydraSkin container host role