Using Docker’s default bridge network is convenient, but it comes with several drawbacks:

• No network isolation: All containers attached to the default network can freely reach each other. This makes it harder to enforce clear boundaries between internal-only services (databases, caches, queues) and public-facing components.
• Name collisions: Service-to-service DNS resolution is less predictable, and naming conflicts become more likely across unrelated projects.
• Lack of explicit topology: Relying on defaults hides the actual network structure. Explicit networks make your architecture self-documenting and easier to troubleshoot.
• Harder security controls: Custom networks let you define which services may communicate and which should be completely isolated.
• Why you should create custom networks (internal + external)
• Defining your own networks in Docker Compose gives you

https://docs.docker.com/engine/network/drivers/bridge/ and I will quote:

You can also create user-defined custom bridge networks. User-defined bridge networks are superior to the default bridge network.

Anyhow, so I propose to apply best practices here. And create a internal network (for DB, Redis, etc) as well as an external network (for the Nginx, websocket and scheduler.. and ES?).

Regards,
Melroy