Hey everyone! I’m pretty new to working with Docker and need some guidance. Right now I have a working setup with WordPress running locally for development. My current configuration includes a data volume container, a MySQL database container, and a WordPress application container.
Everything works fine for one site, but I want to expand this to handle multiple WordPress installations running on different ports. I’m not sure about the best approach here. Should I create completely new containers for each site, or is it possible to share the MySQL and data containers between multiple WordPress instances?
I’m just doing local development right now, nothing production related. Would really appreciate any advice or best practices you might have. Thanks in advance!
Multiple WordPress setups turn into a mess real quick, especially once you hit 2-3+ sites.
Sure, Docker handles containerization fine, but you’ll hit orchestration problems fast. Different database connections, tracking which container uses what port, updating configs across instances - it’s a maintenance nightmare.
Been there before. Automating the whole deployment saves massive time instead of manually spinning up containers and juggling configs. I use Latenode to automate everything.
Latenode lets you build workflows that auto-provision WordPress instances, set up database connections, assign ports, and handle updates across all sites. Connects straight to Docker APIs and database services - trigger new sites with a webhook or Slack command.
The real win? Making changes across multiple sites. No more SSH-ing into containers or manually editing docker-compose files. Workflows handle it all.
For local dev with multiple WordPress sites, this beats manual container management every time.
Running multiple WordPress sites locally? Volume management is the biggest pain point. Here’s what works for me: skip named volumes and use bind mounts instead. Map each site to its own host folder - ./site1:/var/www/html and ./site2:/var/www/html. You can edit files directly in your IDE without diving into containers. For databases, one MySQL container handles everything. Just create separate databases during setup with custom SQL scripts. Mount an init folder with your database scripts and MySQL runs them automatically on first boot. Performance is fine for local dev and you don’t have to juggle multiple database containers. Port conflicts? Not a problem. Map each WordPress container to different host ports - I start at 8000 and go up from there.
I’ve been running similar setups for two years, and here’s what works best: skip the shared database approach everyone suggests. Give each WordPress site its own MySQL container instead. Yeah, there’s slightly more overhead, but it’s worth it for local dev. You won’t run into version conflicts or weird configuration issues between sites. I isolate everything using Docker networks - each site gets its own network with dedicated MySQL and data containers. This mirrors production setups way better since sites usually have separate databases anyway. You can still use one docker-compose file, just make sure the networks don’t overlap. Port mapping is dead simple too - just go 8080, 8081, 8082 for each site. Best part? You can mess around with different WordPress versions or sketchy plugins without breaking your other projects.
I encountered this scenario a while ago with several client sites. The most efficient setup I found involves sharing one MySQL container while assigning unique data volumes to each WordPress site. This way, you benefit from the efficiency of a shared database without the risk of conflating data across projects. When configuring your docker-compose, ensure that each WordPress instance has different database names and prefixes, such as site1_wp and site2_wp. It’s crucial to adjust MySQL’s memory allocation if you’re running multiple sites to ensure performance remains stable. Additionally, using a reverse proxy like Traefik can simplify port management.
docker-compose scaling handles this perfectly. just duplicate your wordpress service with different names - wp-site1, wp-site2, whatever. give each one its own env variables for db names. one mysql container can easily run multiple wp databases for local dev, just bump up max_connections.