Crypto miner bot is scaning new Dokploy instances and compromize them as soon they're online. Disabling UI by default is a good idea.

What problem will this feature address?

I just reinstalled a VPS with Dokploy at OVH and was instantly compromised.

Here is the report from my initial audit:

• Compromise is confirmed, and the attacker gained root access to the host.

• The initial vector did not originate from the Mac: an ephemeral Alpine container named orch-key-inject-… injected a
  key into /root/.ssh/authorized_keys at 13:19:06 UTC.

• Four seconds later, 51.68.xxx.x logged in via SSH as root using that key.

• This session installed a fake docker-daemon, downloaded vltrig, and began mining on pool.hashvault.pro.

• The same session installed a second piece of malware that is still active: /root/.orch-lab/orchestrator. It is scanning
  the Internet on port 3000 on a massive scale to find other vulnerable Dokploy instances.

• It has already recorded 3 "hits" and contains its own SSH keys as well as binaries for multiple architectures, demonstrating a capability to spread.

• The attacker's root key is still present, and the PermitRootLogin prohibit-password setting still allows it; therefore, they can return.

• Dokploy is currently on v0.30.2. The appName vulnerability you mentioned affects versions <= 0.26.6, so it is likely not that specific CVE. However, the infection definitely entered via Dokploy/its Docker access: the injection container appeared right after Dokploy was exposed—before your legitimate registration at 13:31:56—which explains why we got an "Admin already exist" error immediately after installing Dokploy.

• The Dokploy database contains a suspicious account containing "orch-lab"

• The compromise is confirmed and root access was obtained; the fake
  miner was only part of the deployment, as a second malicious service (orchestrator-lab) was
  still active at the time of the last check and was aggressively scanning other Dokploy instances.

Describe the solution you'd like

Disabling the UI by default and let the user enable it via flags at installation is a good idea I think.
OVH VPS cannot be fully protected by their Edge Firewall on VPS becuase rules does not applies to IPv6.

Describe alternatives you've considered

Security hardening is a MUST before anything, but you have to be more explicit on that.

Additional context

No response

Will you send a PR to implement it?

No

The issue names no files, tests, or entry points. Start by locating the installation path and how UI exposure and installation flags are configured, then review the existing security-hardening guidance. Done means the default behavior and opt-in configuration are clearly specified and verified for fresh installations.