disable listening on 0.0.0.0:3000 after enabled custom domain

[binaryYuki]

What problem will this feature address?

When configuring a custom domain in the Dokploy panel, the application still listens on 0.0.0.0:3000 through Docker, exposing the service to the public internet. This behavior could lead to unauthorized access, posing a security risk.

Once a custom domain is enabled, external requests should be handled solely through traefik, without directly exposing the Docker container's port. I propose a mechanism to disable Docker's listening on 0.0.0.0:3000 after a custom domain is configured.

Describe the solution you'd like

After configuring a custom domain:

The application should no longer listen on 0.0.0.0:3000/There is a button to disable.
All external traffic should be handled via the reverse proxy, allowing access only through the custom domain.

Describe alternatives you've considered

Automatically change Docker's listening address from 0.0.0.0 to 127.0.0.1 after a custom domain is configured, with all external requests handled by the reverse proxy.

Additional context

No response

Will you send a PR to implement it?

Yes

[Siumauricio]

I think literally disabling the port after adding a domain would not be the right thing to do, I think it would be more sensible to have a toggle or something like that to disable port 3000.

[binaryYuki]

@Siumauricio I agree with your suggestion that a toggle or configuration option to control whether port 3000 is exposed would be a more flexible approach. Switching the listening address to 127.0.0.1:3000 after a custom domain is configured would significantly reduce the attack surface without compromising functionality for most users.

As it stands, exposing 0.0.0.0:3000 creates a considerable security risk. A quick search using public asset mapping systems reveals 3,618 Dokploy server IPs with open ports that are accessible over the internet.(Unfortunately I can't disclose the relevant search method in an issue without a security policy configured in this repo)
This exposure, combined with the fact that Dokploy currently lacks a security policy or rate-limiting mechanism for its login API, makes it vulnerable to brute-force attacks and other malicious activities.

While I understand the need for flexibility, I believe the following steps should be considered to enhance security:

• Default to 127.0.0.1:3000 once a custom domain is configured, ensuring external traffic is routed exclusively through the reverse proxy.
• Introduce a toggle to allow advanced users to expose 0.0.0.0:3000 if absolutely necessary, but this should come with a clear warning about the associated risks.
• Implement rate-limiting or other mechanisms to mitigate brute-force attacks on the login API.
  This approach balances security and usability while addressing the immediate vulnerability.