You know that feeling when your service mesh is more tangled than the cables under your desk? That’s what happens when Caddy and Traefik aren’t actually talking to each other. It’s not that either tool is bad, they just have different opinions about what “mesh” means. Getting them to cooperate is where the fun starts.
Caddy brings elegance to HTTP management. It automates TLS with zero config, handles reverse proxying like it was born for it, and comes with an API that actually makes sense. Traefik Mesh, on the other hand, is about service‑to‑service communication and fine‑grained networking within distributed systems. Put them together and you get hardened ingress with smart internal routing, all TLS‑aware and identity‑driven.
The core idea is this: let Caddy terminate publicly facing traffic and convert it into authenticated, encrypted sessions heading into the Traefik Mesh. Inside the mesh, traffic is encrypted again, service identities are checked through mutual TLS, and policies control where requests can go. Caddy handles the edge, Traefik Mesh runs the neighborhood watch.
How do I connect Caddy and Traefik Mesh?
Treat Caddy as your front gate. Point your DNS to it, enable automatic certificates, then forward incoming requests to the Traefik Mesh entry point. Mesh services use identities issued by your preferred provider, often via OIDC or SPIFFE. The result: clean ingress flow, no manual cert rotation, and end‑to‑end trust.
Common setup pitfalls
The top mistake is double TLS termination. Pick your boundary. If Caddy owns the public certs, let Traefik Mesh issue internal ones only. Another trap is inconsistent identity mapping. Tie each internal service to a unique SPIFFE ID or an IAM role, otherwise your logs will read like a mystery novel.