Splitting Docker Across Mac + Synology NAS Without Changing DNS

Last week I posted about running production Docker apps through Cloudflare Tunnels with no open ports and no static IP. That setup works great until you run out of RAM on the Mac hosting everything.

My Mac Mini was sitting at 14.5 GB of 16 GB used. Twenty, n8n, Outline, Listmonk, Documenso, InvoiceNinja - every service fighting for the same memory. I needed to split the stack across two machines without touching DNS, without changing ports, and without my wife asking why the internet was down.

The answer: Cloudflare tunnel ingress-flip.

What Are Cloudflare Tunnels?

Cloudflare tunnels don't bind to a specific machine. They bind to tunnel connectors - lightweight daemons that can run anywhere. When you define an ingress rule connecting a public hostname to a local service, that localhost resolves on whatever machine the connector is running on.

This means you can move services between machines and simply update the ingress rule to point at a different IP address. The public URL never changes. Zero DNS updates. Zero port forwarding.

The Migration Pattern

Here's how I moved six services from the Mac Mini to the Synology DS920+:

1. Spin up a tunnel connector on the Synology NAS
2. Move a Docker stack to the NAS
3. Change the ingress rule from localhost:8080 to 192.168.1.50:8080 (wherever the service now lives)
4. Done. Zero DNS changes. Zero port forwarding.

In one session I moved Documenso, InvoiceNinja, Outline's Redis, Listmonk, and two n8n workers. The Mac dropped from 14.5 GB to 9.1 GB. No downtime anyone would notice.

The Real Story: Documenso on Apollo Lake

The migration itself was straightforward. What almost killed it was the Synology DS920+ using an Intel Celeron J4125 - Apollo Lake architecture. Documenso's Docker image ships binaries compiled with AVX2 instructions. Apollo Lake doesn't support AVX2. The container started, then immediately segfaulted with no useful error.

This is the kind of problem self-hosters hit constantly and nobody writes about because it's boring to debug. The fix: rebuild the binary from source targeting x86-64-v2, package it as a custom Docker layer, and swap it in. Took 90 minutes. The migration itself took 20.

Why This Matters

Most infrastructure content tells you how things are supposed to work. The useful stuff tells you what broke and how you fixed it. Splitting services across hosts is straightforward on paper and full of invisible architecture traps in practice.

If you're running self-hosted services on a Synology or an old mini PC, you're going to hit the AVX2 wall eventually. Build from source and target your actual CPU architecture. It is the only reliable way.

Internal Links

• How to Expose Your Docker Apps to the Internet with Cloudflare Tunnels - The foundational setup this post builds on
• The Productivity Stack Nobody's Selling You - The self-hosted Mac Mini stack mentioned here