Bottom Line: Decide Between Separate WordPress Containers and WordPress Multisite Before You Deploy
“Run multiple WordPress sites” can mean two architectures. Separate containers give every site its own WordPress instance and usually its own database. WordPress Multisite runs several sites inside one shared WordPress installation. They have different failure and update boundaries.
Separate Containers Give the Cleanest Isolation
For unrelated sites or different clients, create one Compose project per site. Give each WordPress instance its own persistent files, database credentials and external hostname. The WordPress container image supports normal persistent WordPress deployments.
The MariaDB requirements helps plan database memory and storage.
Use Multisite Only When the Sites Belong Together
WordPress Multisite shares one WordPress core installation, plugins and themes while giving each site separate database tables and uploads. The WordPress Multisite setup explains the model and its subdomain/subdirectory choices.
Do Not Reuse One Database Schema Carelessly
Separate WordPress instances can share one MariaDB server, but give each site a distinct database and user. That keeps backup, migration and access clearer than pointing every container at the same schema.
Put a Reverse Proxy in Front of the Sites
Each site needs a stable hostname and HTTPS endpoint. Map public domains to the appropriate WordPress container through a reverse proxy rather than exposing several random high ports to users.
The ZimaOS HTTPS proxying provides the current ZimaOS-side proxy model.
Back Up Each Failure Boundary Separately
For separate sites, back up each site's WordPress files and database. For Multisite, back up the shared files plus the full multisite database. The old 2025 CasaOS tutorial is useful inspiration, but the architecture choice should come before cloning containers.
The ZimaOS app requirements helps size the combined host.
