Improve Remote Servers UX: connection status, health checks, and existing Dokploy instance discovery

What problem will this feature address?

Remote Servers work correctly when the SSH connection and setup are valid, but the current UX does not make the server lifecycle clear enough after the server has already been configured.

For example, after a remote server is successfully connected and set up, the card can still show the “Setup Server” action. This makes it difficult to quickly understand whether the server is:

Not configured yet
Already configured and ready
Connected and healthy
Connected but degraded
Offline
Unreachable through SSH
Failing because of authentication or Docker/Traefik issues

In multi-server environments, this becomes confusing because the main Dokploy dashboard should make it very obvious which servers are ready to receive deployments and which ones require attention.

Another related problem is that when connecting a server that already has a Dokploy installation, there is no intuitive way to discover or import the existing projects/services into the main Dokploy instance. This makes it harder to use one Dokploy installation as the main control panel for multiple servers or existing Dokploy nodes.

This is not a connection bug. The remote server connection works. The problem is mainly about visibility, server state, monitoring, and better multi-server management.

Describe the solution you'd like

I would like Remote Servers to have a clearer lifecycle and health status system.

Suggested improvements:

1. Replace or hide “Setup Server” after successful setup

Once a remote server has been successfully configured, the main button should no longer say “Setup Server”.

Instead, the server card could show a clear status such as:

Connected
Server Ready
Online
Degraded
Offline
Setup Required
Authentication Failed

The “Setup Server” action could still exist, but moved into a secondary menu as:

Re-run setup
Repair setup
Reconfigure server

This would make the UI much more intuitive.

2. Add remote server health checks

Each remote server could have automatic health checks for:

SSH connectivity
Docker availability
Traefik status
Dokploy remote setup status
Disk usage
Docker disk usage
CPU usage
Memory usage
Last successful check
Last error message
Server latency/ping from the main Dokploy instance

The card could show a compact summary, and clicking the server could open a detailed health page.

3. Improve Remote Servers monitoring

Remote Servers should have a dedicated monitoring view where each connected server can be reviewed individually.

Example:

Server name
IP / hostname
Status
CPU
Memory
Disk
Docker disk
Containers running
Failed services
Last deployment
Last health check
Last error

This would make it easier to decide where to deploy new services and detect when a remote server has gone down.

4. Add server status events and notifications

Dokploy could generate events when a remote server changes state:

Server connected
Server disconnected
Server went offline
Server came back online
Docker unavailable
Traefik unavailable
Disk usage critical
Deployment server unreachable

These events could also be integrated with existing notification channels.

5. Support connecting an existing Dokploy installation

If the remote server already has Dokploy installed, it would be useful to have an option like:

“Connect existing Dokploy instance”

This mode could allow the main Dokploy instance to discover existing resources from the remote Dokploy installation.

Possible behavior:

Validate remote Dokploy API/token
Validate SSH access
Discover existing projects
Discover existing services
Discover domains
Discover deployments
Discover Docker Compose apps
Discover databases metadata
Discover volumes metadata
Show everything in read-only mode first
Allow the user to selectively adopt/import projects into the main Dokploy instance

For safety, secrets and environment variables should not be imported automatically unless the user explicitly confirms it.

6. Add safe adoption/import flow

When existing projects are found on a remote Dokploy server, Dokploy could provide an adoption workflow:

Scan existing Dokploy instance
Show discovered projects/services
Let the user select what to import
Preview what will be created in the main instance
Confirm adoption
Keep existing containers running without destructive changes
Start managing the selected resources from the main Dokploy instance

This would make migrations between Dokploy servers much easier and safer.

Describe alternatives you've considered

Current workarounds are possible, but they are not ideal:

Manually opening the remote terminal to verify if the server is working
Using external monitoring tools like Uptime Kuma, Netdata, Prometheus, or Grafana
Keeping each Dokploy installation as a separate standalone dashboard
Manually recreating projects in the main Dokploy instance
Manually checking Docker containers, Traefik, disk usage, and server status over SSH
Re-running setup without knowing whether the server is already correctly configured

These workarounds add extra steps and make multi-server management less intuitive.

Additional context

I am using Dokploy Remote Servers in a real multi-server workflow.

The remote server connects correctly, but after setup the interface could be clearer. When a server is already connected and configured, it would be more intuitive if the UI showed a persistent Connected / Ready / Online state instead of keeping the main Setup Server action visible.

This would help users immediately understand the status of each server and quickly detect when a server is down or degraded.

This feature would be especially useful for teams managing multiple VPS servers, client servers, or migration workflows between Dokploy instances.

Related idea: this could complement remote server monitoring improvements, but the request here is broader because it includes:

Remote server lifecycle status
Better setup button behavior
Health checks
Server-level monitoring
Optional discovery/import from an existing Dokploy installation

Screenshot example from Remote Servers page can be attached.

Will you send a PR to implement it?

Yes

The issue does not identify files, tests, or entry points. Start by reviewing the Remote Servers page and its existing setup flow, then define the server lifecycle states, health checks, monitoring view, notifications, and existing-instance discovery before implementation. Done means the requested multi-server status and safe adoption workflows are specified and working without destructive changes.