Single-User Shared Setup

All websites run under www-data with shared PHP pools. A malware infection on Site A reads wp-config.php files across Sites B, C, and D, compromising all databases.

Isolated Linux System Users

Each domain runs under an isolated POSIX user, dedicated PHP-FPM socket, restricted open_basedir, and separate MySQL credentials with zero cross-access.

1. POSIX Filesystem Permissions and System User Isolation

Never place multiple client websites inside a single home directory. Create an independent Linux system user for each domain (e.g., user_sitea, user_siteb) without interactive SSH shell access (/usr/sbin/nologin). Set home directory permissions to 750 and assign the web server group (www-data) read access. Additionally, enforcing umask 027 ensures that newly created files inherit restrictive permissions, preventing neighboring users from inspecting sensitive source code or credentials.

2. Dedicated PHP-FPM Pools and open_basedir Restrictions

Standard PHP installations run all virtual hosts through a single global pool (www.conf). In a hardened environment, define a dedicated pool file for each website (e.g., sitea.conf). Configure each pool to execute as the site’s specific system user over its own Unix domain socket. Inject the php_admin_value[open_basedir] directive to lock the PHP engine strictly to the site’s document root and /tmp, blocking directory traversal attacks.

3. Sandboxed Database Privileges

Never connect multiple applications using the MySQL root administrative user or a shared database account. Provision an isolated database and an exclusive MySQL user for each website. Restrict grants strictly to the target database: GRANT ALL ON sitea_db.* TO 'sitea_user'@'localhost'. Even if an attacker extracts database credentials from one site, adjacent client tables remain completely inaccessible.

4. Independent Server Blocks and Automated SSL Lifecycle

Maintain separate configuration files for each domain within /etc/nginx/sites-available/. Avoid combining multiple virtual hosts into a single monolithic file. Use Certbot with dedicated Let’s Encrypt certificates per domain rather than multi-domain SAN certificates; this prevents SSL renewal errors on one expired domain from breaking certificates across your entire portfolio.

5. Tenant-Specific Rate Limiting and Fail2ban Jails

When hosting dozens of websites, brute-force attacks targeting wp-login.php or XML-RPC endpoints on a single client site can consume substantial CPU cycles. Configure Nginx request rate limiting zones (e.g., limit_req_zone) and deploy tenant-specific Fail2ban filters to automatically drop malicious IP addresses at the Linux kernel firewall level.

6. Granular Access & Error Log Isolation

Never funnel all web server traffic into a single global log file. Direct each virtual host to write logs to its dedicated path (e.g., /var/log/nginx/clientalpha_access.log). This enables streamlined debugging during 500 internal server errors, simplifies Logrotate retention policies, and ensures client data confidentiality.

🏢 Full-Service Digital Agencies

Agencies bundle website maintenance packages with ultra-fast hosting, charging clients \$50–\$150/month while consolidating 30 sites on a single 16GB VPS for massive profit margins.

💼 Freelance Web Developers

Freelancers host client production and staging sites side-by-side with complete credential isolation, preventing staging test scripts from accessing live client databases.

🌐 Multi-Brand Corporate Holdings

Corporations manage regional brand portals and subsidiary sites on a unified server cluster, streamlining OS updates and centralized disaster recovery snapshots.

📈 High-Volume Affiliate Marketers

Affiliate publishers launch dozens of niche landing page funnels, using Nginx FastCGI microcaching to handle millions of ad clicks without buying separate hosting plans.

sudo useradd -m -d /home/clientalpha -s /usr/sbin/nologin clientalpha
sudo mkdir -p /home/clientalpha/public_html
sudo chown -R clientalpha:clientalpha /home/clientalpha
sudo chmod 750 /home/clientalpha && sudo usermod -aG clientalpha www-data

[clientalpha]
user = clientalpha
group = clientalpha
listen = /run/php/php8.3-fpm-clientalpha.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = ondemand
pm.max_children = 15
pm.process_idle_timeout = 10s
pm.max_requests = 500

php_admin_value[open_basedir] = /home/clientalpha/public_html:/tmp

server {
    listen 80;
    server_name clientalpha.com www.clientalpha.com;
    root /home/clientalpha/public_html;
    index index.php index.html;

    access_log /var/log/nginx/clientalpha_access.log;
    error_log  /var/log/nginx/clientalpha_error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm-clientalpha.sock;
    }
}

sudo ln -s /etc/nginx/sites-available/clientalpha.conf /etc/nginx/sites-enabled/
sudo systemctl reload php8.3-fpm && sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d clientalpha.com -d www.clientalpha.com

CREATE DATABASE clientalpha_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'clientalpha_u'@'localhost' IDENTIFIED BY 'StrongRandomP@ss2026!';
GRANT ALL PRIVILEGES ON clientalpha_db.* TO 'clientalpha_u'@'localhost';
FLUSH PRIVILEGES;