Dokploy: Intelligent Application Deployment

The Architecture Rationale

As my Proxmox ecosystem expanded, the overhead of managing raw Docker Compose files for every service became a bottleneck. I required a deployment orchestrator that was both lightweight and “fine-grained.” After evaluating Coolify, Dokku, and cosmOS—and determining that their update cycles or resource footprints did not align with my production requirements—I selected Dokploy for its balance of performance and management simplicity.

Phase 1: Deployment & Network Topology

Dokploy is hosted in a dedicated LXC, utilizing Proxmox Helper-Scripts. To maintain a clean ingress flow, I leverage a dual-mode strategy:

• Option 1: Edge Proxy Path (Nginx): Traffic hits the Nginx LXC, which routes the request to the Dokploy internal port. This preserves my centralized SSL termination and Nginx security policy.
• Option 2: Cloudflare Tunnel: For services requiring Zero Trust access, I bypass Nginx and route traffic directly via Cloudflare Tunnels. This allows for identity-based access policies (e.g., email-based authorization) to be enforced at the edge, effectively creating a “perimeter-less” security model for specific applications.

Phase 2: Orchestration & Lifecycle Management

The primary benefit of Dokploy in this infrastructure is its ability to treat “containers as applications” rather than abstract services.

Advanced Configuration Patterns

• Storage Integration: For applications requiring persistent cloud storage (e.g., Browser-based environments), I utilize Rclone mounts within the host, mapped into the container via volume mounts. This ensures that data remains persistent and accessible via standard Linux file system paths.
• Container Identity: For secure file access within containers, I explicitly define user contexts (e.g., user: root) in the compose configuration to avoid permission mismatch issues between the host mount and the container runtime.
• Internal Service Discovery: To ensure cross-container communication (e.g., a Dokploy app needing to communicate with the Stalwart mail relay), I inject custom network mappings:

YAML

extra_hosts:
  - "stalwart.domain.com:[stalwart-ip]" # Mapping internal LAN service

Phase 3: Infrastructure Evaluation

Platform	Rationale
Dokploy	Selected. Provides granular control, predictable updates, and minimal resource overhead.
Coolify / Dokku / cosmOS	Evaluated. Found to be either too bloated, lacking frequent updates, or lacking the fine-grained control needed for specific LXC workflows.
Plain Docker	Discarded. While functional, managing dozens of standalone docker-compose files creates significant “Time Wastage” regarding lifecycle updates.

Professional Insights: DB Orchestration

When managing database resources (Postgres, MariaDB, MySQL), connectivity within an orchestrated environment is often the biggest hurdle.

• Predefined Networks: When utilizing orchestrators, ensuring that database resources share a predefined network is essential for container discovery.
• Connection Drivers: For database clients like CloudBeaver, always ensure allowPublicKeyRetrieval=TRUE is set in the driver properties. This avoids common handshake failures when connecting to modern database containers with strict security configurations.

Operational Summary

By implementing Dokploy, I have transitioned from “manual container maintenance” to “application-centric deployment.” This setup allows me to spin up new internal tools, such as browser-based environments or database clients, in seconds, while maintaining rigorous control over networking, persistence, and service inter-connectivity.