Communication within "Project"

[gunhaxxor]

Is there a convenient way to make resources able to reach each other within a project?

I have successfully been able to communicate between services within a resource (a docker compose deployment), but in my current use case it would be slightly inconvenient to put all my services in the same compose deployment.

How can one resource access another resource, without exposing them on the host (ie exposing them to the public internet)

Thankful for any advice!

[djsisson]

@gunhaxxor the services that need to 'communicate' with each other need to be in the same docker network.

so say you have 3 different compose files, but only need 1 service from each to communicate, you would add a new network, and add those 3 to the same network as well as their initial ones

you can also do this in coolify ui using the destinations (this is just an alias for a docker network)

[gunhaxxor]

Thanks! I'm starting to grasp things better now. To my understanding I can only add/edit networks in the destination tab in the UI, not add containers to those networks?

I read that if I check "use predefined network" coolify will add a uid to the service name. Doesn't seem to be the case?
I have a compose build with a service called "app" running on port 4334. It seems to be reachable on app:4334, no need to use some uid suffix. Am I misunderstanding the docs?
https://coolify.io/docs/knowledge-base/docker/compose#connect-to-predefined-networks

[gunhaxxor]

Hmm! This is confusing to me!
coolify (or is it docker?) does indeed seem to add a suffix to the app in the network (docker network inspect coolify).
But. I can reach the app at app:4334 from another resource. What to conclude from this?

[gunhaxxor]

Ok. I'll try to answer my own question, with the risk of being wrong 😄
My conclusion is that coolify doesnt change the hostname, but rather adds a suffixed alias for the conatiner in the coolify network..
First I do docker ps and can see the container "ic04gokkcowgoo0sg4gk0sww-app"
Inspecting that container with docker container inspect [container id] gives info about which networks it belong to and specifically cheking the Aliases property in the coolify network gives:

"Aliases": [
                        "app-ic04gokkcowgoo0sg4gk0sww-071531404199",
                        "app",
                        "fda36de65498"
                    ],

which I guess explains why I can reach the app at app:4334, since "app" is also an alias.

custom networking with docker/compose is a slightly uncharted terrain for me.

[pksorensen]

@gunhaxxor - did you find a solution ?

[pksorensen]

The problem with predefined network is that it expose services across projects/envrionments. Would be good with a way to create a network per environment or project event.

[gunhaxxor]

Also. Note that the predefined network option allows one-directional request. So if you need the database to be able to reach back to other services it should also have predefined network enabled.
A service that needs to reach other service should enable the option.
A service that needs to be reachable doesn't need to do anything.

[gunhaxxor]

The problem with predefined network is that it expose services across projects/envrionments. Would be good with a way to create a network per environment or project event.

Then I think custom docker networks is the way. Haven't had a need for this yet so haven't explored. But I guess the destinations section of the ui is the place to start. And then update compose files accordingly.

I think you usually get the option to choose what network (destination) a coolify service should be added to upon creation?

[douglasg14b]

connect to predefined network

This allows the app to see and communicate with any network even outside of the project right?

Which is definitively not ideal for isolation.

This is making me question what the "point" of standalone DB deployments within a project are, if they cannot be reached from other services in the project without breaking network isolation.

[Cinzya]

@douglasg14b this connects the compose app to the network or rather Coolify Destination you selected during deployment. If you didn't configure any additional Destinations, then every app gets deployed to the Coolify Network.

If you don't want every app to share the same network and be more isolated, you can create a docker network through the Destinations and move the apps to the new destination.

Every other deployment type, e.g. dockerfiles, nixpacks, standalone databases and docker images are immediately being connected to the assigned network / destination.

[ahmtgrbz]

Is it possible to create a network architecture where:

• Frontend can only reach Backend
• Backend can reach both Frontend and Database
• Frontend can not directly access Database

Current Issue:
When using "Connect to Predefined Network", all containers join the same flat network:

destination network (172.16.1.x)
├── frontend    (172.16.1.4) → CAN access DB ⚠️
├── backend     (172.16.1.3) → CAN access DB ✅
└── database    (172.16.1.2)

Additionally, databases created in Coolify automatically join the destination network - they don't get their own isolated network.

Security Concern:
This flat network architecture enables lateral movement. If an RCE vulnerability exists in the frontend (e.g., react2shell, supply chain attack, SSRF), an attacker can directly connect to the database.
Custom networks in docker-compose.yml are discouraged (docs mention Gateway Timeout issues), which limits our options.

Questions:

1. Is there a way to achieve FE→BE→DB segmentation?
2. Is there a planned feature for per-project or per-environment network isolation?

My Current Environment: Coolify v4.0.0-beta.460

[djsisson]

you need 3 docker networks

1. with frontend & proxy in
2. with frontend & backend in
3. with backend & db in

the gateway timeout issues are due to when a container has multiple ip's (in more than one network) it can be given the ip of a network it is not in, to resolve this you would just add the traefik label traefik.docker.network=mynetwork where mynetwork is the network with just the frontend and proxy in

the above would need to be done in a compose as you can't specify multiple networks in an application, the same with the db, this would need to be specified in the compose not a one click db.

however there is no way to currently do this in coolify as it would automatically add all 3 containers to its own docker network upon creation (you can override this behaviour with a compose.override.yaml file.)
so first you would create a destination (this would be for proxy + frontend) when creating the compose project, then in override you would reset the networks on the other 2 containers, whilst adding in the networks for 2 and 3 as above in an override file.

Lastly, you should avoid using auto generated dockerfiles as they are often bloated as well as run as root, and use dhi (docker hardened images) instead, these would have the minimal set of binaries needed to run, this is still an issue for js projects, since node/bun can run code directly passed to it, however there would be no shell so it would still be an improvement.

[ahmtgrbz]

@djsisson Thank you for the detailed explanation!
However, I found that compose.override.yaml is currently not supported
in Coolify (see Discussion #4339 - Feature Request still open).
Could you clarify:

1. Is there an alternative way to override Coolify's automatic network assignment?
2. Did you mean using "Raw Docker Compose Deployment" option?
3. Or is this something that requires waiting for the override feature?
   I want to implement the 3-network segmentation you described but can't
   find a way to override Coolify's default network behavior that adds all
   containers to the destination network.

[djsisson]

there isn't an automatic way no, but you can still place the file in the project folder, then use custom start command (unfortunately coolify would still add back in the -f, so you would need to add both files using -f), i had forgotten about raw docker compose, that would work also.
i would probably go with the raw compose option.

[ahmtgrbz]

Thank you so much for the detailed explanation and follow-up!
I'll go with the Raw Docker Compose option as you suggested. This gives us full control over the network configuration without Coolify's automatic modifications.
Your guidance on the 3-network architecture and the traefik.docker.network label for avoiding Gateway Timeout issues was extremely helpful.
Also, thanks for the DHI (Docker Hardened Images) recommendation - I'am planning to use distroless images for our applications.
Much appreciated! 🙏