{"id":23884,"date":"2026-08-02T07:48:09","date_gmt":"2026-08-02T07:48:09","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=23884"},"modified":"2026-08-02T10:19:08","modified_gmt":"2026-08-02T10:19:08","slug":"how-to-host-multiple-websites-on-one-vps","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/es\/how-to-host-multiple-websites-on-one-vps\/","title":{"rendered":"How to Host Multiple Websites on One VPS | Atal Networks"},"content":{"rendered":"

Paying for five separate hosting plans to run five low-traffic sites is money left on the table. One properly configured VPS handles them all, and every site performs better than it would on shared hosting.<\/span><\/p>\n

Hosting multiple websites on one VPS works by running a web server like Nginx or Apache that reads the domain name in each incoming HTTP request and routes it to the correct site directory. Each site gets its own document root, database, SSL certificate, and PHP process pool. One server, one IP address, as many domains as your RAM and CPU can support.<\/span><\/p>\n

This guide covers the complete setup: directory structure, Nginx server blocks, Apache virtual hosts, PHP-FPM pool isolation, free SSL with Certbot, security hardening, Redis caching, automated backups, and a clear framework for knowing when a single VPS is no longer enough.<\/span><\/p>\n

Can You Host Multiple Websites on One VPS?<\/span><\/h2>\n

A single VPS can host anywhere from 3 to 20+ websites. The web server software handles all traffic routing. Nginx uses server blocks and Apache uses virtual hosts. Both work by reading the <\/span>Host<\/span> header in each HTTP request and matching it to a configured domain name. The matched domain maps to a specific directory on disk, where the site’s files live. One IP address, one server, many domains.<\/span><\/p>\n

This works at the KVM virtualization layer too. Our <\/span>Linux VPS hosting<\/span><\/a> plans run KVM-based isolation, meaning your VPS has a fixed slice of CPU and RAM that no other customer shares. That isolation is what makes multi-site consolidation on a VPS reliable, unlike shared hosting, where hundreds of accounts compete for the same physical resources with no guaranteed allocation.<\/span><\/p>\n

How Many Sites Can One VPS Handle?<\/span><\/h3>\n

The honest answer depends on traffic volume and whether your sites use caching. Here is a practical reference based on real-world WordPress deployments:<\/span><\/p>\n\n\n\n\n\n\n\n
VPS Specs<\/b><\/th>\nLow-Traffic Sites (<500 visitors\/day)<\/b><\/th>\nMedium-Traffic Sites (500\u20135,000\/day)<\/b><\/th>\n<\/tr>\n<\/thead>\n
2 vCPU \/ 2 GB RAM<\/span><\/td>\n3\u20135 sites<\/span><\/td>\n1\u20132 sites<\/span><\/td>\n<\/tr>\n
2 vCPU \/ 4 GB RAM<\/span><\/td>\n5\u201310 sites<\/span><\/td>\n3\u20135 sites<\/span><\/td>\n<\/tr>\n
4 vCPU \/ 8 GB RAM<\/span><\/td>\n10\u201320 sites<\/span><\/td>\n5\u201310 sites<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The bottleneck is almost always RAM. Use this formula to size PHP-FPM workers:<\/span><\/p>\n

max_children = available_RAM_for_PHP \u00f7 average_PHP_process_size_MB<\/span><\/p>\n

Average WordPress PHP-FPM process: 30\u201350 MB. On a 4 GB VPS, reserve 1 GB for the OS and MariaDB. That leaves 3 GB for PHP, which supports roughly 60\u2013100 total workers across all sites. With Redis object caching enabled, these numbers are conservative because Redis absorbs most database reads before PHP ever sees them.<\/span><\/p>\n

Shared Hosting vs. VPS for Multiple Sites<\/span><\/h3>\n

Shared hosting puts hundreds of tenants on one machine with no resource guarantees. When one site spikes in traffic, every other site on that machine slows down. A VPS gives you a dedicated slice of CPU and RAM. PHP-FPM pools keep each site’s processes isolated so a traffic spike on site1.com cannot starve site2.com of workers.<\/span><\/p>\n

Before You Start: Prerequisites<\/span><\/h2>\n

Get these in place before touching any configuration files:<\/span><\/p>\n

    \n
  1. A VPS running Ubuntu 22.04 or 24.04 with root or sudo access<\/span><\/li>\n
  2. At least 2 GB RAM (4 GB recommended for 5+ sites)<\/span><\/li>\n
  3. Domain names registered with DNS A records pointing to your VPS public IP<\/span><\/li>\n
  4. SSH key authentication configured and password authentication disabled<\/span><\/li>\n
  5. Basic Linux command line familiarity (file editing, service management)<\/span><\/li>\n
  6. UFW firewall installed<\/span><\/li>\n<\/ol>\n

    DNS A records push out across global resolvers within 24\u201348 hours. Test resolution with <\/span>dig site1.com<\/span> before running web server configuration. If the command returns your VPS IP, the domain is ready.<\/span><\/p>\n

    Set Up Your Directory Structure First<\/span><\/h2>\n

    Most guides jump straight to web server configuration. Setting up a clean directory structure first saves hours of debugging later. Permissions, backup scripts, and log rotation all depend on a consistent layout.<\/span><\/p>\n

    \"Set<\/p>\n

    Use this structure for every site:<\/span><\/p>\n

    \/var\/www\/<\/span><\/p>\n

    \u251c\u2500\u2500 site1.com\/<\/span><\/p>\n

    \u2502 \u00a0 \u251c\u2500\u2500 public\/\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u2190 document root (web-accessible files)<\/span><\/p>\n

    \u2502 \u00a0 \u2514\u2500\u2500 logs\/\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u2190 per-site access and error logs<\/span><\/p>\n

    \u251c\u2500\u2500 site2.com\/<\/span><\/p>\n

    \u2502 \u00a0 \u251c\u2500\u2500 public\/<\/span><\/p>\n

    \u2502 \u00a0 \u2514\u2500\u2500 logs\/<\/span><\/p>\n

     <\/p>\n

    Create the directories:<\/span><\/p>\n

    sudo mkdir -p \/var\/www\/site1.com\/{public,logs}<\/span><\/p>\n

    sudo mkdir -p \/var\/www\/site2.com\/{public,logs}<\/span><\/p>\n

    sudo chown -R www-data:www-data \/var\/www\/site1.com\/public<\/span><\/p>\n

    sudo chown -R www-data:www-data \/var\/www\/site2.com\/public<\/span><\/p>\n

    sudo chmod -R 755 \/var\/www<\/span><\/p>\n

    Separate log directories per site mean you can run <\/span>tail -f \/var\/www\/site1.com\/logs\/error.log<\/span> to debug one site without seeing noise from all the others.<\/span><\/p>\n

    Create a Separate Linux User Per Site<\/span><\/h3>\n

    Running every site under <\/span>www-data<\/span> is the default and the wrong choice for multi-site security. If one site gets compromised, a process running as <\/span>www-data<\/span> can read every other site’s files and database credentials.<\/span><\/p>\n

     <\/p>\n

    A separate system user per site stops lateral movement after a compromise:<\/span><\/p>\n

    sudo adduser –no-create-home –shell \/usr\/sbin\/nologin site1user<\/span><\/p>\n

    sudo adduser –no-create-home –shell \/usr\/sbin\/nologin site2user<\/span><\/p>\n

    sudo chown -R site1user:www-data \/var\/www\/site1.com\/public<\/span><\/p>\n

    sudo chown -R site2user:www-data \/var\/www\/site2.com\/public<\/span><\/p>\n

    Each site’s PHP-FPM pool will run under its matching system user. A malicious script on site1.com runs as <\/span>site1user<\/span>, which has no read access to <\/span>\/var\/www\/site2.com\/<\/span>.<\/span><\/p>\n

    Install the Web Stack (Nginx + PHP-FPM + MariaDB)<\/span><\/h2>\n

    Update the system and install the full stack on Ubuntu 24.04:<\/span><\/p>\n

    sudo apt update && sudo apt upgrade -y<\/span><\/p>\n

    sudo apt install nginx mariadb-server php8.3-fpm \\<\/span><\/p>\n

    \u00a0\u00a0php8.3-mysql php8.3-curl php8.3-gd \\<\/span><\/p>\n

    \u00a0\u00a0php8.3-mbstring php8.3-xml php8.3-zip -y<\/span><\/p>\n

    sudo mysql_secure_installation<\/span><\/p>\n

    Answer yes to all <\/span>mysql_secure_installation<\/span> prompts: set a root password, remove anonymous users, disallow remote root login, remove the test database, and reload privileges.<\/span><\/p>\n

    Nginx uses an event-driven, asynchronous architecture that handles thousands of concurrent connections with minimal memory. Apache’s process-based model uses more RAM per connection but remains the better choice for applications that rely on <\/span>.htaccess<\/span> files or per-directory configuration without server-level config access. For most modern PHP and WordPress deployments, Nginx is the right default.<\/span><\/p>\n

    Configure Nginx Server Blocks for Multiple Domains<\/span><\/h2>\n

    Nginx reads the <\/span>Host<\/span> header on every incoming request and matches it against <\/span>server_name<\/span> directives in your configuration files. The matching block determines which document root serves the response. Multiple blocks share ports 80 and 443, and Nginx handles all routing internally.<\/span><\/p>\n

    Store each site’s configuration in <\/span>\/etc\/nginx\/sites-available\/<\/span>, then create a symlink to <\/span>\/etc\/nginx\/sites-enabled\/<\/span> to activate it. This separation lets you disable a site without deleting its config.<\/span><\/p>\n

    Create a Server Block for Each Domain<\/span><\/h3>\n

    \"Create<\/p>\n

    Full production-ready configuration for site1.com. Create the file:<\/span><\/p>\n

    sudo nano \/etc\/nginx\/sites-available\/site1.com<\/span><\/p>\n

    Paste this configuration:<\/span><\/p>\n

    server {<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0listen 80;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0listen [::]:80;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0server_name site1.com www.site1.com;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0root \/var\/www\/site1.com\/public;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0index index.php index.html;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0access_log \/var\/www\/site1.com\/logs\/access.log;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0error_log\u00a0 \/var\/www\/site1.com\/logs\/error.log;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0client_max_body_size 64M;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0# Security headers<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0add_header X-Frame-Options\u00a0 \u00a0 \u00a0 \u00a0 “SAMEORIGIN”\u00a0 \u00a0 always;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0add_header X-Content-Type-Options “nosniff” \u00a0 \u00a0 \u00a0 always;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0add_header X-XSS-Protection \u00a0 \u00a0 \u00a0 “1; mode=block” always;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0location \/ {<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try_files $uri $uri\/ \/index.php?$args;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

     <\/p>\n

    \u00a0\u00a0\u00a0\u00a0location ~ \\.php$ {<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0include snippets\/fastcgi-php.conf;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fastcgi_pass unix:\/run\/php\/php8.3-fpm-site1.sock;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

     <\/p>\n

    \u00a0\u00a0\u00a0\u00a0# Block access to sensitive files<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0location ~ \/\\.ht \u00a0 \u00a0 \u00a0 \u00a0 { deny all; }<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0location = \/wp-config.php { deny all; }<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0# Cache static assets at the browser level<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0location ~* \\.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0expires 30d;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0add_header Cache-Control “public, immutable”;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0}<\/span><\/p>\n

    }<\/span><\/p>\n

    Repeat the same process for site2.com, changing <\/span>server_name<\/span>, <\/span>root<\/span>, <\/span>access_log<\/span>, <\/span>error_log<\/span>, and the <\/span>fastcgi_pass<\/span> socket path.<\/span><\/p>\n

    Enable both sites, remove the default, and test:<\/span><\/p>\n

    sudo ln -s \/etc\/nginx\/sites-available\/site1.com \/etc\/nginx\/sites-enabled\/<\/span><\/p>\n

    sudo ln -s \/etc\/nginx\/sites-available\/site2.com \/etc\/nginx\/sites-enabled\/<\/span><\/p>\n

    sudo rm \/etc\/nginx\/sites-enabled\/default<\/span><\/p>\n

    sudo nginx -t<\/span><\/p>\n

    sudo systemctl reload nginx<\/span><\/p>\n

    A clean <\/span>nginx -t<\/span> output confirms no syntax errors before you reload.<\/span><\/p>\n

    Add a Catch-All Server Block (The Security Step Most Guides Skip)<\/span><\/h3>\n

    Without a catch-all default block, Nginx serves the first alphabetically-loaded config file to any request that does not match a known <\/span>server_name<\/span>. Automated scanners and bots probe VPS IP addresses constantly. Serving your site content to an unknown host header leaks information and can expose application details.<\/span><\/p>\n

    Add this block:<\/span><\/p>\n

    sudo nano \/etc\/nginx\/sites-available\/000-catch-all<\/span><\/p>\n

    server {<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0listen 80\u00a0 default_server;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0listen [::]:80 default_server;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0server_name _;<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0return 444;<\/span><\/p>\n

    }<\/span><\/p>\n

    sudo ln -s \/etc\/nginx\/sites-available\/000-catch-all \/etc\/nginx\/sites-enabled\/<\/span><\/p>\n

    sudo nginx -t && sudo systemctl reload nginx<\/span><\/p>\n

    Return code <\/span>444<\/span> closes the TCP connection immediately with no HTTP response. Scanners get nothing. The <\/span>000-<\/span> prefix in the filename ensures this block loads before your site configs alphabetically, making it the true default.<\/span><\/p>\n

    Apache Virtual Hosts (For Legacy or .htaccess-Dependent Apps)<\/span><\/h3>\n

    If your application requires <\/span>.htaccess<\/span> support or you are running legacy PHP software that expects Apache-style per-directory configuration, use Apache virtual hosts instead of Nginx server blocks.<\/span><\/p>\n

    Create the configuration file:<\/span><\/p>\n

    sudo nano \/etc\/apache2\/sites-available\/site1.com.conf<\/span><\/p>\n

    <VirtualHost *:80><\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0ServerName\u00a0 \u00a0 site1.com<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0ServerAlias \u00a0 www.site1.com<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0DocumentRoot\u00a0 \/var\/www\/site1.com\/public<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0ErrorLog\u00a0 \u00a0 \u00a0 \/var\/www\/site1.com\/logs\/error.log<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0CustomLog \u00a0 \u00a0 \/var\/www\/site1.com\/logs\/access.log combined<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0<Directory \/var\/www\/site1.com\/public><\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Options -Indexes +FollowSymLinks<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0AllowOverride All<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Require all granted<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0<\/Directory><\/span><\/p>\n

    <\/VirtualHost><\/span><\/p>\n

    Enable the site and reload:<\/span><\/p>\n

    sudo a2ensite site1.com.conf<\/span><\/p>\n

    sudo systemctl reload apache2<\/span><\/p>\n

    Repeat for each additional domain.<\/span><\/p>\n

    Configure Separate PHP-FPM Pools Per Site<\/span><\/h2>\n

    The default <\/span>www.conf<\/span> PHP-FPM pool runs all PHP requests under <\/span>www-data<\/span> with a shared process pool. A traffic spike on site1.com or a runaway WordPress cron job can exhaust all available PHP workers and crash every other site on the server. Separate pools prevent this entirely.<\/span><\/p>\n

     <\/p>\n

    Create a dedicated pool config for site1:<\/span><\/p>\n

    sudo nano \/etc\/php\/8.3\/fpm\/pool.d\/site1.conf<\/span><\/p>\n

    [site1]<\/span><\/p>\n

    user\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = site1user<\/span><\/p>\n

    group \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = www-data<\/span><\/p>\n

    listen\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = \/run\/php\/php8.3-fpm-site1.sock<\/span><\/p>\n

    listen.owner\u00a0 \u00a0 \u00a0 \u00a0 = www-data<\/span><\/p>\n

    listen.group\u00a0 \u00a0 \u00a0 \u00a0 = www-data<\/span><\/p>\n

    pm\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = dynamic<\/span><\/p>\n

    pm.max_children \u00a0 \u00a0 = 8<\/span><\/p>\n

    pm.start_servers\u00a0 \u00a0 = 2<\/span><\/p>\n

    pm.min_spare_servers = 1<\/span><\/p>\n

    pm.max_spare_servers = 3<\/span><\/p>\n

    pm.max_requests \u00a0 \u00a0 = 500<\/span><\/p>\n

    Duplicate this file for each site, incrementing the pool name, user, and socket path. Disable the default <\/span>www.conf<\/span> pool to prevent it from consuming resources:<\/span><\/p>\n

    sudo mv \/etc\/php\/8.3\/fpm\/pool.d\/www.conf \/etc\/php\/8.3\/fpm\/pool.d\/www.conf.disabled<\/span><\/p>\n

    sudo systemctl restart php8.3-fpm<\/span><\/p>\n

    Sizing guide:<\/b> On a 4 GB VPS, reserve 1 GB for the OS and MariaDB. 3 GB remains for PHP. At 40 MB average per WordPress PHP-FPM process, you have room for roughly 75 total workers. Across 10 sites, set <\/span>pm.max_children = 7<\/span> or <\/span>8<\/span> per site. Adjust based on each site’s traffic profile: a high-traffic site gets more workers, a low-traffic staging site gets fewer.<\/span><\/p>\n

    Verify the pools are running after restart:<\/span><\/p>\n

    sudo systemctl status php8.3-fpm<\/span><\/p>\n

    ls \/run\/php\/<\/span><\/p>\n

    You should see one <\/span>.sock<\/span> file per configured pool.<\/span><\/p>\n

    Install SSL Certificates for All Domains<\/span><\/h2>\n

    Every site on your VPS needs HTTPS. Let’s Encrypt provides free, automatically renewing SSL certificates through Certbot. Certbot covers all domains in a single command.<\/span><\/p>\n

    Install Certbot:<\/span><\/p>\n

    sudo apt install certbot python3-certbot-nginx -y<\/span><\/p>\n

    Generate certificates for all domains at once:<\/span><\/p>\n

    sudo certbot –nginx \\<\/span><\/p>\n

    \u00a0\u00a0-d site1.com -d www.site1.com \\<\/span><\/p>\n

    \u00a0\u00a0-d site2.com -d www.site2.com<\/span><\/p>\n

    Certbot modifies your Nginx server blocks automatically: it adds port 443 listeners, SSL certificate file paths, and HTTP-to-HTTPS redirect rules. After it runs, Nginx serves every site over HTTPS without any manual configuration changes.<\/span><\/p>\n

    Verify that auto-renewal works before trusting it:<\/span><\/p>\n

    sudo certbot renew –dry-run<\/span><\/p>\n

    A successful dry run confirms Certbot can reach Let’s Encrypt’s servers and renew certificates without human input. Certbot installs a systemd timer by default on Ubuntu. Check its status:<\/span><\/p>\n

    sudo systemctl status certbot.timer<\/span><\/p>\n

    SSL with Multiple Domains on One IP: SNI Explained<\/span><\/h3>\n

    Running multiple SSL certificates on one IP address works through Server Name Indication (SNI). During the TLS handshake, the client’s browser sends the requested hostname before the HTTP connection is established. Nginx reads that hostname and serves the matching certificate. Every browser released after 2010 supports SNI. You do not need a separate IP address per domain, and adding IP addresses solely for SSL is unnecessary cost.<\/span><\/p>\n

    Harden Security Across All Sites<\/span><\/h2>\n

    Enable UFW Firewall<\/span><\/h3>\n

    A firewall limits which ports accept connections. Only open what your server actually needs:<\/span><\/p>\n

    sudo ufw allow 22\/tcp\u00a0 \u00a0 # SSH<\/span><\/p>\n

    sudo ufw allow 80\/tcp\u00a0 \u00a0 # HTTP<\/span><\/p>\n

    sudo ufw allow 443\/tcp \u00a0 # HTTPS<\/span><\/p>\n

    sudo ufw enable<\/span><\/p>\n

    sudo ufw status<\/span><\/p>\n

    Everything else is blocked by default. If you run other services (mail, custom ports), add specific rules rather than opening broad ranges.<\/span><\/p>\n

    Install Fail2Ban<\/span><\/h3>\n

    Fail2Ban monitors log files for repeated failed login attempts and bans the offending IP address automatically. It protects SSH by default and can be extended to WordPress login pages and other web endpoints.<\/span><\/p>\n

    sudo apt install fail2ban -y<\/span><\/p>\n

    sudo systemctl enable fail2ban<\/span><\/p>\n

    Create a local jail configuration:<\/span><\/p>\n

    sudo nano \/etc\/fail2ban\/jail.local<\/span><\/p>\n

    [DEFAULT]<\/span><\/p>\n

    bantime\u00a0 = 3600<\/span><\/p>\n

    findtime = 600<\/span><\/p>\n

    maxretry = 3<\/span><\/p>\n

    [sshd]<\/span><\/p>\n

    enabled = true<\/span><\/p>\n

    sudo systemctl restart fail2ban<\/span><\/p>\n

    sudo fail2ban-client status sshd<\/span><\/p>\n

    Set Correct File Permissions<\/span><\/h3>\n

    The right permissions per resource type:<\/span><\/p>\n\n\n\n\n\n\n\n\n
    Resource<\/b><\/th>\nPermission<\/b><\/th>\n<\/tr>\n<\/thead>\n
    Directories<\/span><\/td>\n755<\/span><\/td>\n<\/tr>\n
    PHP and HTML files<\/span><\/td>\n644<\/span><\/td>\n<\/tr>\n
    wp-config.php<\/span><\/td>\n600<\/span><\/td>\n<\/tr>\n
    Upload directories<\/span><\/td>\n755<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    With each site running under its own system user, <\/span>site2user<\/span> cannot read files owned by <\/span>site1user<\/span> regardless of permissions. That separation is the structural protection. Permissions add a second layer.<\/span><\/p>\n

    Disable Nginx Version Disclosure<\/span><\/h3>\n

    By default, Nginx includes its version number in HTTP response headers and error pages. Attackers use this to target known vulnerabilities in specific versions. Turn it off in <\/span>\/etc\/nginx\/nginx.conf<\/span> inside the <\/span>http {}<\/span> block:<\/span><\/p>\n

    server_tokens off;<\/span><\/p>\n

    sudo nginx -t && sudo systemctl reload nginx<\/span><\/p>\n

    Add Redis Object Caching for WordPress Sites<\/span><\/h2>\n

    Redis stores frequently queried database results in memory. For WordPress sites sharing a MariaDB instance, Redis can reduce database query load by 60\u201380% on read-heavy pages. That reduction directly increases how many concurrent visitors each site handles before hitting resource limits.<\/span><\/p>\n

    Install Redis:<\/span><\/p>\n

    sudo apt install redis-server -y<\/span><\/p>\n

    sudo systemctl enable redis-server<\/span><\/p>\n

    sudo systemctl start redis-server<\/span><\/p>\n

    The critical multi-site configuration detail that most guides miss: assign each site its own Redis database index. Redis provides 16 database indices (0\u201315) by default. Without different indices, cache keys from site1.com and site2.com can collide and serve the wrong cached content.<\/span><\/p>\n

    In each site’s <\/span>wp-config.php<\/span>, add the Redis database assignment before the <\/span>\/* That’s all, stop editing! *\/<\/span> comment:<\/span><\/p>\n

    \/\/ site1.com wp-config.php<\/span><\/p>\n

    define( ‘WP_REDIS_DATABASE’, 0 );<\/span><\/p>\n

    \/\/ site2.com wp-config.php<\/span><\/p>\n

    define( ‘WP_REDIS_DATABASE’, 1 );<\/span><\/p>\n

    \/\/ site3.com wp-config.php<\/span><\/p>\n

    define( ‘WP_REDIS_DATABASE’, 2 );<\/span><\/p>\n

    Install the “Redis Object Cache” plugin by Till Kruss in each WordPress site. Activate it and confirm the connection status shows “Connected” in the plugin settings. If you run more than 16 WordPress sites on one server, configure a second Redis instance on a different port.<\/span><\/p>\n

    Set Up Automated Backups<\/span><\/h2>\n

    A backup strategy that is never tested is not a backup strategy. Automated database dumps and file archives cover the data layer. Off-site sync covers the catastrophic failure scenario.<\/span><\/p>\n

    Create the backup script:<\/span><\/p>\n

    sudo nano \/usr\/local\/bin\/backup-sites.sh<\/span><\/p>\n

    #!\/bin\/bash<\/span><\/p>\n

    BACKUP_DIR=”\/var\/backups\/multi-site”<\/span><\/p>\n

    DATE=$(date +%Y-%m-%d)<\/span><\/p>\n

    mkdir -p “$BACKUP_DIR\/$DATE”<\/span><\/p>\n

    # Databases<\/span><\/p>\n

    for DB in site1_db site2_db; do<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0mysqldump -u root “$DB” | gzip > “$BACKUP_DIR\/$DATE\/${DB}.sql.gz”<\/span><\/p>\n

    done<\/span><\/p>\n

    # Site files<\/span><\/p>\n

    for SITE in site1.com site2.com; do<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0tar -czf “$BACKUP_DIR\/$DATE\/${SITE}_files.tar.gz” \\<\/span><\/p>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0-C “\/var\/www\/$SITE” public<\/span><\/p>\n

    done<\/span><\/p>\n

    # Remove backups older than 14 days<\/span><\/p>\n

    find “$BACKUP_DIR” -type d -mtime +14 -exec rm -rf {} + 2>\/dev\/null<\/span><\/p>\n

    echo “Backup complete: $DATE”<\/span><\/p>\n

    Make it executable and schedule it:<\/span><\/p>\n

    sudo chmod +x \/usr\/local\/bin\/backup-sites.sh<\/span><\/p>\n

    echo “0 3 * * * root \/usr\/local\/bin\/backup-sites.sh” | sudo tee \/etc\/cron.d\/multi-site-backup<\/span><\/p>\n

    For off-site storage, sync the backup directory to any S3-compatible object store using <\/span>rclone<\/span>:<\/span><\/p>\n

    sudo apt install rclone -y<\/span><\/p>\n

    # Configure rclone with your storage provider credentials<\/span><\/p>\n

    rclone sync \/var\/backups\/multi-site remote:your-bucket\/vps-backups<\/span><\/p>\n

    Add the <\/span>rclone sync<\/span> command to the backup script after the local archive step. Run a manual restore to a test domain every 90 days. A backup you have never restored is an assumption, not a guarantee.<\/span><\/p>\n

    Monitor Server Health Across All Sites<\/span><\/h2>\n

    Monitoring becomes more important as the number of sites on a single VPS grows. One under-resourced site can create subtle performance degradation across all others before any site crashes outright.<\/span><\/p>\n

    Basic Monitoring with htop and vnstat<\/span><\/h3>\n

    htop<\/b> gives a real-time view of CPU and RAM usage per process. Sort by <\/span>MEM%<\/span> to identify which PHP-FPM pool is consuming the most memory. Press <\/span>F6<\/span> to select the sort column.<\/span><\/p>\n

    sudo apt install htop vnstat -y<\/span><\/p>\n

    vnstat<\/b> tracks bandwidth usage per network interface over time. Run <\/span>vnstat -l<\/span> for a live view or <\/span>vnstat -d<\/span> for daily totals. Useful for identifying which site drives outbound traffic spikes before you get a bandwidth overage notice.<\/span><\/p>\n

    Netdata for Live Server Dashboards<\/span><\/h3>\n

    Netdata installs in one command and provides a browser-based dashboard with CPU, RAM, disk I\/O, and Nginx request rate metrics updated every second:<\/span><\/p>\n

    wget -O \/tmp\/netdata-kickstart.sh https:\/\/get.netdata.cloud\/kickstart.sh<\/span><\/p>\n

    sh \/tmp\/netdata-kickstart.sh<\/span><\/p>\n

    Access the dashboard at <\/span>http:\/\/your-vps-ip:19999<\/span>. Set alerts in <\/span>\/etc\/netdata\/health_alarm_notify.conf<\/span> for RAM usage above 85% and disk usage above 85%. Those thresholds give you time to act before performance degrades or a disk fills completely.<\/span><\/p>\n

    For larger deployments running 10+ sites, Prometheus with Grafana provides longer retention and more granular per-site metrics through Nginx’s stub status module and PHP-FPM’s status endpoint.<\/span><\/p>\n

    WordPress Multisite vs. Separate WordPress Installs<\/span><\/h2>\n

    Both approaches work on a VPS. The right choice depends on the relationship between your sites.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n
    Factor<\/b><\/th>\nWordPress Multisite<\/b><\/th>\nSeparate Installs<\/b><\/th>\n<\/tr>\n<\/thead>\n
    Admin overhead<\/span><\/td>\nOne dashboard<\/span><\/td>\nOne dashboard per site<\/span><\/td>\n<\/tr>\n
    Plugin conflict risk<\/span><\/td>\nHigh (plugins shared across all sites)<\/span><\/td>\nNone (fully isolated)<\/span><\/td>\n<\/tr>\n
    Performance isolation<\/span><\/td>\nNone (shared database tables)<\/span><\/td>\nFull (separate DB, PHP-FPM pool)<\/span><\/td>\n<\/tr>\n
    Traffic spike impact<\/span><\/td>\nAffects all sites in the network<\/span><\/td>\nContained to one site<\/span><\/td>\n<\/tr>\n
    Theme and user management<\/span><\/td>\nCentralized<\/span><\/td>\nIndependent<\/span><\/td>\n<\/tr>\n
    Best for<\/span><\/td>\nRelated brand network, educational networks<\/span><\/td>\nIndependent client sites, agency work<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Use WordPress Multisite<\/b> when all sites belong to the same organization, share users or administrators, and use the same theme with minor customization per sub-site. A university with department sub-sites is the classic use case.<\/span><\/p>\n

    Use separate WordPress installs<\/b> when you host sites for different clients, run projects with different traffic profiles, or need to update, troubleshoot, or migrate one site without touching the others. Separate installs give you complete fault isolation: a broken plugin on site3.com does not affect site1.com or site2.com.<\/span><\/p>\n

    For most agencies and developers running a mix of client sites and personal projects, separate installs with per-site PHP-FPM pools are the more stable and easier-to-maintain setup. The overhead of managing multiple WordPress admin panels is offset by the cleaner isolation.<\/span><\/p>\n

    When to Stop Consolidating and Move to a Dedicated Server<\/span><\/h2>\n

    A multi-site VPS works until one of these conditions becomes consistently true:<\/span><\/p>\n