Remote Server Management Panel for Main Server Failover

What problem will this feature address?

Currently, remote servers in Dokploy depend on the main Dokploy instance for management and orchestration.

If the main Dokploy server becomes unavailable due to a server failure, network issue, maintenance, or outage, the remote servers may continue running their applications, but there is no independent management interface available on those remote servers.

This creates a single point of failure for administration. Even though applications on remote servers are still online, it may not be possible to easily manage deployments, restart services, inspect logs, change environment variables, or perform other administrative tasks through Dokploy until the main server is restored.

Describe the solution you'd like

I would like an optional lightweight Dokploy management component/agent that can run directly on each Remote Server.

The main Dokploy instance would remain the primary control plane during normal operation, but each remote server could optionally expose a local management panel containing the services and deployments assigned to that server.

If the main Dokploy instance becomes unavailable, an administrator could connect directly to the remote server's panel and continue managing its local applications.

Ideally, this could include:

View applications deployed on the remote server
Start, stop, restart, and redeploy services
View container/service status
View logs
Access deployment history
Manage environment variables
Manage Docker/Compose services
Perform basic server management
Synchronize configuration/state with the main Dokploy instance
Detect when the main Dokploy instance is unavailable
Continue operating independently during a main server outage
Re-synchronize changes when the main Dokploy instance becomes available again

This could work similarly to a Remote Agent / Secondary Control Plane, while keeping the main Dokploy instance as the central management interface under normal conditions

Describe alternatives you've considered

One alternative is installing a complete independent Dokploy instance on every remote server. However, this creates duplicated installations, separate databases, separate authentication, and configuration synchronization problems.

Another alternative is managing the remote server directly through SSH and Docker CLI when the main Dokploy instance is unavailable. This works for emergency situations but removes most of the convenience and visibility provided by Dokploy.

An optional remote management agent/panel integrated with the main Dokploy instance would provide a cleaner solution.

Additional context

My current setup has one primary Dokploy instance managing multiple Remote Servers.

Applications are distributed between these servers, and the goal is to avoid having the main Dokploy server become a single point of failure for management.

For example:

Normal operation

Main Dokploy → Remote Server 1

→ Remote Server 2

Main Dokploy unavailable

Remote Server 1 → Local Dokploy/Agent Panel → Manage local services

Remote Server 2 → Local Dokploy/Agent Panel → Manage local services

When the main Dokploy server comes back online, the remote agents could reconnect and synchronize their state.

This would be especially useful for high-availability setups where applications are replicated or distributed across multiple independent Docker servers.

Will you send a PR to implement it?

No

No files or tests are named. Start by mapping the existing remote-server management and deployment orchestration entry points, then define the agent, local panel, failover, and synchronization boundaries; done requires an agreed scope for independent local management and recovery synchronization.