I mirrored a client’s e-commerce stack — frontend, API, PDF service, Redis, Elasticsearch — onto my own Coolify server behind Cloudflare Tunnel, as an isolated environment for testing. Two networking lessons came out of it.
First: a hardcoded request timeout is a bet about network topology. The backend’s Elasticsearch client had a timeout tuned for same-network latency, and it was fine for years — until the search traffic started crossing a tunnel and a proxy, where the same queries occasionally breathed past the limit and surfaced as search failures rather than slow searches. The fix wasn’t a bigger magic number; it was making the timeout configurable (SEARCH_REQUEST_TIMEOUT as an env var) so each deployment of the stack can state its own tolerance. Any client library timeout you hardcode is an assumption that every future environment will have your current network.
Second: getaddrinfo EAI_AGAIN is a DNS problem, not a service problem. When one container couldn’t reach another, the error looked like Elasticsearch being down. It wasn’t — EAI_AGAIN means the name lookup failed temporarily, which in a Docker/Coolify world almost always means container-DNS or network-attachment issues: services on different Docker networks, a service name that only resolves on the internal network while you’re connecting via published ports, or the reverse. Fixing it is about which network the containers share and which hostname you use from where — not about the service you’re trying to reach.
The general rule from both: when you relocate a stack, the code is the easy part. The assumptions the code makes about the network — latency, name resolution, who can see whom — are the actual migration.