I’m currently working on a large-scale Joomla migration project at a university environment (around 500 websites), all currently managed through ISPConfig. Our goal is to modernize the stack and standardize deployments, and I’m considering an architecture where: ISPConfig continues to handle: Domain management DNS SSL (Let’s Encrypt) Storage quotas While Docker is used to run the actual Joomla applications The idea is to configure ISPConfig (Apache/Nginx) as a reverse proxy, forwarding requests to Docker containers running on localhost (different ports or via an internal router like Traefik). Proposed flow: Client → ISPConfig (SSL termination) → Reverse Proxy → Docker Container (Joomla) Each site would: Keep its directory under /var/www/clients/... (managed by ISPConfig) Mount that directory into a Docker container Run Joomla isolated per container Goals: Standardize Joomla environment across hundreds of sites Isolate applications (avoid one site affecting another) Simplify upgrades and maintenance Keep ISPConfig quotas and backups functional Questions: Has anyone implemented a similar setup with ISPConfig + Docker in production? Are there any known pitfalls with using ISPConfig purely as a reverse proxy? How well does this approach scale (hundreds of sites)? Any concerns regarding permissions, quotas, or backups in this model? Would you recommend introducing something like Traefik instead of managing ports manually? I’d really appreciate feedback, especially from the ISPConfig team or anyone managing a large number of sites. Thanks in advance!
I use Docker quite a bit alongside the same ISPconfig server, I upload the application and configure subdomains with an active reverse proxy to access them, and I've had it running in production for a long time without problems.
Nice! Did you change anything in ISPConfig? Could you share more about how you’re using it? My goal is to have multiple standardized sites, like updating 100 sites at the same time, for example Joomla. I think using Docker would make that a lot easier.
First, install the necessary packages for the proxy to work: Code: a2enmod proxy_http service apache2 restart Here, I usually make this available through a subdomain, so I register the subdomain as a domain, allowing me to add a new website in the format system.example.com. And in the site options tab, under Apache directives, you add the necessary code for Let's Encrypt to be generated by the ISP and the redirection to the Docker application. Code: ProxyRequests Off ProxyPreserveHost On ProxyPass /.well-known/acme-challenge ! <Directory "{DOCROOT}/.well-known/acme-challenge"> Options None AllowOverride None Require all granted AddDefaultCharset off </Directory> <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://192.168.100.252:8080 ProxyPassReverse / http://192.168.100:8080 Remember that the quota doesn't apply in this case, since disk usage is within Docker. As for the bandwidth limit, I can't say if it works because I don't limit my clients, but test it. I think it should work.
Thanks for sharing your setup, this really helped clarify how you're using ISPConfig with Docker! I was wondering about the user side in this model. In your case, what can users still manage through ISPConfig? For example, are they still able to: transfer files via FTP normally? change their FTP passwords through the panel? access phpMyAdmin as usual? restore databases using ISPConfig tools? Or does most of the control move outside ISPConfig into Docker? My goal is to keep all ISPConfig features available so users can handle things themselves (like changing database passwords) without needing intervention from the data center team. Just trying to understand how much autonomy users keep in this approach. Thanks again!
I don't use docker yet, but if I understand you right, I don't think ISPConfig can manage the Docker container(s), though as said by @marceloleaes managing proxy to it is possible. In my mind, you need specific app / software to manage your Docker container(s), while about the database, yes you can still use the one that is managed by ISPConfig, so users can still change their password themselves. If I remember correctly, (not checking, so do check or wait for @till to respond), ISPConfig is also moving to support dockerized container(s) in the future, and even currently it may also be installed in it too, but the quotas (and other kernel functions) may not be available, if you choose to run it from a container.