Traefik in this Coolify install resolves backends on a per-resource
network named after the resource UUID, not the shared "coolify" network.
COOLIFY_RESOURCE_UUID is injected into the compose env by Coolify, so
naming the external network from it lets Traefik find couchdb.
The container was only on the project's default network, so Coolify's
Traefik (on the shared coolify network) had no route to it — Traefik
matched the router but reported "no available server". Putting couchdb
on both networks lets Traefik reach 5984 while leaving the init sidecar
talking to it over the default network as before.
When SERVICE_FQDN_<NAME>_<PORT> is set, Coolify auto-injects its own
Traefik router and service labels on the couchdb container. Our manual
labels reused the same router/service name (couchdb), so the two
definitions collided and Traefik ended up with a router whose backing
service had no servers — Traefik returned "no available server" for
couch.apoena.dev. Dropping the manual labels lets Coolify own routing
end-to-end.
The couchdb:3 image purges curl after the build, so the curl-based
healthcheck could never succeed. The cors.ini bind-mount also looks
like the cause of the ~600ms container exit observed in the first two
Coolify deploys. Both pieces are removed; CORS is now applied by the
init sidecar via PUTs against /_node/_local/_config/..., which is
idempotent on redeploy.
