Feature Requests

Allow services that are bridged with host network
Problem: Easypanel-Managed Services Cannot Access Host-Accessible Private Subnets In a Docker Swarm environment, services deployed by Easypanel are attached to overlay networks (e.g. easypanel-alonso-apps). Overlay networks, by design, are isolated from the host’s underlying network interfaces and routing table. As a result, these services cannot reach private subnets that the host machine has access to (e.g. 10.2.5.0/24, where an internal SQL Server may reside). Even though the Docker host itself can reach these private resources, containers within overlay networks cannot unless they are granted some form of access to the host network. This limitation is fundamental to Docker Swarm’s overlay architecture and is not specific to Easypanel. Workaround: Deploying a Global Port-Forward Proxy To bridge this gap, users must manually deploy a “forwarding” service using socat or similar tooling. This service: • Runs in deploy_mode: global to ensure it exists on every node • Publishes the relevant port in mode: host so that it can bind to the real host network • Is connected to a user-created overlay network (e.g. fwd-host) • Forwards traffic from a stable service name (e.g. db-proxy:1433) to a host-accessible private subnet (e.g. 10.2.5.1:1433) Then, Easypanel-managed services must also be manually attached to that overlay (fwd-host) to access the proxy. How I accomplished this: A python script that runs on a cron every 3 seconds checks for easypanel services and attaches services to this network (very awkward) This pattern is stable, but it introduces a multi-step manual deployment and orchestration process, which can be difficult to automate cleanly inside the Easypanel deployment lifecycle. Feature Request It would be valuable if Easypanel supported the ability to: 1. Attach services to additional user-defined overlay networks, such as fwd-host, during deployment. 2. Optionally deploy a host-networked global forwarding service as part of the stack configuration (or expose a plug-in point for it). 3. Provide documentation or native support for common access patterns to private infrastructure (such as databases on VPN interfaces, internal subnets, etc.). Why It Matters This limitation blocks access to internal infrastructure that cannot be publicly exposed and is only available from inside the Docker host or its associated network interfaces. Supporting this natively would allow Easypanel users to interact with internal services (e.g., database clusters, private APIs) in a secure, Swarm-compliant, and manageable way without introducing out-of-band infrastructure.
0
Auto Snapshots
Auto Snapshots with Service Stop/Restart Feature This feature allows Easypanel to automatically create snapshots of running services while giving the option to stop a service before taking the snapshot and restart it once the process is complete. Service-Level Interface and Configuration New "Auto Snapshots" Tab: In each service, add an "Auto Snapshots" tab (similar to the existing database backups section) to allow individual configuration of automatic snapshots. Configuration Options: Within this tab, users can configure: Enable/Disable: A toggle to activate or deactivate automatic snapshot creation for the service. Schedule/Frequency: Predefined intervals (e.g., hourly, daily, weekly). A field for entering a cron expression for more customized scheduling. Retention Policy: Define the maximum number of snapshots to keep. Specify an expiration time for each snapshot, with the automatic removal of older snapshots. Storage Location Selection: A dropdown list showing configured storage providers (local, SFTP, FTP, Dropbox, Google Drive, etc.) with the option to select one or more destinations for redundancy. Service State Management (Auto Stop/Restart): Auto Stop Toggle: An option that instructs Easypanel to automatically stop the service before initiating the snapshot. Controlled Procedure: A setting to determine if the service should automatically restart once the snapshot is completed. This may include designating a “maintenance window” or sending notifications to inform the user when the automatic stop will occur, thereby minimizing operational impacts. These options enable users to tailor snapshot behavior according to the criticality of the service and its availability requirements. Automated Snapshot Process with Service Stop and Restart Snapshot Execution: An internal Easypanel process monitors the configured schedules and triggers the snapshot routine at the set times. Service State Check and Adjustment: If the Service is Running: With Auto Stop enabled, the system will detect if the service is active and automatically stop it before taking the snapshot. Controlled Execution: Once stopped, the snapshot is generated. If stopping the service is not possible (due to maintenance restrictions or high-availability requirements), the system will log a warning and reschedule the task according to the defined conditions. Storage and Synchronization: Local Storage: The snapshot file is initially saved in a designated snapshots directory on the server. Remote Storage: Subsequently, a routine uploads the snapshot file to the selected remote storage providers using the configured credentials. Automatic Restart: If Auto Stop/Restart is enabled, the service is automatically restarted once the snapshot creation is successfully completed, ensuring minimal downtime. Snapshot Visualization and Management History and Status: The interface displays a list of all created snapshots, including details such as date, time, status (success, failure, pending), and the storage locations where they are saved. Available Actions: Download: Allows users to manually download the snapshot for external restoration or maintenance purposes. Restoration: Implements a "Restore" button to revert the service to the state captured in the snapshot. Deletion: Provides an option to manually delete snapshots that are no longer needed, alongside the automated cleanup via the retention policy. Notifications and Logs: Integrate notifications through email or via the Easypanel dashboard to inform users about snapshot execution, any service interruptions, or errors encountered. Maintain detailed logs of the snapshot operations for auditing and troubleshooting. Technical Considerations and Benefits Consistency and Integrity: Similar to database backups, the snapshot must capture a complete and consistent state of the service. Enabling automatic service stoppage ensures data consistency by preventing concurrent modifications during the snapshot. Flexibility and Personalization: Users can select the best strategy for their environment—either opting for snapshots without interruption or ensuring a consistent state with a brief service stop. Risk Reduction and Easier Recovery: This approach creates a robust backup and recovery process, reducing the risk of data loss and simplifying service restoration after deployment failures or configuration errors. This enhanced feature increases Easypanel's resilience by automating snapshots and intelligently managing service states. It not only enables fast recovery of critical services but also streamlines maintenance with minimal operational disruption.
0
Load More