fix(proxy): master domain routing for remote apps/services

[Iisyourdad]

Changes

• TLDR: Added the option to have a master domain router like a Kubernetes cluster.

• Added EdgeProxyRemoteRouteService to generate edge Traefik routes for remote services and applications.

• Added opt-in Master Domain Router setting (single server per team), instead of forcing this behavior globally.

• Edge now writes stable dynamic files:

  • /data/coolify/proxy/dynamic/service-remote-<service-uuid>.yaml
  • /data/coolify/proxy/dynamic/application-remote-<application-uuid>.yaml

• Generated config includes:

  • HTTP -> HTTPS redirect
  • HTTPS router with certResolver=letsencrypt
  • Load balancer target http://<remote_host>:<published_host_port>

• Deploy/redeploy updates route files; delete removes them.

• Missing/invalid host or port is skipped with warnings.

• Added remote database proxy master-routing support and tests:

  • EdgeProxyRemoteRouteServiceTest
  • DatabaseProxyMasterRoutingTest
  • ServerMasterDomainRouterSettingTest

Issues

Closes #8668

• Remote servers connected via Wireguard would not get traffic just by adding it as a server.

Category

• Bug fix
• Improvement
• New feature
• Adding new one click service
• Fixing or updating existing one click service

Preview

AI Assistance

• AI was NOT used to create this PR
• AI was used (please describe below)

If AI was used:

• Tools used: Codex
• How extensively: I used ChatGPT's Codex to help identify the issue and what needed to be done in the future. I also had it help write some of the test cases.

Testing

1. Ran the new unit test file:
   • php artisan test tests/Unit/EdgeProxyRemotePortForwardServiceTest.php tests/Unit/EdgeProxyRemoteRouteServiceTest.php tests/Unit/DatabaseProxyMasterRoutingTest.php
   • Result: 50 passed (230 assertions)

Verified by tests:

• Traefik dynamic config is generated with:
  • HTTP -> HTTPS redirect
  • HTTPS router using certResolver=letsencrypt
  • service target http://<remote_host>:<published_host_port>
• Route files are handled across lifecycle:
  • create/update on deploy
  • delete on resource removal
  • stable filename per UUID (service/application)
• TCP and UDP routing for applications.
• Skipped routes return/log actionable warnings.

Contributor Agreement

Important

• I have read and understood the contributor guidelines. If I have failed to follow any guideline, I understand that this PR may be closed without review.
• I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate.
• I have tested all the changes thoroughly with a local development instance of Coolify and I am confident that they will work as expected when a maintainer tests them.

[Cinzya]

Not necessarily a bad idea, but it comes with a few flaws / oversights.

From what I can tell, you are right now only covering service routes, but not applications. So as soon as you deploy a application, it won't work. The same probably applies for database proxies as well, would need to check the code again to confirm.

There are users who use Coolify actually the opposite way. Have the Coolify dashboard on a non-public, private network, while every other remote server is public.
Also one server as the entrypoint makes it a single point of failure.
It would probably be better if this is a setting people can opt-in from the UI, not make it the default behavior for every user.

I probably missed a few more points, I didn't actually test the implementation myself, just glanced over the code. Also make sure to actually do a integration test, aka test with a running Coolify installation, not just running the Unit test files.

[Iisyourdad]

I see your point about the applications, I'll make sure that that is resolved and I didn't think about people having coolify the opposite way. I'll look into this and also add a button in the server config that will let users opt into this.

[Iisyourdad]

Howdy @Cinzya, I added support for applications and databases. I also added in a "master server" option in the server config that enables or disables this feature. I did implementation test on my machine and it works. I also added some more test cases via the command below. I had Codex write some of these test cases just because I couldn't get every edge case.

php artisan test tests/Feature/ServerMasterDomainRouterSettingTest.php tests/Unit/DatabaseProxyMasterRoutingTest.php tests/Unit/EdgeProxyRemoteRouteServiceTest.php

[Iisyourdad]

I found an error when I implemented this on my on VPS running coolify. TLS certificates would not route properly whenever the port on the secondary server wasn't resolved. I have implemented this PR on my own VPS and have seen that it has worked. I have tested it with the one click deploy of VERT which does work (with https). I just tried it on the one minecraft server and unfortunately it didn't work which I'm working on currently.

[Iisyourdad]

Howdy @Cinzya, I have fixed the issue I found and tested both http/https and tcp applications running on a live VPS and a secondary home server.

I tested the "Master router" feature where only one server has all the DNS records set to it and only one server can enable this feature. From there, I deployed the one click service VERT which ran as expected and I also ran the one click minecraft server aswell and it worked as expected.
I have not tested out a database simply because I don't know how to test out a database in a production environment but I am confident that it will work.

How I had my system set up is the main vps with *.twestbrook.com pointed to it and my home server connected via wireguard over ssh. From there, the end user types in the domain that they want and it gets routed to the appropriate server after passing through the master server, or in my case, to the vps then to the home server.

Please let me know if you have any questions!

[Iisyourdad]

Let me know if/when you want me to update documentation on this.

[Iisyourdad]

Line 5

'version' => '4.0.0-beta.465', must be changed.

[Iisyourdad]

@Cinzya and @ShadowArcanist, would either of you mind reviewing this PR when you get a chance? I know it is a large PR so I completely understand that it may take some time.

I currently have it running on my personal VPS with other servers connected to it and it has been working in my testing/use case. The overall idea is somewhat similar to a Kubernetes cluster.

I did not want to ping Peak or Andras since I know they are busy with the recent updates, but I would really appreciate it if one of yall had time to look it over.

[ShadowArcanist]

@Cinzya and @ShadowArcanist, would either of you mind reviewing this PR when you get a chance? I know it is a large PR so I completely understand that it may take some time.

I currently have it running on my personal VPS with other servers connected to it and it has been working in my testing/use case. The overall idea is somewhat similar to a Kubernetes cluster.

I did not want to ping Peak or Andras since I know they are busy with the recent updates, but I would really appreciate it if one of yall had time to look it over.

Sorry, I’m unable to review this PR because the changes are beyond my current level of familiarity with the codebase.

[Iisyourdad]

I readded one of the features in the new update which was a merge conflict. I readded the "Server Details" feature in servers.

[Iisyourdad]

@andrasbacsai and/or @peaklabs-dev , would either of you mind reviewing this PR when you get a chance? I know it is a large PR so I completely understand that it may take some time.

I currently have it running on my personal VPS with other servers connected to it and it has been working in my testing/use case. The overall idea is somewhat similar to a Kubernetes cluster.