RabbitMQ and backend could not communicate due to "Enable Isolated Deployment" option #125

New Issue

GiteaMirror · 2025-11-22T20:30:51-06:00

GiteaMirror commented

2025-11-22 20:30:51 -06:00

Originally created by @hussainsabba on GitHub (Oct 6, 2025).

Template Name

RabbitMQ

Relevant Logs of the Error

I initially submitted PR #426 to add RabbitMQ to the dokploy-network so that the backend could connect to it.
Later I discovered the root cause was not the compose configuration itself, but the "Enable Isolated Deployment" option under Advanced Settings.

Problem
When "Enable Isolated Deployment" is ON, each service is placed in its own Docker network (e.g., estage-rabbitmq-gm8wnx vs dokploy-network).
This results in services not being able to resolve each other by hostname (rabbitmq, postgres, etc.), breaking backend-to-service connectivity.

The issue is compounded by the fact that this option is somewhat hidden in the Advanced Settings, so users may not realize its impact until they troubleshoot networking problems.

Expected behavior

If services are part of the same Dokploy project, disabling "Isolated Deployment" should allow them to share the same dokploy-network automatically, enabling hostname resolution across services (e.g., amqp://user:pass@rabbitmq:5672).
The UI should make the isolation option more visible and clearly communicate its effect on inter-service networking.

Clarification needed

Is this behavior intentional (strict network isolation by default when the option is enabled)?
Could the UI/Docs make it more obvious that enabling "Isolated Deployment" prevents inter-service communication?
Would it make sense to allow an option to selectively share a network even when "Isolated Deployment" is enabled?

Why this matters
This caused confusion because initially it appeared to be a misconfigured compose file. The real issue was networking isolation.

Steps to Reproduce the Error

Create a new Dokploy project with multiple services (e.g., backend and RabbitMQ).
Go to Advanced Settings for one of the services and enable "Enable Isolated Deployment".
Deploy the project.
Observe that each service is assigned its own Docker network (e.g., estage-rabbitmq-gm8wnx vs dokploy-network).
Try to connect from the backend service to RabbitMQ using the service hostname (rabbitmq:5672).
The connection fails with an unknown host / cannot resolve hostname error.

Expected: Backend should be able to resolve rabbitmq and connect successfully.
Actual: Hostname resolution fails because the services are on separate networks.

Environment Information

N/A

When does this error occur?

When accessing the application

Additional Context

No response

Will you send a PR to fix it?

No

Originally created by @hussainsabba on GitHub (Oct 6, 2025). ### Template Name RabbitMQ ### Relevant Logs of the Error I initially submitted PR [#426](https://github.com/Dokploy/templates/pull/426) to add RabbitMQ to the `dokploy-network` so that the backend could connect to it. Later I discovered the root cause was not the compose configuration itself, but the **"Enable Isolated Deployment"** option under *Advanced Settings*. **Problem** When "Enable Isolated Deployment" is **ON**, each service is placed in its own Docker network (e.g., `estage-rabbitmq-gm8wnx` vs `dokploy-network`). This results in services not being able to resolve each other by hostname (`rabbitmq`, `postgres`, etc.), breaking backend-to-service connectivity. The issue is compounded by the fact that this option is somewhat hidden in the Advanced Settings, so users may not realize its impact until they troubleshoot networking problems. **Expected behavior** - If services are part of the same Dokploy project, disabling "Isolated Deployment" should allow them to share the same `dokploy-network` automatically, enabling hostname resolution across services (e.g., `amqp://user:pass@rabbitmq:5672`). - The UI should make the isolation option more visible and clearly communicate its effect on inter-service networking. **Clarification needed** - Is this behavior intentional (strict network isolation by default when the option is enabled)? - Could the UI/Docs make it more obvious that enabling "Isolated Deployment" prevents inter-service communication? - Would it make sense to allow an option to **selectively share a network** even when "Isolated Deployment" is enabled? **Why this matters** This caused confusion because initially it appeared to be a misconfigured compose file. The real issue was networking isolation. ### Steps to Reproduce the Error ### Steps to Reproduce the Error 1. Create a new Dokploy project with multiple services (e.g., backend and RabbitMQ). 2. Go to **Advanced Settings** for one of the services and enable **"Enable Isolated Deployment"**. 3. Deploy the project. 4. Observe that each service is assigned its own Docker network (e.g., `estage-rabbitmq-gm8wnx` vs `dokploy-network`). 5. Try to connect from the backend service to RabbitMQ using the service hostname (`rabbitmq:5672`). 6. The connection fails with an **unknown host / cannot resolve hostname** error. **Expected:** Backend should be able to resolve `rabbitmq` and connect successfully. **Actual:** Hostname resolution fails because the services are on separate networks. ### Environment Information ```bash N/A ``` ### When does this error occur? When accessing the application ### Additional Context _No response_ ### Will you send a PR to fix it? No

GiteaMirror added the bug label 2025-11-22 20:30:51 -06:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/templates#125