You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi Louis and the Dockge team, First of all, thank you for creating Dockge! I’ve been using it extensively in my homelab, and I really appreciate its philosophy: — transparency (you always see the actual docker-compose.yml), — simplicity (no hidden abstractions), — and immediate feedback (logs, status, and editing in one place). This approach makes managing containers incredibly intuitive — especially for users who want control without complexity. Recently, I’ve been thinking: what if we applied the same philosophy to reverse proxy management? Right now, many of us use tools like: - Nginx Proxy Manager (GUI, but hides the actual config), - manual Caddyfile editing (powerful, but lacks visual feedback), - or Traefik with labels (great for automation, but less transparent). But there’s a gap: no tool offers the "Dockge experience" for reverse proxies — i.e.: - Each route/service as a separate, human-readable config file (e.g., app1.conf), - A clean web UI to edit, save, and reload that config, - Per-service logs shown right next to the editor, - And isolation: if one route is misconfigured, it doesn’t break the entire proxy. Both Caddy (with import *.conf + caddy reload) and Traefik (with dynamic providers) support safe, modular reloading — making this idea technically feasible. For example, a Caddyfile could look like: caddy import routes/*.conf And routes/app1.conf: caddy yourname.keenetic.link { handle /app1/* { reverse_proxy http://192.168.1.101:3000 } log { output file /logs/app1.log } } This is as self-contained and readable as a docker-compose.yml file — and fits perfectly into the Dockge mindset. I understand this would be a new project (or major expansion), but I believe many in the homelab community would benefit from such a tool — especially those who already trust Dockge for container management. Would you be open to exploring this idea? Even as a separate but "Dockge-inspired" project? I’d be happy to help test, document, or contribute in any small way. Thanks again for your great work — Dockge has genuinely made my setup cleaner and more maintainable! Best regards, Lincooln.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Louis and the Dockge team, First of all, thank you for creating Dockge! I’ve been using it extensively in my homelab, and I really appreciate its philosophy: — transparency (you always see the actual
docker-compose.yml), — simplicity (no hidden abstractions), — and immediate feedback (logs, status, and editing in one place). This approach makes managing containers incredibly intuitive — especially for users who want control without complexity. Recently, I’ve been thinking: what if we applied the same philosophy to reverse proxy management? Right now, many of us use tools like: - Nginx Proxy Manager (GUI, but hides the actual config), - manual Caddyfile editing (powerful, but lacks visual feedback), - or Traefik with labels (great for automation, but less transparent). But there’s a gap: no tool offers the "Dockge experience" for reverse proxies — i.e.: - Each route/service as a separate, human-readable config file (e.g.,app1.conf), - A clean web UI to edit, save, and reload that config, - Per-service logs shown right next to the editor, - And isolation: if one route is misconfigured, it doesn’t break the entire proxy. Both Caddy (withimport *.conf+caddy reload) and Traefik (with dynamic providers) support safe, modular reloading — making this idea technically feasible. For example, aCaddyfilecould look like:caddy import routes/*.confAndroutes/app1.conf:caddy yourname.keenetic.link { handle /app1/* { reverse_proxy http://192.168.1.101:3000 } log { output file /logs/app1.log } }This is as self-contained and readable as adocker-compose.ymlfile — and fits perfectly into the Dockge mindset. I understand this would be a new project (or major expansion), but I believe many in the homelab community would benefit from such a tool — especially those who already trust Dockge for container management. Would you be open to exploring this idea? Even as a separate but "Dockge-inspired" project? I’d be happy to help test, document, or contribute in any small way. Thanks again for your great work — Dockge has genuinely made my setup cleaner and more maintainable! Best regards, Lincooln.Beta Was this translation helpful? Give feedback.
All reactions