Summary

Assessment of migrating the 10-server Nimsforest stack off Hetzner Cloud to self-hosted infrastructure. Current cost is approximately 45 EUR/month.

Current Hetzner Inventory (Nimsforest Stack)

Migration Priority

Phase 1 — Move first (lightweight land services)

Land servers are likely lightweight Go services that can run as Incus containers (scales) on hydraskin nodes.

• land-nimsforest-one
• land-shared-one
• land-tenant-*-one (6 servers) — these are identical per-tenant instances, perfect candidates for containerization. Could run as 6 scales on a single hydraskin node.

Phase 2 — Move with care

• docker-registry — needs persistent storage for container images. Could move to a hydraskin node with NVMe, but need to ensure sufficient disk space and consider using Hetzner Storage Box as backend.

Phase 3 — Keep on Hetzner (or move last)

• neoremote (4c/8GB) — DECIDED: moving to a Mac mini (hardware already purchased). Not a hydraskin candidate; it leaves Hetzner for dedicated hardware rather than becoming a scale.

Technical Considerations

• Per-tenant lands are ideal for containers — 6 identical instances doing the same thing is the perfect containerization use case. Instead of 6 Hetzner VMs, run 6 scales on one hydraskin node.
• Docker registry — if the registry is only used for CI/CD builds, consider replacing with GitHub Container Registry (ghcr.io) to eliminate the server entirely.
• neoremote — resolved: a Mac mini has been purchased for it. No Pi/Incus sizing question remains.

Target Architecture

The 8 land servers (nimsforest + shared + 6 tenants) could consolidate onto a single hydraskin node running 8 Incus containers. Each land service likely needs less than 256MB RAM as a Go binary, so even a 4GB Pi could host several.

Cost Impact

Current Hetzner Nimsforest stack: ~45 EUR/month (~540 EUR/year)
After migration of Phase 1 (8 land servers): saves ~36 EUR/month
Remaining: docker-registry (~4.50 EUR) + neoremote (~8 EUR) = ~12.50 EUR/month

Combined with Hydra stack savings, total potential Hetzner reduction from ~130 EUR/month to ~25-30 EUR/month for services that must stay (WebRTC, Perforce, neoremote, docker-registry).

Dependency

Depends on hydraskin role being implemented first — see issues.experiencenet.com issue 406 (HydraSkin: Container host role for low-cost nodes).

Update 2026-07-28 — neoremote resolved

neoremote is moving to a Mac mini that has already been bought. It is no longer an
open item in this assessment and is not a hydraskin/Incus candidate — it moves to
dedicated hardware rather than becoming a scale.

That clears the largest Phase 3 blocker here. The only Nimsforest server still genuinely
open is docker-registry (Phase 2, needs persistent storage), so theremaining Hetzner
footprint for this stack drops to ~4.50 EUR/month once neoremote is in service.

Plan of action per server (2026-07-28) — corrected inventory

Two things in the original assessment turned out to be wrong on inspection.

Correction 1 — the lands are not "lightweight Go services"

This issue assumed each land is a Go binary needing "<256MB RAM". They are
actually Docker hosts. Every land runs dockerd (70–111MB) + containerd
(42–60MB) + journald, hosting ~8 service containers each pulled from
registry.nimsforest.com, plus a land.service on the host.

So this is not "8 services → 8 scales". It is 8 VMs hosting ~64 containers.

Example — land-shared-one: landconfigregistry, nimsforestmaddy,
nimsforestwebviewer, landregistry, nimsforeststripe, nimsforestecommerce,
mycelium, nimsforest.

Correction 2 — the tenant names in the inventory above are wrong

There is no land-tenant-1..6. The real servers, with measured memory:

BLOCKER — the images are amd64-only

docker image inspect on the running images reports amd64/linux for
nimsforest:v0.84.0, mycelium:v1.3.0 and landregistry:v0.6.2, and the
registry publishes no arm64 manifest.

The Pi fleet therefore cannot host any of this today — not as OCI scales, not
as system containers, not as VMs. An amd64 guest on an arm64 host means emulation,
which is not viable in production.

This is the key asymmetry with the Hydra stack (#408): those are Go binaries where
arm64 is a one-line Makefile change. Here it means multi-arch buildx across ~20
image repos. Nimsforest needs either that image-pipeline project, or amd64
hardware (the Intel N150 worker), before anything can move.

Recommended target: system container per land, on amd64

Assuming amd64 hardware, prefer a system container over a VM:

Same lift-and-shift, no redesign, but at container density instead of VM density.
A VM is only warranted if a land needs kernel isolation or a different kernel.

Per server

Longer-term option: land as an Incus project

Once (or if) multi-arch images exist, a land could stop being a Docker host
entirely: model each land as an Incus project and each service container as an
OCI scale inside it. That drops dockerd + containerd + journald per land
(~250MB × 8 ≈ 2GB) and the images are already OCI, so incus remote add nimsforest https://registry.nimsforest.com --protocol=oci would consume them
directly. The hydraskin-project helper on each node already creates projects
that inherit the node's default profile.

This is a redesign, not a migration, and it is not a prerequisite — it can be done
per service, incrementally, after the lift-and-shift.

Order

1. Decide amd64 worker hardware, or start the multi-arch image pipeline
2. Lift-and-shift lands as system containers
3. docker-registry with a persistent volume
4. Optionally flatten to projects + OCI scales later