Description
## 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
```
| Process | RSS | What it is |
|---|---|---|
| `hydraneck.service` | **28 MB** (cgroup), peak 31 MB | the Go service |
| `java -Xmx1024m` | 1979 MB | TP-Link Omada EAP Controller |
| `mongod` (port 27217) | 194 MB | Omada's bundled database |
| dockerd + containerd | 135 MB | hosting the Omada container |
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