Migrate DaemonCraft to a validated OVH VPS-4 shadow deployment

[nicoechaniz]

Goal

Move the DaemonCraft server-side stack from Nicolás's Lenovo Legion workstation to a dedicated OVHcloud VPS-4 only after a measured shadow deployment proves that Minecraft interaction remains responsive from Córdoba.

This is a deferred infrastructure plan. It does not authorize purchasing a provider plan, changing model providers, enabling autonomous L4 operation, or cutting over the live world without a separate explicit decision.

Why

• Free the workstation from having to host Minecraft/Purpur, Docker, the cast, and embodied services while humans play.
• Keep DaemonCraft reachable without depending on a gaming laptop staying online.
• Avoid repeating the previous Contabo migration, where advertised resources did not translate into usable Minecraft block interaction.
• Preserve a reversible local fallback until the remote stack has passed a real multiplayer rehearsal.

Evidence collected on 2026-08-28

Current DaemonCraft workload

Live measurements with CompAII online:

• Purpur TPS: 20.0 / 20.0 / 20.0 / 20.0
• tick time, 1-minute average/min/max: approximately 8.5 / 2.4 / 32.2 ms
• Minecraft container: 9.754 GiB resident, cgroup limit 14 GiB
• configured JVM heap: INIT_MEMORY=8G, MAX_MEMORY=12G
• cast + bot + agent loop: approximately 0.70 GiB
• current full application estimate: approximately 10.59 GiB
• modeled worst-case application usage: approximately 14.84 GiB
• world + Nether + End + plugins + runtime data: approximately 1.1 GiB
• view-distance=10, simulation-distance=10, max-players=20

With a conservative 2 GiB OS/Docker reserve:

RAM	Current headroom	Worst-case headroom	Assessment
12 GiB	-0.59 GiB	-4.84 GiB	impossible
16 GiB	3.41 GiB	-0.84 GiB	OOM/swap risk
24 GiB	11.41 GiB	7.16 GiB	appropriate

Existing OVH operational evidence

daimonmatrix:

• 6 vCPU / 12 GB RAM / 100 GB disk
• virtual Intel Haswell at approximately 2.4 GHz
• 17+ days uptime at measurement time
• 0% observed CPU steal while idle
• already using swap; insufficient for DaemonCraft

mona:

• 8 vCPU / 24 GB RAM / 200 GB disk — the same shape as VPS-4
• virtual Intel Haswell at approximately 2.4 GHz
• 31+ days uptime at measurement time
• dozens of production containers
• approximately 16 GB available memory and 0% observed CPU steal

This supports OVH's general operational stability in our own environment, but does not prove Minecraft single-thread performance on a newly assigned shared host.

Measured network latency from La Quintana, Córdoba

OVH region/host	Average RTT	Packet loss
Vint Hill, Virginia (vin.proof.ovh.us)	~171 ms	0%
mona, BHS Canada	~178 ms	0%
daimonmatrix, BHS Canada	~186 ms	0%
Hillsboro, Oregon (hil.proof.ovh.us)	~222 ms	0%

Vint Hill is preferred if available in the account/configurator. BHS is acceptable for a trial. Hillsboro should be avoided. The measured RTT will be perceptible compared with LAN, but should not cause blocks to reappear while TPS remains healthy; that behavior would indicate server tick/IO failure rather than latency alone.

Recommended plan

OVHcloud VPS-4 (2027 range):

• 8 vCores
• 24 GB RAM
• 200 GB NVMe
• daily provider backup
• unlimited traffic
• up to 3 Gbps public bandwidth
• advertised from USD 23.37/month on the worldwide page using pricing=upfront12

Official references:

• https://www.ovhcloud.com/en/vps/
• https://www.ovhcloud.com/en/vps/vps-usa/
• https://www.ovhcloud.com/en/vps/vps-canada/

Before purchase, verify the actual no-commit/monthly price, taxes, available datacenter, cancellation terms, and whether Vint Hill requires a separate OVHcloud US account. The advertised Local Zone offer is VPS-2 with 8 GB RAM and is not large enough.

Migration phases

Phase 0 — Purchase decision

• Confirm shortest practical billing commitment; do not assume the advertised upfront12 price is month-to-month.
• Confirm Vint Hill availability; otherwise choose BHS Canada.
• Do not choose Hillsboro.
• Confirm public IPv4, UDP support, and root access.
• Record actual invoice price and datacenter.

Phase 1 — Provision and harden

• Install Debian 13.
• Apply security updates.
• Configure SSH key-only access and least-privilege operations.
• Install Docker/Compose through the project's declared procedure.
• Join ZeroTier for private administration and service dependencies.
• Configure firewall:
  • public 25565/tcp for Java Minecraft;
  • public 19132/udp for Geyser/Bedrock if retained;
  • RCON, bot API 3003, embodied API 7790, Redis, and admin surfaces private only.
• Configure systemd units; do not enable autonomous L4 behavior.
• Verify clock, DNS, disk, memory, cgroup, and CPU steal telemetry.

Phase 2 — Shadow deployment

• Create and verify an offline-consistent local world backup (save-all flush + existing backup procedure).
• Copy the world, plugins, runtime configuration, and secrets through the sanctioned deployment path.
• Preserve local secrets outside Git.
• Deploy the current lab cast and controller mode.
• Keep public DNS/IP pointed at the local server.
• Start the remote copy on a temporary hostname/port.
• Keep the current JVM/config values unchanged for the first comparison:
  • heap 8–12 GB;
  • view distance 10;
  • simulation distance 10.
• Verify RCON, backups, bridge, embodied health, bot status, and CompAII connection.

Phase 3 — Dependency decision

The embodied service currently points to Ollama at http://10.10.20.1:11434.

Choose explicitly before claiming VPS independence:

• Keep home Ollama reachable through ZeroTier, accepting that this embodied backend disappears when home is offline; or
• approve a remote/API provider and its cost/privacy implications; or
• define another remote inference host.

Running the current 27B Ollama model CPU-only on this VPS is out of scope and not recommended.

Phase 4 — Multiplayer rehearsal

Run a 60–90 minute test with the real workload:

• Nicolás
• Sihuel
• Amélie
• CompAII
• optionally one additional agent
• Java client and, if relevant, a Bedrock client
• concurrent exploration/chunk generation
• mining, fast block placement/breaking, combat, inventory/chests, chat, agent movement, and reconnects

Collect:

• Spark/Purpur TPS and MSPT
• CPU steal
• JVM/container memory and swap
• disk latency/IO wait
• packet loss and RTT
• reconnect behavior
• human reports of block reappearance and rubber-banding

Acceptance gates:

• sustained TPS >= 19.8
• 1-minute average MSPT < 25 ms
• no sustained MSPT > 50 ms
• CPU steal ideally 0%, never sustained above 5%
• packet loss 0% during rehearsal
• no swap/OOM
• no block reappearance
• no perceptible sustained rubber-banding
• RCON, backups, bot APIs, and agent body remain healthy

Phase 5 — Bounded tuning if chunk generation is the only failure

Perform only after the exact-clone baseline:

• pre-generate the intended play region;
• test view-distance=8;
• test simulation-distance=8;
• rerun the full rehearsal and preserve before/after evidence.

If TPS/MSPT or CPU steal still fails, do not buy a larger generic shared-vCPU plan merely for more cores. Evaluate a dedicated/high-frequency CPU server instead.

Phase 6 — Reversible cutover

• Announce maintenance window.
• Stop writes and run save-all flush.
• Create and verify final local backup.
• Sync the final world delta.
• Start and verify remote services through systemd.
• Change DNS/public connection details.
• Verify Java, Bedrock if applicable, CompAII, RCON, backups, and health probes.
• Keep the local server stopped but recoverable for 48–72 hours.
• Document exact rollback command and responsible operator.

Phase 7 — Closeout

• Confirm stable runtime across at least two real play sessions.
• Verify provider daily backup plus application-consistent Minecraft backups.
• Verify monitoring/alerts and disk retention.
• Remove temporary test ports and credentials.
• Decide explicitly whether services should be enabled at boot.
• Record final architecture and operational runbook.

Rollback

Rollback is mandatory until closeout:

1. Stop the remote cast and Minecraft write path.
2. Restore public DNS/IP to the workstation.
3. Restore the last verified local world backup or reverse-sync only after validating timestamps and hashes.
4. Start local services through systemd in order: Minecraft → embodied → cast.
5. Verify RCON, controller lab, bot status, and player join.

Never run two writable copies of the same world concurrently.

Risks

Risk	Mitigation
Shared-vCPU single-thread performance	Real multiplayer rehearsal; Spark/MSPT + steal gates
170–186 ms RTT from Córdoba	Prefer Vint Hill; human block/combat test; accept only with 0% loss and healthy TPS
New chunk generation stalls	Exact baseline first, then pregeneration and distance tuning
OOM/swap	VPS-4 24 GB minimum; preserve cgroup limits and monitor
Home Ollama dependency	Explicit ZeroTier/API/remote-host decision
Corrupt/inconsistent world copy	save-all flush, offline verified backup, single writer
Provider snapshot is crash-consistent, not app-consistent	Keep existing Minecraft backup container and off-host copies
Premature irreversible cutover	Shadow deployment, temporary endpoint, 48–72h local rollback window

Non-goals

• Enabling 24/7 autonomous L4 behavior.
• Changing model/provider billing without explicit approval.
• Running a 27B model CPU-only on VPS-4.
• Sharing mona or daimonmatrix with DaemonCraft production.
• Re-architecting the game stack during infrastructure validation.
• Treating marketing vCore/bandwidth numbers as acceptance evidence.

Decision requested later

When budget and time permit, Nicolás decides:

1. purchase/commitment and datacenter;
2. home Ollama dependency vs approved remote inference;
3. whether to proceed from shadow test to cutover;
4. whether post-validation services become boot-persistent.