Integrate remote servers into the monitoring dashboard

[DenisHoppe]

What problem will this feature address?

The central /dashboard/monitoring page currently focuses on the local Dokploy host and does not provide a unified view of registered remote deployment servers.

Remote monitoring support already exists in parts of the application: remote servers have their own metricsConfig, the monitoring agent can be deployed remotely, and the existing server-monitoring component can render metrics from a configured URL. However, this functionality is currently exposed mainly through Cloud-only server modals. Self-hosted users with remote servers cannot conveniently compare server health or switch the central monitoring view between hosts.

Service detail pages have a similar limitation: container monitoring for remote applications is gated by Cloud-specific conditions, so self-hosted applications assigned to remote servers do not consistently expose their Monitoring tab.

Describe the solution you'd like

Extend the central Monitoring page with a conditional fleet view that appears only when at least one accessible, active remote deployment server exists.

Server overview

• Show compact cards for the local Dokploy host and every accessible active remote deployment server.
• Display the most important current values: connection/monitoring status, CPU, memory, disk usage, and uptime.
• Allow selecting a server by clicking its card.
• Treat unavailable servers independently so one failed endpoint does not block the complete dashboard.
• Exclude build-only and inactive servers.

Detail view

• Add a server selector for installations with multiple servers.
• Show the existing historical CPU, memory, disk, network, system information, refresh interval, and data-point controls for the selected server.
• Fetch historical metrics only for the selected server rather than mounting a complete chart dashboard for every card.
• Keep the current single-server page unchanged when no remote servers exist.

Service monitoring

• Show the Monitoring tab for self-hosted services assigned to a remote server when monitoring is configured and the user has monitoring.read permission.
• Automatically use the service's assigned server; no server selector is necessary inside a service detail page.
• Keep local services on the existing local monitoring path and use the remote monitoring API for remote services.

Backend and security

• Introduce server-ID-based metric endpoints for current and historical metrics.
• Resolve the metrics URL, port, and token on the server side after validating organization membership and server access.
• Do not accept an arbitrary metrics URL or token from the client and do not expose monitoring tokens in page data.
• Return per-server availability/error states suitable for the overview.
• Use a slower overview polling interval, such as 15-30 seconds, and retain the configurable interval for the selected detail view.

Monitoring setup

• Make the Monitoring setup tab available for eligible self-hosted remote deployment servers, not only Cloud servers.
• Clearly show when the remote monitoring agent is not configured and link to the corresponding server setup action.
• Preserve any intentional feature/licensing restrictions explicitly rather than relying on scattered isCloud UI conditions.

Describe alternatives you've considered

• Keep monitoring exclusively in per-server modals: this works for individual inspection but provides no fleet overview and is difficult to discover.
• Add only a server dropdown to the current page: simpler, but users cannot quickly identify an overloaded or unavailable server.
• Render complete charts for every server simultaneously: informative but unnecessarily expensive because every server would continuously fetch historical datasets.
• Create a separate page per remote server: adds navigation complexity while duplicating the existing monitoring layout.

Additional context

Current implementation observations:

• pages/dashboard/monitoring.tsx loads local web-server monitoring and redirects Cloud users away from the page.
• ShowPaidMonitoring already accepts a metrics base URL and token and can be reused for a selected server detail view.
• ShowMonitoringModal exposes remote metrics from the server settings page but is rendered only under Cloud-specific conditions.
• SetupMonitoring and server.setupMonitoring already support a serverId and remote monitoring configuration.
• Application Monitoring tabs currently require (serverId && isCloud) for remote metrics.
• server.getServerMetrics currently receives a URL and token from the client; a server-ID-based API would provide a safer boundary and avoid client-side secret exposure.

Suggested acceptance criteria:

1. The central Monitoring page remains unchanged when no remote deployment server exists.
2. When remote servers exist, users see current health summaries for all accessible active deployment servers.
3. Selecting a server loads only that server's detailed historical charts.
4. An unavailable server does not prevent metrics from other servers from rendering.
5. Self-hosted remote services show monitoring when their monitoring agent is configured.
6. Metrics URLs and tokens are resolved and protected server-side.
7. Users cannot retrieve metrics for servers outside their organization or permissions.
8. Build-only and inactive servers are excluded from the fleet monitoring UI.

Will you send a PR to implement it?

Yes

[DenisHoppe]

Umgesetzt in PR #3 (feat/appmove-remote):

• zentrale Monitoring-Übersicht für den Dokploy-Server und alle aktiven Remote-Server
• auswählbare Serverkarten mit CPU-, Arbeitsspeicher- und Festplattenstatus
• Detailansicht für den ausgewählten Remote-Server
• Remote-Monitoring in den Detailseiten von Applications, Compose und Datenbanken
• sichere serverseitige Auflösung von Monitoring-Adresse und Token; Zugangsdaten werden nicht mehr an den Client übergeben
• Monitoring-Setup für selbst gehostete Remote-Server freigeschaltet
• IPv6-kompatible Monitoring-Endpunkte
• lokaler Dokploy-Server nutzt seine integrierten Statistiken und benötigt keinen dokploy-monitoring-Agent
• Remote-Server verwenden weiterhin den automatisch eingerichteten dokploy-monitoring-Service

Die Funktion wurde auf dem Testserver 10.15.105.72 installiert und erfolgreich getestet.