Keep the Pod boundary intact while Mesh sits beside the app
A sidecar belongs in the same Pod as the workload because the Pod already gives both containers the same network namespace and lifecycle. Mesh can handle the network path without forcing the application container to know anything about Mesh internals. That keeps the app image clean and avoids host-level package installation.
The practical change is small. The application still listens on its own ports and still behaves like a normal container. Mesh becomes the companion container that handles the connection into Cloudflare One. If the app already works behind a local proxy or service mesh style setup, the shape will look familiar, just with less ceremony.
What changes in the application, and what does not
The application usually does not need code changes just to live beside the Mesh container. It still binds to localhost or the Pod network, depending on how the workload is written. The main shift is in how traffic enters and leaves the Pod.
What does not change is the app’s container image and its runtime contract. It does not need Mesh packages baked in. It does not need host configuration. It also does not need to care whether the Pod was started by Docker Compose, a Kubernetes StatefulSet, or another OCI-compatible runtime.
Make the Pod survive registration and traffic hand-off
Mesh sidecars work best when the container lifecycle stays separate from the registration state. If the node identity lives only inside the image layer, a rebuild or reschedule can wipe it and force a fresh join. That is fine for temporary jobs, but awkward for a long-lived Pod that needs a stable Mesh presence.
A better pattern is to keep persistent registration state outside the container filesystem layer. In Kubernetes, that usually means a volume mounted into the Pod so the Mesh container can keep its node state across restarts. In a StatefulSet, that fits neatly because the Pod identity stays stable enough for a persistent attachment point. A plain Deployment is less tidy if the Mesh node is expected to remember who it is.
Keep persistent registration state out of the container layer
Container layers are disposable by design. That is useful right up to the point where the registration token or node state disappears with the next rollout. For a sidecar that should survive restarts, the state belongs on durable storage mounted into the Pod.
That keeps the Mesh container replaceable without forcing a full re-registration cycle every time the image changes. It also means the Pod can fail and recover without turning every restart into a fresh enrolment event. For a StatefulSet, persistent registration state is the sensible default.
Let source NAT handle return traffic without touching the VPC
Mesh includes built-in source NAT, which matters because return traffic has to find its way back cleanly. Without that, traffic may leave the Pod through one path and return through another, which is a good way to create a quiet failure nobody notices until the application looks broken.
With source NAT in place, the Pod can send traffic out through Mesh without changing VPC route tables. That keeps the network side contained. No route-table tweaks, no host routing games, no odd detours through the node. The Pod sends traffic out, Mesh keeps the return path sane, and the VPC does not need to know about the arrangement.
Run the image as an OCI-compatible sidecar in a Pod
The cloudflare/mesh image is designed for container runtimes that speak OCI, so it fits the normal Pod pattern cleanly. In Kubernetes, that means the Mesh container can run as a sidecar container next to the app container with the same Pod networking. In Docker Compose, the same image can sit in a service definition beside the workload. The mechanism changes, but the deployment shape stays familiar.
That makes the image useful in places where host installation is a nuisance or simply not allowed. It also keeps the runtime choice flexible. If the platform can pull and run an OCI-compatible image, the Mesh node can usually join from there.
