Draft Recommendation: Rebuild Oconto’s Docker Platform Around a Clean Local Swarm

This is a draft architecture recommendation, not an implementation record. I inspected the candidate machines, dockerlab01, the DigitalOcean public host, and the reachable ESXi endpoint on October 4, 2026. I made no infrastructure changes.

Hardware update: Michael subsequently confirmed that the available Pi fleet is two Raspberry Pi 5 systems and two Raspberry Pi 4 systems, with a 128 GB-class USB drive attached to each. The fourth Pi 4 was not part of the original live inspection, so its address, memory, media type, and health still need verification.

The short version: build a new Swarm rather than repairing the abandoned one, put it on a dedicated container VLAN, keep the manager quorum entirely inside Oconto, and be honest that Swarm only makes the stateless portion of this estate highly available. Stateful services need SSD-backed placement, application-native backups, and tested restores. SugarCove should be a separate recovery plane, not a manager across the WAN. The current DigitalOcean public edge should stay in place until the home platform can prove recovery and failback.

What is actually sitting on the network

The three inspected addresses are not mystery servers. They are members of an older Raspberry Pi Swarm that has been dormant long enough to become a liability. The confirmed fourth Pi 4 materially improves the clean-slate topology, even though it still needs a live baseline.

• 10.7.7.101 is Docker-Pi4-01: Debian 12 on a four-core Raspberry Pi 4 with 3.7 GiB of RAM. Its 235 GiB root filesystem has about 216 GiB free. Docker still believes it belongs to a Swarm, but the node is stuck in a pending state and points at three old manager addresses.
• 10.7.7.103 is Docker-Pi5-01: Debian 12 on a four-core Raspberry Pi 5 with 7.9 GiB of RAM. Its root filesystem is 96 percent full, with roughly 11 GiB free. Docker cannot load the old Swarm certificate because it expired in January 2026.
• 10.7.7.104 is Docker-Pi5-02 with the same CPU and memory class. Its root filesystem is also 96 percent full, with roughly 9.6 GiB free. Its old Swarm certificate expired in February 2026.

All three inspected Pis expose unused 114.6 GiB SanDisk USB devices, but those devices are not mounted for Docker. Michael confirms equivalent 128 GB-class USB capacity on the fourth Pi. The inspected Pis have current NTP synchronization. Docker is installed, but none carries a useful live workload today; the stopped containers are mostly residue from Portainer and the former Swarm.

That matters because the right first move is not certificate surgery. It is a clean rebuild. The old cluster has no production workload worth preserving, its former manager at 10.7.7.100 does not answer the tested ports, and stale Raft identity is more risk than asset.

dockerlab01 is busy, not redundant

dockerlab01 is an Ubuntu 24.04 VMware guest with eight vCPUs, about 11.7 GiB of RAM, an 80 GiB system disk, and a 256 GiB data disk mounted at /srv. Docker stores its data under that second disk. At inspection time it had 64 containers in total, 56 running, and 32 active Compose projects.

The workload includes NetBox, Paperless, n8n, Paperclip, Discourse, Pi-hole, Homebox, Homarr, Mealie, Vikunja, AdventureLog, PriceBuddy, Uptime Kuma, Portainer, Backrest, several media-management services, and a set of older dashboard applications. Some are tiny. Others carry PostgreSQL, MySQL, MariaDB, PostGIS, Redis or Valkey, Qdrant, SQLite databases, media mounts, or direct access to the Docker socket.

dockerlab01 still had about 4.4 GiB of available memory during the snapshot, but its 4 GiB swap allocation was effectively full. That does not prove a current outage; it does prove that this is not the moment to add orchestration overhead and another batch of applications without first adding memory or moving work away.

The ESXi management endpoint is reachable, but I did not find an approved ESXi credential in Aura’s vault, so I could not verify host-level RAM, datastore headroom, or the number and placement of other guests. Any VM sizing below is therefore a design target, not a claim that the hypervisor can already satisfy it.

The target topology

I recommend a three-manager Oconto control plane built entirely from the Pi fleet:

• Manager 1: the first Raspberry Pi 5 after a clean rebuild onto its 128 GB USB data drive.
• Manager 2: the second Raspberry Pi 5 after the same remediation.
• Manager 3: one Raspberry Pi 4 on its 128 GB USB data drive.

Keep those three managers inside Oconto, but they do not need to be manager-only. In this small cluster I would leave them at Swarm availability active and allow selected lightweight ARM services with explicit CPU and memory limits. Keep databases, image builds, media processing, and other noisy or stateful work off them so application pressure cannot destabilize quorum. Three managers tolerate the loss of one manager, and the arrangement removes ESXi from the control-plane quorum: if the hypervisor disappears, the managers remain available.

The fourth Pi becomes the ARM worker for lightweight, verified multi-architecture services. dockerlab01 remains the first x86 worker, and a new or resized ESXi VM becomes the second. Based on the current host’s workload and swap history, the target x86 worker should start around eight vCPUs and 24 GiB of RAM, with at least 300 GiB of SSD-backed local data capacity. That is a planning floor pending ESXi inspection, not a capacity reservation.

The USB drives improve capacity and let Docker leave the SD-card roots, but capacity is not endurance. Before a Pi becomes a manager, verify whether its device is an SSD or high-endurance flash, check health where the device supports it, use a Linux-native filesystem, and prove that Docker’s data root and Swarm state survive reboot. Cheap thumb drives should not be trusted with Raft state merely because they report 128 GB.

This revised design preserves control-plane quorum if ESXi disappears and provides a dedicated ARM worker. It still does not create full x86 compute redundancy, because dockerlab01 and another ESXi VM share one physical failure domain. Stateless services built for both amd64 and arm64 can fail over to the Pi worker. x86-only images and pinned databases cannot. A second physical x86 host is the eventual answer if host-level application redundancy is the goal.

Put the Swarm on a new VLAN

I agree with moving away from the inherited 10.7.7.x placement. Create a dedicated container-infrastructure VLAN and a new private /24, but choose the actual VLAN ID and prefix only after checking NetBox and UniFi for conflicts. The article deliberately does not invent a supposedly free number.

The firewall policy should be narrow:

• Allow TCP 2377 among manager and joining nodes.
• Allow TCP and UDP 7946 among Swarm nodes for discovery.
• Allow UDP 4789 among nodes for overlay traffic.
• Allow SSH and management interfaces only from the administration network.
• Expose applications through a controlled reverse-proxy path rather than giving every container a LAN address.
• Permit only the outbound destinations each stack needs.

The present host contains an IPvLAN network as well as ordinary Compose bridges. That model needs a service-by-service review. Most web applications should move behind one or two replicated ingress proxies on overlay networks. Services with real Layer-2 requirements, especially DNS or DHCP, may be safer as deliberate singletons outside the general routing mesh.

Swarm does not solve storage

This is the most important caveat in the recommendation. A Swarm task can move to another node; its local volume cannot. If a PostgreSQL container restarts elsewhere while its data remains on the old node, the scheduler has produced downtime, not availability.

Use three storage patterns:

• Stateless replicas: frontends, proxies, workers, converters, and simple tools can run two or more replicas across eligible nodes.
• Pinned single-writer state: databases, Qdrant, SQLite applications, Discourse, and similar workloads stay on named SSD-backed nodes with placement constraints. They get restart automation, not pretend database HA.
• Shared bulk data: media and document trees can use the NAS where the application semantics allow it. Do not place live database files on generic NFS merely to make them look portable.

Every stateful migration should begin with a database-native dump or application-consistent backup, continue through an isolated restore, and end with a health check plus a real read-and-write test. Restic can protect the resulting artifacts and volumes, but “the backup job was green” is not a restore test.

Mixed architectures are useful, but they impose a tax

The Pis are arm64. dockerlab01, ESXi guests, and DigitalOcean are amd64. Swarm can constrain services to matching nodes, but it cannot make an amd64-only custom image run on a Pi. Before any service is declared redundant, its image manifest must be checked and its behavior tested on both architectures.

Official images for common infrastructure often support both platforms. Custom images and old snapshots may not. Pinning an x86-only service is valid, but it means that service has no Pi failover. For internally built software, publish multi-architecture images only where the build and test pipeline can continue to support both architectures; otherwise accept explicit x86 placement.

Where SugarCove fits

Do not put a Swarm manager at SugarCove. Raft quorum belongs on a low-latency, reliable local network. A WAN partition should not be allowed to trigger manager elections or complicate recovery at the primary site.

SugarCove is more valuable as an independent failure domain: a Restic repository, a receiver for database dumps, and eventually a warm standalone Compose host for a small set of critical services. Promotion can be manual and documented. If a future experiment joins it to the Swarm, use it only as a labeled worker for stateless, restart-tolerant jobs over the site-to-site path. That is capacity, not quorum and not stateful HA.

Do not rush the DigitalOcean move

The DigitalOcean host currently runs 13 containers on one vCPU and about 1.9 GiB of RAM. Its 48 GiB disk is 76 percent used. It carries the public Caddy edge, three WordPress sites with MariaDB, Wiki.js with PostgreSQL, Brackets, two Stupid Little Cups deployments, and SearXNG.

Moving those services home immediately would trade a small cloud bill for dependence on residential power, ISP availability, firewall changes, and the immature storage plan described above. It would also collapse the separation between public services and the home control plane. My recommendation is to keep the public web edge in DigitalOcean for now and improve its recoverability instead.

The first candidates for a later return are a test deployment and other noncritical services, not the three public WordPress databases. Repatriation should require an off-host backup, an isolated restore, a home ingress and TLS test, a DNS rollback plan, an observation window, and a proven failback. Public production stays in the cloud until all of those gates pass.

A practical migration sequence

1. Repair the foundation. Baseline the fourth Pi, export anything still worth keeping from the fleet, remove the abandoned Swarm identity, rebuild all four Pis with Docker on their USB data drives, reclaim the full roots, establish the VLAN, and confirm time, DNS, MTU, and firewall behavior.
2. Prove the platform. Initialize the new three-Pi manager quorum, label architecture and storage capabilities, deploy ingress and the selected management agent, then run one stateless canary. Power off or drain one node and verify what actually happens.
3. Move low-risk applications. Start with IT-Tools, KMS, simple frontends, converters such as Tika and Gotenberg, and monitoring components. Preserve dockerlab01 definitions as rollback material.
4. Move stateful stacks one at a time. Begin with lower-impact applications, then advance to Paperless, n8n, NetBox, Discourse, and the media stack only after each backup passes an isolated restore. Pin state explicitly and define a rollback window.
5. Revisit public services last. Keep DigitalOcean authoritative until the new environment survives node loss, backup loss, restore, DNS rollback, and failback exercises.

Recommendation

Proceed with Docker Swarm, but scope the promise correctly. It can give Oconto a clean control plane, consistent deployment, placement rules, rolling updates, and genuine redundancy for stateless services. It will not turn 32 Compose projects and their local databases into automatic high availability.

The immediate approval I would request is for design and remediation only: choose the new VLAN, verify ESXi capacity, baseline the fourth Pi, rebuild all four Pi storage paths, establish the three-Pi manager quorum, create one properly sized x86 worker, and run a stateless failure test. An ESXi manager VM is no longer necessary. Do not migrate production state or change public DNS in that phase.

If those tests pass, the migration can proceed stack by stack with measurable gates. If they do not, independent Compose hosts plus tested recovery remain better than a cluster that is redundant only on paper.

Sources and method

• Docker: Administer and maintain a swarm of Docker Engines
• Docker: Manage Swarm service networks
• Docker: Deploy services to a swarm
• Direct read-only host inspection performed by Aura on October 4, 2026. Resource readings are snapshots, not capacity guarantees.

No secret was printed or persisted. No node, container, network, DNS record, or cloud service was changed during this investigation.