{"id":4503,"date":"2026-02-05T15:33:09","date_gmt":"2026-02-05T12:33:09","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/hosting-multiple-isolated-wordpress-sites-on-one-vps\/"},"modified":"2026-02-05T15:33:09","modified_gmt":"2026-02-05T12:33:09","slug":"hosting-multiple-isolated-wordpress-sites-on-one-vps","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/hosting-multiple-isolated-wordpress-sites-on-one-vps\/","title":{"rendered":"Hosting Multiple Isolated WordPress Sites on One VPS"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Running several WordPress sites on a single <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> is one of the most efficient ways to balance cost, performance and control. But there is a big difference between simply dropping multiple sites into one directory and designing a properly <strong>isolated<\/strong> hosting stack with separate Linux users, Nginx virtual hosts and per\u2011site PHP\u2011FPM pools. Done right, one VPS can safely host client projects, side hustles and production blogs together without letting a single compromised plugin take everything down.<\/p>\n<p>In this article, we will walk through the architecture we like to use at dchost.com when agencies and power users ask: \u201cHow can I host multiple WordPress sites on one VPS <em>without<\/em> them affecting each other?\u201d We will focus on three pillars: Linux user isolation, Nginx server blocks (vHosts) and per\u2011site PHP\u2011FPM + database design. By the end, you will have a clear, practical blueprint you can adapt to your own VPS, whether you manage everything over SSH or combine it with a control panel.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Host_Multiple_WordPress_Sites_on_One_VPS\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Host Multiple WordPress Sites on One VPS?<\/a><ul><li><a href=\"#Cost_efficiency_without_losing_control\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Cost efficiency without losing control<\/a><\/li><li><a href=\"#Consistent_stack_and_tooling\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Consistent stack and tooling<\/a><\/li><li><a href=\"#Better_performance_than_generic_shared_hosting\"><span class=\"toc_number toc_depth_2\">1.3<\/span> Better performance than generic shared hosting<\/a><\/li><li><a href=\"#The_big_caveat_isolation_matters\"><span class=\"toc_number toc_depth_2\">1.4<\/span> The big caveat: isolation matters<\/a><\/li><\/ul><\/li><li><a href=\"#Isolation_Models_One_Server_Many_Sites_Without_CrossContamination\"><span class=\"toc_number toc_depth_1\">2<\/span> Isolation Models: One Server, Many Sites Without Cross\u2011Contamination<\/a><ul><li><a href=\"#Option_1_Everything_under_one_Linux_user_what_not_to_do\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Option 1: Everything under one Linux user (what not to do)<\/a><\/li><li><a href=\"#Option_2_WordPress_Multisite\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Option 2: WordPress Multisite<\/a><\/li><li><a href=\"#Option_3_Separate_installations_with_persite_users_recommended\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Option 3: Separate installations with per\u2011site users (recommended)<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_Linux_Users_and_Folder_Structure_for_Isolation\"><span class=\"toc_number toc_depth_1\">3<\/span> Designing Linux Users and Folder Structure for Isolation<\/a><ul><li><a href=\"#Persite_Linux_users\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Per\u2011site Linux users<\/a><\/li><li><a href=\"#Directory_layout_per_site\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Directory layout per site<\/a><\/li><li><a href=\"#File_permissions_and_ownership\"><span class=\"toc_number toc_depth_2\">3.3<\/span> File permissions and ownership<\/a><\/li><\/ul><\/li><li><a href=\"#Nginx_vHosts_Server_Blocks_for_Multiple_WordPress_Sites\"><span class=\"toc_number toc_depth_1\">4<\/span> Nginx vHosts (Server Blocks) for Multiple WordPress Sites<\/a><ul><li><a href=\"#Basic_Nginx_vHost_structure_for_one_WordPress_site\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Basic Nginx vHost structure for one WordPress site<\/a><\/li><li><a href=\"#One_IP_many_HTTPS_sites_SNI\"><span class=\"toc_number toc_depth_2\">4.2<\/span> One IP, many HTTPS sites (SNI)<\/a><\/li><li><a href=\"#Persite_logging\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Per\u2011site logging<\/a><\/li><li><a href=\"#Performance_microcaching_and_static_assets\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Performance: microcaching and static assets<\/a><\/li><\/ul><\/li><li><a href=\"#PerSite_PHPFPM_Pools_and_Databases\"><span class=\"toc_number toc_depth_1\">5<\/span> Per\u2011Site PHP\u2011FPM Pools and Databases<\/a><ul><li><a href=\"#One_PHPFPM_pool_per_site\"><span class=\"toc_number toc_depth_2\">5.1<\/span> One PHP\u2011FPM pool per site<\/a><\/li><li><a href=\"#Separate_databases_and_DB_users\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Separate databases and DB users<\/a><\/li><li><a href=\"#PHP_versions_per_site_optional_but_useful\"><span class=\"toc_number toc_depth_2\">5.3<\/span> PHP versions per site (optional but useful)<\/a><\/li><\/ul><\/li><li><a href=\"#Practical_Setup_StepbyStep_Workflow_on_a_Fresh_VPS\"><span class=\"toc_number toc_depth_1\">6<\/span> Practical Setup: Step\u2011by\u2011Step Workflow on a Fresh VPS<\/a><ul><li><a href=\"#1_Prepare_the_VPS_and_base_security\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. Prepare the VPS and base security<\/a><\/li><li><a href=\"#2_Install_Nginx_PHPFPM_and_MariaDBMySQL\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Install Nginx, PHP\u2011FPM and MariaDB\/MySQL<\/a><\/li><li><a href=\"#3_Create_the_first_site_user_and_directory_structure\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Create the first site user and directory structure<\/a><\/li><li><a href=\"#4_Configure_the_PHPFPM_pool\"><span class=\"toc_number toc_depth_2\">6.4<\/span> 4. Configure the PHP\u2011FPM pool<\/a><\/li><li><a href=\"#5_Configure_the_database_for_this_site\"><span class=\"toc_number toc_depth_2\">6.5<\/span> 5. Configure the database for this site<\/a><\/li><li><a href=\"#6_Configure_Nginx_vHost_and_SSL\"><span class=\"toc_number toc_depth_2\">6.6<\/span> 6. Configure Nginx vHost and SSL<\/a><\/li><li><a href=\"#7_Install_WordPress_under_the_site_user\"><span class=\"toc_number toc_depth_2\">6.7<\/span> 7. Install WordPress under the site user<\/a><\/li><\/ul><\/li><li><a href=\"#Management_Backups_and_Monitoring_for_Many_Sites\"><span class=\"toc_number toc_depth_1\">7<\/span> Management, Backups and Monitoring for Many Sites<\/a><ul><li><a href=\"#Centralized_but_persite_aware_backups\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Centralized but per\u2011site aware backups<\/a><\/li><li><a href=\"#Updates_and_maintenance\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Updates and maintenance<\/a><\/li><li><a href=\"#Monitoring_and_capacity_planning\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Monitoring and capacity planning<\/a><\/li><li><a href=\"#When_to_move_to_multiple_VPS_or_a_more_advanced_stack\"><span class=\"toc_number toc_depth_2\">7.4<\/span> When to move to multiple VPS or a more advanced stack<\/a><\/li><\/ul><\/li><li><a href=\"#Conclusion_A_Clean_Blueprint_for_MultiSite_WordPress_on_One_VPS\"><span class=\"toc_number toc_depth_1\">8<\/span> Conclusion: A Clean Blueprint for Multi\u2011Site WordPress on One VPS<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Host_Multiple_WordPress_Sites_on_One_VPS\">Why Host Multiple WordPress Sites on One VPS?<\/span><\/h2>\n<p>Before diving into users and vHosts, it helps to be clear about <strong>why<\/strong> you would consolidate multiple sites on a single VPS instead of using several shared hosting plans or separate small servers.<\/p>\n<h3><span id=\"Cost_efficiency_without_losing_control\">Cost efficiency without losing control<\/span><\/h3>\n<p>A reasonably sized VPS with NVMe storage and a few vCPUs can handle many small to medium WordPress sites if you configure it correctly. Instead of paying for multiple small hosting plans, you pay once for a VPS and divide its resources yourself. On dchost.com, many agencies start with one VPS and grow into larger instances as their portfolio expands, instead of juggling dozens of separate accounts.<\/p>\n<h3><span id=\"Consistent_stack_and_tooling\">Consistent stack and tooling<\/span><\/h3>\n<p>When all your sites live on one VPS, you control:<\/p>\n<ul>\n<li>The Linux distribution and version<\/li>\n<li>PHP versions and extensions<\/li>\n<li>Web server (Nginx), global modules and tuning<\/li>\n<li>Monitoring, backup and security policies<\/li>\n<\/ul>\n<p>This consistency is a big productivity win. You can apply the same deployment flow, the same backup tooling and the same security hardening to every site. If you are curious about what we usually do on a fresh machine, our guide on the <a href=\"https:\/\/www.dchost.com\/blog\/en\/yeni-vpste-ilk-24-saat-guncelleme-guvenlik-duvari-ve-kullanici-hesaplari\/\">first 24 hours on a new VPS<\/a> is a useful companion to this article.<\/p>\n<h3><span id=\"Better_performance_than_generic_shared_hosting\">Better performance than generic shared hosting<\/span><\/h3>\n<p>On a VPS, you are not sharing CPU, RAM and disk I\/O with hundreds of strangers. Even if you run 10\u201320 WordPress sites, you can tune Nginx, PHP\u2011FPM and MySQL\/MariaDB for your exact workload. With proper caching and NVMe disks, one well\u2011configured VPS often beats low\u2011end shared hosting for both TTFB and stability. If you want a deeper dive into how server choices affect speed, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/core-web-vitals-ve-hosting-altyapisi-ttfb-lcp-ve-clsyi-sunucu-tarafinda-iyilestirme-rehberi\/\">server\u2011side Core Web Vitals tuning<\/a>.<\/p>\n<h3><span id=\"The_big_caveat_isolation_matters\">The big caveat: isolation matters<\/span><\/h3>\n<p>The downside is risk concentration. If you throw every site under the same Linux user, using the same PHP pool and same document root, then:<\/p>\n<ul>\n<li>One vulnerable plugin can give an attacker write access to all sites\u2019 files.<\/li>\n<li>One runaway plugin or cron job can consume all PHP workers and CPU.<\/li>\n<li>File permissions become messy, and backups are harder to reason about.<\/li>\n<\/ul>\n<p>The solution is to treat each WordPress site as its own <strong>tenant<\/strong>: one Unix user, one home directory, one PHP\u2011FPM pool, one database and one Nginx server block. Let\u2019s break that down.<\/p>\n<h2><span id=\"Isolation_Models_One_Server_Many_Sites_Without_CrossContamination\">Isolation Models: One Server, Many Sites Without Cross\u2011Contamination<\/span><\/h2>\n<p>When you say \u201cmultiple WordPress sites on one VPS\u201d, you can mean different things architecturally. The isolation model you choose has a huge impact on security, manageability and scaling.<\/p>\n<h3><span id=\"Option_1_Everything_under_one_Linux_user_what_not_to_do\">Option 1: Everything under one Linux user (what not to do)<\/span><\/h3>\n<p>This is the classic \u201cquick and dirty\u201d setup:<\/p>\n<ul>\n<li>One system user (often <code>www-data<\/code> or <code>nginx<\/code>)<\/li>\n<li>All document roots under something like <code>\/var\/www\/site1<\/code>, <code>\/var\/www\/site2<\/code>, \u2026<\/li>\n<li>One PHP\u2011FPM pool, shared by all sites<\/li>\n<\/ul>\n<p>It works, but isolation is almost zero. A vulnerability in one site can quickly become a vulnerability in all. For hobby projects this might be acceptable, but for client work it is not.<\/p>\n<h3><span id=\"Option_2_WordPress_Multisite\">Option 2: WordPress Multisite<\/span><\/h3>\n<p>WordPress Multisite runs multiple sites from a single codebase and database (with per\u2011site tables). It is great for networks where all sites share almost the same plugins, themes and policies (for example, a university or a franchise chain). But it is <strong>not<\/strong> ideal when you want strong isolation between independent projects or clients. Our dedicated guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-multisite-mi-ayri-kurulumlar-mi-cok-dilli-ve-cok-markali-siteler-icin-dogru-mimari\/\">WordPress Multisite vs separate installations<\/a> goes deeper into this trade\u2011off.<\/p>\n<h3><span id=\"Option_3_Separate_installations_with_persite_users_recommended\">Option 3: Separate installations with per\u2011site users (recommended)<\/span><\/h3>\n<p>The model we recommend for agencies and power users on a VPS is:<\/p>\n<ul>\n<li><strong>One Linux user per site<\/strong> (e.g., <code>wp_site1<\/code>, <code>wp_site2<\/code>)<\/li>\n<li><strong>Separate document root<\/strong> under each user\u2019s home directory<\/li>\n<li><strong>Separate PHP\u2011FPM pool<\/strong> running under that user<\/li>\n<li><strong>Separate database<\/strong> and DB user per site<\/li>\n<li><strong>One Nginx server block (vHost)<\/strong> per domain<\/li>\n<\/ul>\n<p>This looks more complex at first, but it pays off in lower risk, easier debugging and predictable performance. If <code>wp_site3<\/code> gets hacked, the attacker only has that user\u2019s permissions, not the entire server.<\/p>\n<h2><span id=\"Designing_Linux_Users_and_Folder_Structure_for_Isolation\">Designing Linux Users and Folder Structure for Isolation<\/span><\/h2>\n<p>Everything starts with a clean user and directory layout. If you get this right, Nginx, PHP\u2011FPM and backups all fall into place more naturally.<\/p>\n<h3><span id=\"Persite_Linux_users\">Per\u2011site Linux users<\/span><\/h3>\n<p>For each WordPress site, create a dedicated Linux user with no shell or with a restricted shell if you do not want to give SSH access:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">adduser --disabled-password --gecos &quot;&quot; wp_site1\n<\/code><\/pre>\n<p>You can later grant SSH access (with keys only) to specific users if needed. Keeping each site under its own user ensures:<\/p>\n<ul>\n<li>File permissions are clean and predictable.<\/li>\n<li>One compromised site cannot overwrite files of another site.<\/li>\n<li>Per\u2011site resource limits (through PHP\u2011FPM and ulimits) actually work.<\/li>\n<\/ul>\n<p>For a deeper dive into structuring Linux users and sudo for multi\u2011project setups, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/linux-vpste-kullanici-grup-ve-sudo-mimarisi-coklu-proje-ve-ekipler-icin-yetki-tasarimi\/\">designing Linux users, groups and sudo on a VPS<\/a>.<\/p>\n<h3><span id=\"Directory_layout_per_site\">Directory layout per site<\/span><\/h3>\n<p>A clean pattern we like is:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">\/home\/wp_site1\/\n  public\/      # Document root (WordPress core files here)\n  logs\/        # Access and error logs for this site\n  tmp\/         # Temporary files, cache, uploads temp\n  backups\/     # Optional per\u2011site backups\n<\/code><\/pre>\n<p>Then in Nginx, you will set <code>root \/home\/wp_site1\/public;<\/code>. This keeps each site self\u2011contained and makes it easy to tar\/rsync one site for migration or backup.<\/p>\n<h3><span id=\"File_permissions_and_ownership\">File permissions and ownership<\/span><\/h3>\n<p>Within each site directory:<\/p>\n<ul>\n<li>All files should be owned by the site user, e.g. <code>wp_site1:wp_site1<\/code>.<\/li>\n<li>Directories typically <code>755<\/code>, files <code>644<\/code>.<\/li>\n<li>Never run the PHP\u2011FPM pool as <code>root<\/code> or a shared web user that owns other sites\u2019 files.<\/li>\n<\/ul>\n<p>With this approach, when WordPress writes to <code>wp-content\/uploads<\/code>, it does so as its dedicated Unix user. If another site is compromised, its user still cannot modify these files directly.<\/p>\n<h2><span id=\"Nginx_vHosts_Server_Blocks_for_Multiple_WordPress_Sites\">Nginx vHosts (Server Blocks) for Multiple WordPress Sites<\/span><\/h2>\n<p>Once your users and directories are in place, Nginx becomes the traffic router. Each domain (or subdomain) gets its own <strong>server block<\/strong>. This is where you wire domains, document roots, <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s and PHP\u2011FPM sockets together.<\/p>\n<h3><span id=\"Basic_Nginx_vHost_structure_for_one_WordPress_site\">Basic Nginx vHost structure for one WordPress site<\/span><\/h3>\n<p>A simplified example for <code>example.com<\/code>:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">server {\n    listen 80;\n    listen [::]:80;\n    server_name example.com www.example.com;\n\n    root \/home\/wp_site1\/public;\n    index index.php index.html;\n\n    access_log \/home\/wp_site1\/logs\/access.log;\n    error_log  \/home\/wp_site1\/logs\/error.log;\n\n    location \/ {\n        try_files $uri $uri\/ \/index.php?$args;\n    }\n\n    location ~ .php$ {\n        include fastcgi_params;\n        fastcgi_pass unix:\/run\/php-fpm-wp_site1.sock;\n        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n        fastcgi_buffering on;\n    }\n\n    location ~* .(jpg|jpeg|png|gif|css|js|ico|webp|avif)$ {\n        expires 30d;\n        access_log off;\n    }\n}\n<\/code><\/pre>\n<p>You would then add a separate <code>server<\/code> block listening on 443 with SSL enabled. If you want to deepen your Nginx knowledge for small projects, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginx-reverse-proxy-ve-basit-load-balancer-kurulumu-kucuk-projeler-icin-uygulamali-rehber\/\">Nginx reverse proxy and load balancer setup<\/a> offers good context.<\/p>\n<h3><span id=\"One_IP_many_HTTPS_sites_SNI\">One IP, many HTTPS sites (SNI)<\/span><\/h3>\n<p>You do <strong>not<\/strong> need a separate IP address for each SSL site. Thanks to SNI (Server Name Indication), Nginx can serve many HTTPS domains from one IP, each with its own certificate. We have a detailed article on this pattern in <a href=\"https:\/\/www.dchost.com\/blog\/en\/tek-ip-uzerinde-birden-fazla-https-site-barindirmak-sni-nedir\/\">hosting multiple HTTPS websites on one IP with SNI<\/a>. In practice, each site will have its own <code>server_name<\/code> and <code>ssl_certificate<\/code> directives, but all share the same <code>listen 443 ssl;<\/code> socket.<\/p>\n<h3><span id=\"Persite_logging\">Per\u2011site logging<\/span><\/h3>\n<p>Notice that in the example we wrote logs to <code>\/home\/wp_site1\/logs<\/code>. This is not required, but very helpful:<\/p>\n<ul>\n<li>You can give a developer access only to that site\u2019s logs.<\/li>\n<li>Disk usage stays predictable and is easy to clean with logrotate.<\/li>\n<li>Troubleshooting is faster because you do not sift through a giant shared logfile.<\/li>\n<\/ul>\n<h3><span id=\"Performance_microcaching_and_static_assets\">Performance: microcaching and static assets<\/span><\/h3>\n<p>For high\u2011traffic blogs, you can add Nginx microcaching in front of PHP to dramatically reduce load. This still plays nicely with per\u2011site isolation. If you are curious about this pattern, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginx-mikro-onbellekleme-ile-php-uygulamalarini-ucurmak-1-5-sn-cache-bypass-ve-purge-ne-zaman-nasil\/\">Nginx microcaching for PHP apps<\/a> shows how a 1\u20135 second cache can make sites feel instantly faster while staying cache\u2011friendly for logged\u2011out users.<\/p>\n<h2><span id=\"PerSite_PHPFPM_Pools_and_Databases\">Per\u2011Site PHP\u2011FPM Pools and Databases<\/span><\/h2>\n<p>Nginx hands dynamic requests to PHP\u2011FPM. This is where you enforce resource isolation: how many PHP workers each site can use, which Unix user they run as and what limits they respect.<\/p>\n<h3><span id=\"One_PHPFPM_pool_per_site\">One PHP\u2011FPM pool per site<\/span><\/h3>\n<p>On most distributions, PHP\u2011FPM pool configs live under <code>\/etc\/php\/8.2\/fpm\/pool.d\/<\/code> (version may differ). For <code>wp_site1<\/code>, you might have:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">[wp_site1]\nuser = wp_site1\ngroup = wp_site1\nlisten = \/run\/php-fpm-wp_site1.sock\nlisten.owner = nginx\nlisten.group = nginx\npm = dynamic\npm.max_children = 5\npm.start_servers = 2\npm.min_spare_servers = 1\npm.max_spare_servers = 3\nphp_admin_value[upload_max_filesize] = 64M\nphp_admin_value[post_max_size] = 64M\nphp_admin_value[memory_limit] = 256M\n<\/code><\/pre>\n<p>Then Nginx\u2019s <code>fastcgi_pass<\/code> points to this socket. Each site gets its own pool, with its own limits. If one site receives a traffic spike or runs a heavy plugin, it can exhaust <code>pm.max_children<\/code> for <em>its<\/em> pool but not for others.<\/p>\n<p>If you need help sizing these values, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-php-fpm-ayarlari-pm-pm-max_children-ve-pm-max_requests-hesaplama-rehberi\/\">PHP\u2011FPM settings for WordPress and WooCommerce<\/a> explains how to calculate sane defaults based on CPU and RAM.<\/p>\n<h3><span id=\"Separate_databases_and_DB_users\">Separate databases and DB users<\/span><\/h3>\n<p>Likewise, each WordPress site should have its own database and its own database user:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">CREATE DATABASE wp_site1_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;\nCREATE USER 'wp_site1_dbuser'@'localhost' IDENTIFIED BY 'strongpassword';\nGRANT ALL PRIVILEGES ON wp_site1_db.* TO 'wp_site1_dbuser'@'localhost';\nFLUSH PRIVILEGES;\n<\/code><\/pre>\n<p>Then in <code>wp-config.php<\/code> you reference this DB. This way, even if one site\u2019s DB credentials leak, the attacker only gets access to that site\u2019s database, not everyone else\u2019s.<\/p>\n<h3><span id=\"PHP_versions_per_site_optional_but_useful\">PHP versions per site (optional but useful)<\/span><\/h3>\n<p>On a VPS, you can install multiple PHP versions and run different pools per version. For example, an old plugin that is not yet compatible with PHP 8.2 could temporarily stay on 8.0, while new sites run on 8.2. Your Nginx vHost simply points each site to the appropriate PHP\u2011FPM socket. If you plan a major upgrade, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-8-x-yukseltme-kontrol-listesi-wordpress-ve-laravelde-geriye-uyumluluk-opcache-preload-ve-fpm-havuz-ayarlari-nasil-tatli-tatli-kurulur\/\">PHP 8.x upgrade checklist<\/a> is a good roadmap.<\/p>\n<h2><span id=\"Practical_Setup_StepbyStep_Workflow_on_a_Fresh_VPS\">Practical Setup: Step\u2011by\u2011Step Workflow on a Fresh VPS<\/span><\/h2>\n<p>Let\u2019s connect the dots into a practical workflow you might follow on a new VPS from dchost.com.<\/p>\n<h3><span id=\"1_Prepare_the_VPS_and_base_security\">1. Prepare the VPS and base security<\/span><\/h3>\n<ol>\n<li>Update packages and enable automatic security updates.<\/li>\n<li>Harden SSH: disable password logins, change the default port if you prefer, use SSH keys.<\/li>\n<li>Set up a basic firewall (e.g. <code>ufw<\/code> or <code>firewalld<\/code>) allowing only SSH, HTTP and HTTPS.<\/li>\n<li>Install Fail2ban or a similar tool to rate\u2011limit brute\u2011force attempts.<\/li>\n<\/ol>\n<p>Our detailed checklist in <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-nasil-saglanir-kapiyi-acik-birakmadan-yasamanin-sirri\/\">how to secure a VPS server<\/a> walks through these steps in depth.<\/p>\n<h3><span id=\"2_Install_Nginx_PHPFPM_and_MariaDBMySQL\">2. Install Nginx, PHP\u2011FPM and MariaDB\/MySQL<\/span><\/h3>\n<p>Use your distro\u2019s packages or preferred repositories to install:<\/p>\n<ul>\n<li>Nginx (or Nginx + a control panel if you like GUI management)<\/li>\n<li>PHP\u2011FPM (with common extensions: <code>mysqli<\/code>, <code>mbstring<\/code>, <code>curl<\/code>, <code>zip<\/code>, <code>intl<\/code>, <code>imagick<\/code> or <code>gd<\/code>)<\/li>\n<li>MariaDB or MySQL server<\/li>\n<\/ul>\n<p>Secure the database server with <code>mysql_secure_installation<\/code> (or equivalent): set a strong root password, remove anonymous users and test databases you do not need.<\/p>\n<h3><span id=\"3_Create_the_first_site_user_and_directory_structure\">3. Create the first site user and directory structure<\/span><\/h3>\n<ol>\n<li>Create the site user: <code>adduser --disabled-password wp_site1<\/code>.<\/li>\n<li>Create directories: <code>mkdir -p \/home\/wp_site1\/public \/home\/wp_site1\/logs \/home\/wp_site1\/tmp<\/code>.<\/li>\n<li>Set ownership: <code>chown -R wp_site1:wp_site1 \/home\/wp_site1<\/code>.<\/li>\n<\/ol>\n<p>Repeat this pattern for each additional site you plan to host.<\/p>\n<h3><span id=\"4_Configure_the_PHPFPM_pool\">4. Configure the PHP\u2011FPM pool<\/span><\/h3>\n<ol>\n<li>Create a pool config, e.g. <code>\/etc\/php\/8.2\/fpm\/pool.d\/wp_site1.conf<\/code>.<\/li>\n<li>Set <code>user<\/code>, <code>group<\/code>, <code>listen<\/code> (socket path) and <code>pm.*<\/code> parameters.<\/li>\n<li>Reload PHP\u2011FPM: <code>systemctl reload php8.2-fpm<\/code>.<\/li>\n<\/ol>\n<p>Check that the socket file (e.g. <code>\/run\/php-fpm-wp_site1.sock<\/code>) exists and has the right owner\/group.<\/p>\n<h3><span id=\"5_Configure_the_database_for_this_site\">5. Configure the database for this site<\/span><\/h3>\n<p>Create the database and user as shown earlier, or with your favorite admin tool. Note down:<\/p>\n<ul>\n<li>Database name<\/li>\n<li>Database user<\/li>\n<li>Password<\/li>\n<\/ul>\n<p>You will use these when installing WordPress.<\/p>\n<h3><span id=\"6_Configure_Nginx_vHost_and_SSL\">6. Configure Nginx vHost and SSL<\/span><\/h3>\n<ol>\n<li>Create an Nginx server block in <code>\/etc\/nginx\/sites-available\/example.com<\/code>.<\/li>\n<li>Point <code>root<\/code> to <code>\/home\/wp_site1\/public<\/code> and logs to <code>\/home\/wp_site1\/logs<\/code>.<\/li>\n<li>Set <code>server_name<\/code> for your domain(s).<\/li>\n<li>Point <code>fastcgi_pass<\/code> to the correct PHP\u2011FPM socket.<\/li>\n<li>Enable the vHost by symlinking into <code>sites-enabled<\/code> and reload Nginx.<\/li>\n<\/ol>\n<p>For SSL, use an ACME client like <code>certbot<\/code> or <code>acme.sh<\/code> to obtain Let\u2019s Encrypt certificates, then configure <code>listen 443 ssl;<\/code> with <code>ssl_certificate<\/code> and <code>ssl_certificate_key<\/code> paths. Our series of articles about <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sertifika-otomasyonunda-yenilikler\/\">SSL certificate automation<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sertifika-otomasyonu-inovasyonlari-acme-dns-01-ve-cok-kiracili-mimariler\/\">modern ACME strategies<\/a> cover more advanced multi\u2011tenant SSL setups.<\/p>\n<h3><span id=\"7_Install_WordPress_under_the_site_user\">7. Install WordPress under the site user<\/span><\/h3>\n<p>Switch to the site user (or use <code>sudo -u wp_site1<\/code>) and install WordPress into <code>\/home\/wp_site1\/public<\/code>:<\/p>\n<ol>\n<li>Download latest WordPress.<\/li>\n<li>Extract into <code>public<\/code>.<\/li>\n<li>Set ownership to <code>wp_site1:wp_site1<\/code> if needed.<\/li>\n<li>Visit <code>http:\/\/example.com<\/code> in a browser and complete the installer using the per\u2011site DB credentials.<\/li>\n<\/ol>\n<p>When you repeat this process for the second and third site, you will quickly build a comfortable rhythm: user \u2192 dirs \u2192 FPM pool \u2192 DB \u2192 Nginx vHost \u2192 WordPress install.<\/p>\n<h2><span id=\"Management_Backups_and_Monitoring_for_Many_Sites\">Management, Backups and Monitoring for Many Sites<\/span><\/h2>\n<p>Once your multi\u2011site VPS is running, long\u2011term success depends on how you handle updates, backups and monitoring. With multiple tenants, a small oversight can affect more people.<\/p>\n<h3><span id=\"Centralized_but_persite_aware_backups\">Centralized but per\u2011site aware backups<\/span><\/h3>\n<p>For backups, you want both:<\/p>\n<ul>\n<li>A <strong>full\u2011server backup<\/strong> (so you can quickly recover the whole VPS), and<\/li>\n<li><strong>Per\u2011site backups<\/strong> (so you can restore one site without rolling back everything else).<\/li>\n<\/ul>\n<p>Because each site is in its own directory and has its own database, it is easy to script per\u2011site backups that:<\/p>\n<ul>\n<li>Dump the database (<code>mysqldump<\/code> or <code>mariabackup<\/code> for larger setups).<\/li>\n<li>Tar or rsync <code>\/home\/wp_siteX\/public<\/code>.<\/li>\n<li>Upload encrypted archives to remote object storage.<\/li>\n<\/ul>\n<p>If you want a structured way to design this, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/\">backup strategy, RPO and RTO planning<\/a> gives real\u2011world examples for blogs, e\u2011commerce and SaaS.<\/p>\n<h3><span id=\"Updates_and_maintenance\">Updates and maintenance<\/span><\/h3>\n<p>With several sites on one VPS, updates should be regular and disciplined:<\/p>\n<ul>\n<li>Schedule a weekly maintenance window to update WordPress core, themes and plugins.<\/li>\n<li>Keep PHP and Nginx reasonably up to date, but test on a staging site first.<\/li>\n<li>Use tools like <code>wp-cli<\/code> to automate updates across multiple installations.<\/li>\n<li>Document which site uses which PHP version and which custom modules.<\/li>\n<\/ul>\n<p>For riskier changes (PHP upgrades, major WooCommerce versions), consider a staging copy of the critical sites. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-wordpress-staging-ortami-kurmak-adim-adim-uygulamali-rehber\/\">WordPress staging environments<\/a> explains patterns that apply just as well to a VPS.<\/p>\n<h3><span id=\"Monitoring_and_capacity_planning\">Monitoring and capacity planning<\/span><\/h3>\n<p>Monitoring becomes more important as you add sites:<\/p>\n<ul>\n<li>Use tools like <code>htop<\/code>, <code>top<\/code>, <code>ngxtop<\/code> or more advanced stacks (Prometheus + Grafana) to watch CPU, RAM and I\/O.<\/li>\n<li>Enable per\u2011site access logs and occasionally scan them for slow responses or frequent 5xx errors.<\/li>\n<li>Set up external uptime monitoring and SSL expiry alerts.<\/li>\n<\/ul>\n<p>When a site grows enough to regularly saturate its PHP\u2011FPM pool or database, that is usually your signal to either increase VPS resources at dchost.com or move that particular site to its own VPS or dedicated cluster.<\/p>\n<h3><span id=\"When_to_move_to_multiple_VPS_or_a_more_advanced_stack\">When to move to multiple VPS or a more advanced stack<\/span><\/h3>\n<p>One VPS with isolated sites is a great starting point, but there are natural limits. Consider breaking things up when:<\/p>\n<ul>\n<li>One or two sites generate most of the traffic and CPU load.<\/li>\n<li>You have strict compliance or data\u2011segregation requirements for certain clients.<\/li>\n<li>You need advanced high\u2011availability features (database replication, multi\u2011region, etc.).<\/li>\n<\/ul>\n<p>Our WordPress scaling roadmap in <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-olceklendirme-yol-haritasi-paylasimli-hostingden-yonetilen-wordpress-ve-vps-kume-mimarilerine-gecis\/\">scaling WordPress from shared hosting to VPS clusters<\/a> shows how to evolve from a single VPS into more complex architectures when the time is right.<\/p>\n<h2><span id=\"Conclusion_A_Clean_Blueprint_for_MultiSite_WordPress_on_One_VPS\">Conclusion: A Clean Blueprint for Multi\u2011Site WordPress on One VPS<\/span><\/h2>\n<p>Hosting multiple WordPress sites on a single VPS is not just about copying more files into <code>\/var\/www<\/code>. If you want real isolation, predictable performance and easier maintenance, you need a deliberate architecture: one Linux user per site, one PHP\u2011FPM pool per site, one database per site and one Nginx vHost per domain. This approach keeps blast radius small, simplifies backups and makes it much easier to scale specific projects without touching others.<\/p>\n<p>At dchost.com, we see agencies and developers succeed with this pattern every day. Start with a properly sized VPS (NVMe disk, sufficient RAM and vCPUs), implement the structure described here, then layer on monitoring, automated backups and a simple update routine. When one of your sites becomes a real traffic magnet, you will be able to move it to a larger VPS or dedicated stack with minimal friction, because it is already logically isolated. If you are planning your own multi\u2011site VPS and want to align domain, DNS and hosting choices from day one, our overview of <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-en-iyi-hosting-secimi-paylasimli-yonetilen-ve-vps-karsilastirmasi\/\">the best hosting options for WordPress<\/a> is a good next read.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Running several WordPress sites on a single VPS is one of the most efficient ways to balance cost, performance and control. But there is a big difference between simply dropping multiple sites into one directory and designing a properly isolated hosting stack with separate Linux users, Nginx virtual hosts and per\u2011site PHP\u2011FPM pools. Done right, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4504,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4503","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4503"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4503\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4504"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}