Multiple WordPress Sites on One Server: Safe 24.04 & 26.04

Running multiple WordPress sites on one server is safe only when each site gets its own lock: its own Linux user, PHP-FPM pool, database login and nginx server block, so a hacked plugin in one site cannot read the others. This guide builds that on Ubuntu 24.04 LTS or 26.04 LTS (pick yours with the switch below) in nine steps, explains why each piece is there, and ends with three tests that prove the walls hold. Plan on about two hours and basic comfort with the command line.

Every command was run twice in disposable labs, once on Ubuntu 24.04 LTS (nginx 1.24, PHP 8.3, MariaDB 10.11) and once on Ubuntu 26.04 LTS (nginx 1.28, PHP 8.5, MariaDB 11.8), with WordPress 7.1 on both. Every number is a measurement from one of them, and where the two releases differ the page shows only the one you picked. The labs cannot issue real certificates, so TLS is left to the Certbot guide.

What can go wrong: a wrong folder mode can lock a site out of its own files, and a careless PHP reload drops requests that are running. We say where, and how to check.

Before you start: what you need and your safety net

This guide builds on our WordPress on nginx guide, on a server hardened as in Harden Ubuntu Server. You need an admin account with sudo and a domain name for each site. We use example.com and example.net for the sites, siteone and sitetwo for their accounts, and alex for the administrator.

• Snapshot or back up first. A mistake in the PHP-FPM files can stop every site. See the 3-2-1 backup rule.
• Keep a second SSH session open while you reload nginx and PHP-FPM.
• Start with a new site, not a live one. Moving an existing site in is a migration: build the new home first, copy the site across, switch DNS last.

Multiple WordPress sites on one server: why this way and not the other ways

Picture the server as an apartment building. On a default setup every site lives in one flat with one key: one Linux account, one PHP pool, files owned by the same user. A burglar who gets in through one window is already in every other site's rooms. We build a building where each flat has its own lock, and only the walls and plumbing are shared.

We tested the default first. In our lab two WordPress sites shared the stock PHP pool. A harmless probe in the first site, standing in for a hacked plugin, read the second site's wp-config.php, took its database name, user and password, logged in, and counted the rows in its user table. WordPress's own hardening guide warns that on a shared server a compromised neighbor can compromise you.

There was a quieter problem too. With five shared workers and eight slow requests aimed at the first site, a normal page of the second took 5.7 secondsabout 4 seconds instead of under a tenth. Separate pools fix both. Here is where else people look.

Step 1: Plan the names and the layout

Choose one short name per site, three to sixteen lowercase letters or digits, and use it for the Linux account, the PHP pool, the database and its login. Then every command needs only three values, set once. Keep this terminal open for the steps that follow.

DOMAIN=example.com
SITE=siteone
ROOT=/var/www/$DOMAIN

render() {   # fill in a template: @DOMAIN@, @SITE@, @ROOT@ and @PW@ are replaced
  local t; t=$(<"$1")
  t=${t//@DOMAIN@/$DOMAIN}; t=${t//@SITE@/$SITE}; t=${t//@ROOT@/$ROOT}; t=${t//@PW@/$PW}
  printf '%s\n' "$t"
}

The render function fills a template: it swaps four placeholders for your values and prints the result, so each long configuration file appears once and serves every site. Each site gets these pieces.

Step 2: Prepare the server once

These settings apply to every site, so you make them once, before the first site. Each closes a gap we hit in the lab. The block writes four small files, makes two folders, and ends with a test-then-reload pair.

# an unknown host name must never fall through to a real site
sudo tee /etc/nginx/conf.d/00-default.conf >/dev/null <<'EOF'
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}
EOF
sudo rm -f /etc/nginx/sites-enabled/default

# PHP settings that every pool shares
sudo tee /etc/php/8.38.5/fpm/conf.d/90-sites.ini >/dev/null <<'EOF'
opcache.validate_permission = 1
opcache.restrict_api = /usr/share/php/opcache-admin/
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
EOF

# let "reload" finish the requests that are running
sudo tee /etc/php/8.38.5/fpm/pool.d/00-global.conf >/dev/null <<'EOF'
[global]
process_control_timeout = 20s
EOF

# per-site PHP logs: a folder the site users can pass through, and rotation
sudo install -d -m 711 /var/log/php-fpm
sudo tee /etc/logrotate.d/php-fpm-sites >/dev/null <<'EOF'
/var/log/php-fpm/*.log {
    weekly
    rotate 8
    missingok
    notifempty
    compress
    delaycompress
    create
}
EOF

# a home for the per-site templates used below
sudo install -d /usr/local/share/wp-sites

sudo nginx -t && sudo systemctl reload nginx
sudo php-fpm8.38.5 -t && sudo systemctl reload php8.38.5-fpm

Step 3: Give the site its own account and a locked folder

This step creates the Linux account and the folders, and decides who may enter. The site folder is the lock; everything else in this guide is a second layer behind it.

sudo useradd --system --user-group --home-dir "$ROOT" --no-create-home --shell /usr/sbin/nologin "$SITE"
sudo usermod -aG "$SITE" www-data
sudo install -d -o "$SITE" -g "$SITE" -m 710 "$ROOT"
sudo install -d -o "$SITE" -g "$SITE" -m 750 "$ROOT/public"
sudo install -d -o "$SITE" -g "$SITE" -m 700 "$ROOT/tmp" "$ROOT/backups"
sudo systemctl reload nginx      # nginx workers pick up their new group at reload
sudo ls -la "$ROOT"
id www-data

The first command creates a system account and a same-named group, with no login shell and no password. The second adds the web server's account, www-data, to that group so nginx can read static files. The reload matters: workers learn a new group only when they restart (we checked a worker's groups in /proc before and after). You should see:

total 20
drwx--x--- 5 siteone siteone 4096 Oct  8 22:10 .
drwxr-xr-x 1 root    root    4096 Oct  8 22:10 ..
drwx------ 2 siteone siteone 4096 Oct  8 22:10 backups
drwxr-x--- 2 siteone siteone 4096 Oct  8 22:10 public
drwx------ 2 siteone siteone 4096 Oct  8 22:10 tmp
uid=33(www-data) gid=33(www-data) groups=33(www-data),996(siteone)

A neighbor's account is in neither group and has no "other" rights, so it cannot even list the folder. That also protects files anyone could read: WordPress's updater never creates anything stricter than 644 files and 755 folders, so file modes drift open, yet in our test a neighbor could not read a mode-644 upload.

Step 4: Give the site its own database and login

Each site gets one database and one login that sees only that database. If a site's code is hijacked, the attacker holds that login and nothing more. The password is generated, and it reaches MariaDB through a here-document, so it never appears on a command line.

PW=$(openssl rand -hex 24)
sudo mariadb <<SQL
CREATE DATABASE \`$SITE\` CHARACTER SET utf8mb4;
CREATE USER '$SITE'@'localhost' IDENTIFIED BY '$PW';
GRANT ALL PRIVILEGES ON \`$SITE\`.* TO '$SITE'@'localhost';
SQL
sudo mariadb -e "SHOW GRANTS FOR '$SITE'@'localhost'"

You should see a grant for all privileges, but only on this one database, for a login that works only from the server itself. MariaDB stores the password as a hash.

Grants for siteone@localhost
GRANT USAGE ON *.* TO `siteone`@`localhost` IDENTIFIED BY PASSWORD '*<hash>'
GRANT ALL PRIVILEGES ON `siteone`.* TO `siteone`@`localhost`

"All privileges" sounds alarming and is not: WordPress must create and alter its own tables during updates. In our lab the login could not read mysql.user, and writing a file to disk with SELECT ... INTO OUTFILE was refused, because file access is a global privilege and this grant covers one database. Because the account is @localhost, it is useless from any other machine, and WordPress reaches the database through the local socket.

Step 5: Give the site its own PHP-FPM pool

A pool is a group of PHP workers that all run as one account and listen on one socket. This is the step that makes the site account matter: whatever the site's PHP does, it does as siteone, so the folder modes from Step 3 apply to it. We save the pool as a template and render it for each site.

sudo tee /usr/local/share/wp-sites/pool.tpl >/dev/null <<'EOF'
[@SITE@]
user = @SITE@
group = @SITE@
listen = /run/php/php8.38.5-fpm-@SITE@.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 20s
pm.max_requests = 500
request_terminate_timeout = 120s

php_admin_value[open_basedir] = @ROOT@/:/usr/share/php/
php_admin_value[sys_temp_dir] = @ROOT@/tmp
php_admin_value[upload_tmp_dir] = @ROOT@/tmp
php_admin_value[session.save_path] = @ROOT@/tmp
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[error_log] = /var/log/php-fpm/@SITE@.log
php_admin_flag[log_errors] = on
php_admin_flag[display_errors] = off
EOF
sudo install -m 640 -o "$SITE" -g "$SITE" /dev/null "/var/log/php-fpm/$SITE.log"
render /usr/local/share/wp-sites/pool.tpl | sudo tee "/etc/php/8.38.5/fpm/pool.d/$SITE.conf" >/dev/null

php_admin_value rather than php_value makes a setting immutable from PHP code: the PHP manual says admin values cannot be overridden with ini_set(). Now retire the stock pool and reload. FPM refuses to start with no pools, so do this after the first site's pool exists, and skip the first line for later sites.

sudo mv /etc/php/8.38.5/fpm/pool.d/www.conf /etc/php/8.38.5/fpm/pool.d/www.conf.disabled   # first site only
sudo php-fpm8.38.5 -t && sudo systemctl reload php8.38.5-fpm
sleep 2; ls -l /run/php/*.sock

lrwxrwxrwx 1 root     root     30 Oct  8 21:51 /run/php/php-fpm.sock -> /etc/alternatives/php-fpm.sock
srw-rw---- 1 www-data www-data  0 Oct  8 22:10 /run/php/php8.38.5-fpm-siteone.sock

The stock pool's own socket, php8.38.5-fpm.sock, is gone, and the new one belongs to www-data with mode 660. Once the site answers requests, its workers run as siteone, never as www-data.

On-demand or dynamic pools, and the memory arithmetic

PHP's manual defines three process modes: static keeps a fixed number of workers, dynamic keeps a number that moves between limits, and ondemand starts workers when requests arrive. A small business site is idle most of the day, so we use ondemand.

To size pm.max_children you need one number: what a busy worker really holds. Not memory_limit, which is a ceiling for one request, and not the RSS column of ps, which counts the shared PHP libraries and OPcache in every worker. The fair figure is PSS, which splits shared memory among the processes sharing it:

for p in $(pgrep -f 'php-fpm: pool'); do sudo awk '/^Pss:/ {print $2/1024}' /proc/$p/smaps_rollup; done | awk '{t+=$1; n++} END {printf "%d workers, %.0f MB private share\n", n, t}'

The rule: memory you can spare for PHP, divided by a busy worker's private share. An illustrative example: a 4 GB server keeping 1 GB for Ubuntu and nginx and 1 GB for MariaDB has 2 GB for PHP. At 65 MB per WooCommerce-sized worker that is about 30 workers across all sites; at 15 MB, over 130.

So a cap of 8 per site is a starting point, and a fence: a runaway site can hold 8 workers of memory, not all of it. Raise a cap only when the log says server reached max_children setting (8), consider raising it.

The fence protects neighbors too. On the shared pool, one site's slow requests made another wait 5.7 secondsabout 4 seconds. With a pool each and a similar storm (12 slow requests against a cap of 8), the other site's page took 0.440.56 seconds including a cold start, while the busy site's own pages queued for 2.83.0. A pool caps workers, not CPU or disk.

Temp files: what PrivateTmp does and does not do

By default PHP writes temporary files to the shared /tmp. Many assume Ubuntu's PHP-FPM service already has a private one. Check:

sudo systemctl show php8.38.5-fpm -p PrivateTmp

On both Ubuntu 24.04 and 26.04 the answer is PrivateTmp=no. In our lab, with /tmp allowed in open_basedir as many guides suggest, a file one site wrote there was readable by everyone, sat in the server's real /tmp, and was read by another site's PHP.

A drop-in with PrivateTmp=yes moved the file into a folder the rest of the system cannot see, yet the second site's PHP still read it, because both pools belong to one service. systemd's manual says the private directories are not shared with processes outside the service's namespace. So PrivateTmp protects PHP from the machine, not one pool from another. The pool settings do that job: temp files go to the site's 700-mode tmp/, and /tmp is not in open_basedir.

open_basedir and disable_functions: speed bumps, not walls

Keep these two, and do not trust them. open_basedir limits PHP's own file functions. In our lab it stopped file_get_contents() reading a neighbor's config, but not a shell command: on the shared pool, shell_exec('head ...') still read the neighbor's file. And in the OPcache test a cached script ran from another site despite it. The operating system stopped both. The PHP manual says disable_functions can be circumvented and is not a sufficient measure for shared hosting.

They have a price, so we tested it. Stock WordPress and WooCommerce under these exact settings logged in, loaded the dashboard and Site Health, uploaded media with thumbnails, installed a plugin from wordpress.org, and served the shop, cart, checkout and account pages, with no PHP errors. Plugins that shell out, for example to run zip or an image optimizer, need those functions; on PHP 8.3 and 8.5 the symptom is a fatal "Call to undefined function exec()" in the site's PHP log. Prefer a different plugin to a weaker list.

Step 6: Give the site its own nginx server block and logs

The server block ties the pieces together: this domain, this folder, this socket, these logs. It is a template too. The commands save it, create the two log files with safe permissions, render the block, enable it, and reload nginx after a test.

sudo tee /usr/local/share/wp-sites/vhost.tpl >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name @DOMAIN@ www.@DOMAIN@;
    root @ROOT@/public;
    index index.php;
    client_max_body_size 64m;
    access_log /var/log/nginx/@DOMAIN@.access.log;
    error_log  /var/log/nginx/@DOMAIN@.error.log warn;

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

    # no PHP may run from uploads, whatever other rules say
    location ^~ /wp-content/uploads/ {
        location ~ \.php$ { return 403; }
    }

    # hide dotfiles, but keep /.well-known/ (Let's Encrypt, security.txt)
    location ~ /\.(?!well-known/) { deny all; }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.38.5-fpm-@SITE@.sock;
    }
}
EOF
sudo install -m 640 -o root -g adm /dev/null "/var/log/nginx/$DOMAIN.access.log"
sudo install -m 640 -o root -g adm /dev/null "/var/log/nginx/$DOMAIN.error.log"
render /usr/local/share/wp-sites/vhost.tpl | sudo tee "/etc/nginx/sites-available/$DOMAIN.conf" >/dev/null
sudo ln -s "/etc/nginx/sites-available/$DOMAIN.conf" /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Three details come from things we saw go wrong. First, the log files are created in advance as root:adm with mode 640. When nginx created them they came out root:root with mode 644, readable by every account on the server, including another site's PHP. That matters: WordPress password-reset links carry their secret key in the URL, and the default format logs the whole URL. We requested a reset link in the lab and found the full key in the log line.

Second, the logs live outside the site folder, because a file inside a folder the site account owns is one it can delete: rm worked there in our lab and was refused in /var/log/nginx. And client_max_body_size matches PHP's upload limit from Step 5.

Third, the two comment-marked location rules. nginx checks regular-expression locations in the order they appear and stops at the first match, so a deny rule written after the general .php handler can lose. A prefix location with ^~ is different: nginx's documentation says that when the longest matching prefix location has this modifier, regular expressions are not checked. So PHP in uploads is refused whatever the rule order.

The dotfile rule hides .env and .git but exempts /.well-known/, which Let's Encrypt and security.txt need. In the lab /.well-known/security.txt returned 200 while /.env and /.git/config returned 403.

Step 7: Install WordPress as the site account

Everything that writes WordPress files should run as the site account, never as root: a folder made by root inside a site is one PHP cannot read, and the symptom is baffling (in the lab, "opendir(): Failed to open directory: Permission denied"). The block downloads WordPress and checks its published checksum, unpacks it as the site account, writes wp-config.php from a template, shuffles the salts, runs the installer, verifies every core file, and tightens the modes.

cd /tmp             # a folder every account can enter: WP-CLI needs one
curl -fsSLO https://wordpress.org/latest.tar.gz
echo "$(curl -fsSL https://wordpress.org/latest.tar.gz.sha1)  latest.tar.gz" | sha1sum -c -
sudo -u "$SITE" tar -xzf latest.tar.gz --strip-components=1 -C "$ROOT/public"
rm latest.tar.gz

sudo tee /usr/local/share/wp-sites/wp-config.tpl >/dev/null <<'EOF'
<?php
define( 'DB_NAME', '@SITE@' );
define( 'DB_USER', '@SITE@' );
define( 'DB_PASSWORD', '@PW@' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );
$table_prefix = 'wp_';
define( 'DISALLOW_FILE_EDIT', true );
if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/public/' ); }
/* That's all, stop editing! Happy publishing. */
require_once ABSPATH . 'wp-settings.php';
EOF
sudo install -m 600 -o "$SITE" -g "$SITE" /dev/null "$ROOT/wp-config.php"
render /usr/local/share/wp-sites/wp-config.tpl | sudo tee "$ROOT/wp-config.php" >/dev/null
sudo -u "$SITE" -- wp config shuffle-salts --path="$ROOT/public"

sudo -u "$SITE" -- wp core install --path="$ROOT/public" --url="https://$DOMAIN" \
  --title="$DOMAIN" --admin_user=alex --admin_email=[email address] --skip-email
sudo -u "$SITE" -- wp core verify-checksums --path="$ROOT/public"

# tighten what the archive and WordPress created: no access for "other", none for the web server to write
sudo find "$ROOT/public" -type d -exec chmod 750 {} +
sudo find "$ROOT/public" -type f -exec chmod 640 {} +

The installer prints the admin password once. Copy it into a password manager and change it at first login. The output looks like this:

latest.tar.gz: OK
Success: Shuffled the salt keys.
Admin password: <twelve random characters>
Success: WordPress installed successfully.
Success: WordPress installation verifies against checksums.

Why wp-config.php sits above the web root, with mode 600

WordPress's hardening guide says wp-config.php can sit one directory level above the installation, and that only you and the web server should read it. It adds that some people think moving it gains little. We do both for other reasons. Above the web root, a mistake in nginx or PHP handling cannot serve it as text. And since our PHP runs as the site account, the web server never needs to read it, so mode 600 takes it away from nginx entirely; in the lab nginx's account was refused.

The password reaches the file through a here-document and render, a pipe, not a command line. On Linux every account can read every other account's command lines: in the lab one site's account read --dbpass=... from a process another account had started, so a secret typed into wp config create --dbpass= is exposed to a compromised neighbor while it runs. The hidepid=2 mount option for /proc (see proc(5)) hid other accounts' processes in our lab; test it with your own tools before making it permanent.

Because the site account owns the files and PHP runs as that account, WordPress can update itself without asking for FTP details: it compares the owner of a test file with the owner of its own files and then uses direct file access. In the lab, a plugin installed from WordPress.org through the dashboard's own code path worked under the Step 5 settings.

DISALLOW_FILE_EDIT removes the dashboard's code editors but, as the hardening guide notes, does not stop an attacker who can upload files. The WordPress file permissions guide covers a stricter model where PHP cannot change code.

Step 8: Add the next site with one command

When you host multiple WordPress sites on one server you repeat the same few actions with new names, and the three templates hold all the long text. Wrap the actions in a script that stops at the first error, checks the name, and refuses to reuse an existing account or folder. Save it as /usr/local/sbin/add-wp-site and make it executable.

#!/bin/bash
# add-wp-site DOMAIN SITE ADMIN_USER ADMIN_EMAIL
# example: sudo add-wp-site example.com siteone alex [email address]
# Needs step 2 (the once-per-server setup) and the three templates from steps 5 to 7.
set -euo pipefail
DOMAIN=$1 SITE=$2 ADMIN=$3 EMAIL=$4 SCHEME=${SCHEME:-https}   # SCHEME=http while testing without a certificate
ROOT=/var/www/$DOMAIN T=/usr/local/share/wp-sites
[[ $SITE =~ ^[a-z][a-z0-9]{2,15}$ ]] || { echo "SITE: 3-16 lowercase letters or digits" >&2; exit 1; }
if getent passwd "$SITE" >/dev/null || getent group "$SITE" >/dev/null || [ -e "$ROOT" ]; then
  echo "$SITE or $ROOT already exists" >&2; exit 1
fi
PW=$(openssl rand -hex 24)
render() {
  local t; t=$(<"$1")
  t=${t//@DOMAIN@/$DOMAIN}; t=${t//@SITE@/$SITE}; t=${t//@ROOT@/$ROOT}; t=${t//@PW@/$PW}
  printf '%s\n' "$t"
}

# 1. account, folders and log files
useradd --system --user-group --home-dir "$ROOT" --no-create-home --shell /usr/sbin/nologin "$SITE"
usermod -aG "$SITE" www-data
install -d -o "$SITE" -g "$SITE" -m 710 "$ROOT"
install -d -o "$SITE" -g "$SITE" -m 750 "$ROOT/public"
install -d -o "$SITE" -g "$SITE" -m 700 "$ROOT/tmp" "$ROOT/backups"
install -m 640 -o "$SITE" -g "$SITE" /dev/null "/var/log/php-fpm/$SITE.log"
install -m 640 -o root -g adm /dev/null "/var/log/nginx/$DOMAIN.access.log"
install -m 640 -o root -g adm /dev/null "/var/log/nginx/$DOMAIN.error.log"

# 2. database and login
mariadb <<SQL
CREATE DATABASE \`$SITE\` CHARACTER SET utf8mb4;
CREATE USER '$SITE'@'localhost' IDENTIFIED BY '$PW';
GRANT ALL PRIVILEGES ON \`$SITE\`.* TO '$SITE'@'localhost';
SQL

# 3. pool and server block, from the templates
render $T/pool.tpl > "/etc/php/8.38.5/fpm/pool.d/$SITE.conf"
render $T/vhost.tpl > "/etc/nginx/sites-available/$DOMAIN.conf"
ln -s "/etc/nginx/sites-available/$DOMAIN.conf" "/etc/nginx/sites-enabled/$DOMAIN.conf"
[ ! -e /etc/php/8.38.5/fpm/pool.d/www.conf ] || mv /etc/php/8.38.5/fpm/pool.d/www.conf /etc/php/8.38.5/fpm/pool.d/www.conf.disabled
php-fpm8.38.5 -t
nginx -t
systemctl reload php8.38.5-fpm
systemctl reload nginx

# 4. WordPress, as the site user
cd /tmp                                              # WP-CLI must start in a folder the site user can enter
D=$(mktemp -d); chmod 755 "$D"
curl -fsSL -o "$D/wp.tar.gz" https://wordpress.org/latest.tar.gz
echo "$(curl -fsSL https://wordpress.org/latest.tar.gz.sha1)  $D/wp.tar.gz" | sha1sum -c --quiet -
sudo -u "$SITE" tar -xzf "$D/wp.tar.gz" --strip-components=1 -C "$ROOT/public"
rm -rf "$D"
install -m 600 -o "$SITE" -g "$SITE" /dev/null "$ROOT/wp-config.php"
render $T/wp-config.tpl > "$ROOT/wp-config.php"
sudo -u "$SITE" -- wp config shuffle-salts --path="$ROOT/public" --quiet
sudo -u "$SITE" -- wp core install --path="$ROOT/public" --url="$SCHEME://$DOMAIN" \
  --title="$DOMAIN" --admin_user="$ADMIN" --admin_email="$EMAIL" --skip-email
sudo -u "$SITE" -- wp core verify-checksums --path="$ROOT/public"
find "$ROOT/public" -type d -exec chmod 750 {} +
find "$ROOT/public" -type f -exec chmod 640 {} +
echo "Done. Point DNS at $DOMAIN to this server, then run certbot."

Run it with the domain, a new short name and the administrator's name and email: sudo add-wp-site example.net sitetwo alex [email address]. In the lab, the second site came out identical to the first apart from the names (we compared the pool files and server blocks). To test without a certificate, put the variable after sudo: sudo SCHEME=http add-wp-site example.net sitetwo alex [email address]. A variable written before sudo never reaches the script, because sudo starts the command with a clean environment.

The script does not undo anything if it stops half-way; use the removal commands below, then run it again. Each new site follows one checklist:

1. Choose names. A domain, and a short name nobody has used: letters and digits only.
2. Run the script. Save the admin password it prints.
3. Point DNS, then get a certificate with the Certbot guide.
4. Run the proofs. Step 9, against every other site on the server.
5. Add it to your backups: the site folder, a database dump, and the configuration under /etc/nginx, /etc/php/8.38.5/fpm and /usr/local/share/wp-sites. See server backups with restic.

Step 9: Prove the walls hold

A lock you have not tried is a hope. These tests ask the server whether the isolation works, using two sites. Run them again for every new site and after any change to a pool, a server block or a folder mode. Each cleans up after itself.

Test 1: can one site read the other's wp-config.php?

We put a harmless probe in site one. It stands in for a hacked plugin that can run any PHP there, and it runs inside site one's pool, through nginx, like real code.

sudo -u siteone tee /var/www/example.com/public/probe.php >/dev/null <<'EOF'
<?php
$t = '/var/www/example.net';
function say($what, $v) { printf("%-34s%s\n", $what . ':', $v); }
say('run as', posix_getpwuid(posix_geteuid())['name']);
say("read neighbor's wp-config.php", @file_get_contents("$t/wp-config.php") === false ? 'BLOCKED' : 'READABLE');
say("list neighbor's folder", @scandir($t) === false ? 'BLOCKED' : 'LISTED');
say("talk to neighbor's PHP socket", @stream_socket_client('unix:///run/php/php8.38.5-fpm-sitetwo.sock') ? 'CONNECTED' : 'BLOCKED');
say('read own wp-config.php', @file_get_contents('/var/www/example.com/wp-config.php') === false ? 'BLOCKED' : 'readable (needed by WordPress)');
EOF
curl -s -H 'Host: example.com' http://127.0.0.1/probe.php
sudo -u siteone cat /var/www/example.net/wp-config.php
sudo -u siteone rm /var/www/example.com/public/probe.php

run as:                           siteone
read neighbor's wp-config.php:    BLOCKED
list neighbor's folder:           BLOCKED
talk to neighbor's PHP socket:    BLOCKED
read own wp-config.php:           readable (needed by WordPress)
cat: /var/www/example.net/wp-config.php: Permission denied

The last line is the operating system saying no with PHP out of the picture. open_basedir alone would have blocked the first probe, so the plain cat shows the wall is the account and the folder, not a PHP setting. On the shared pool in our lab, a similar probe read the other site's config and went on to log in to its database.

Test 2: can one site's database login open the other's database?

WP-CLI reads the site's own credentials from wp-config.php, so this asks MariaDB exactly what WordPress would be allowed to ask.

cd /tmp
W="sudo -u siteone -- wp --path=/var/www/example.com/public"
$W db query 'SHOW DATABASES;'
$W db query 'SELECT COUNT(*) FROM sitetwo.wp_users;' 2>&1 | grep ERROR
$W db query 'SELECT user FROM mysql.user;' 2>&1 | grep ERROR

Database
information_schema
siteone
ERROR 1142 (42000) at line 1: SELECT command denied to user 'siteone'@'localhost' for table `sitetwo`.`wp_users`
ERROR 1142 (42000) at line 1: SELECT command denied to user 'siteone'@'localhost' for table `mysql`.`user`

The login sees its own database and the built-in information_schema, and nothing else. The two refusals are what you want; grep keeps just the error lines, because WP-CLI also echoes each failed query.

Test 3: does a PHP file dropped into uploads run?

Uploads is the folder visitors and plugins can write to, and the classic place for an attacker to leave a PHP file. We drop a harmless file there, one level deeper too, and add a control file in the web root so the test cannot pass by accident.

sudo -u siteone tee /var/www/example.com/public/wp-content/uploads/probe.php >/dev/null <<'EOF'
<?php echo "EXECUTED\n";
EOF
sudo -u siteone mkdir -p /var/www/example.com/public/wp-content/uploads/2026/10
sudo -u siteone cp /var/www/example.com/public/wp-content/uploads/probe.php /var/www/example.com/public/wp-content/uploads/2026/10/probe.php
sudo -u siteone cp /var/www/example.com/public/wp-content/uploads/probe.php /var/www/example.com/public/control.php
curl -s -o /dev/null -w "uploads/probe.php          -> HTTP %{http_code}\n" -H 'Host: example.com' http://127.0.0.1/wp-content/uploads/probe.php
curl -s -o /dev/null -w "uploads/2026/10/probe.php  -> HTTP %{http_code}\n" -H 'Host: example.com' http://127.0.0.1/wp-content/uploads/2026/10/probe.php
curl -s -H 'Host: example.com' http://127.0.0.1/control.php
sudo -u siteone rm /var/www/example.com/public/control.php /var/www/example.com/public/wp-content/uploads/{probe,2026/10/probe}.php

uploads/probe.php          -> HTTP 403
uploads/2026/10/probe.php  -> HTTP 403
EXECUTED

The two 403s are the lock. If you ever see EXECUTED for the uploads files, a rule in your server block is losing the order race; the nginx security headers guide shows how that happens. One last check takes seconds: ask the other accounts directly.

sudo -u sitetwo cat /var/www/example.com/wp-config.php      # Permission denied
sudo -u sitetwo ls /var/www/example.com                     # Permission denied
sudo -u www-data cat /var/www/example.com/wp-config.php     # Permission denied
sudo -u www-data touch /var/www/example.com/public/x        # Permission denied
sudo -u siteone touch /var/www/example.com/public/ok-test   # works; delete it afterwards

Read that list as a story. A neighbor can neither read nor list the site. The web server can read the public files but not the config, and cannot write. The site's own account can write to its own folder. That is the shape you want.

What isolation does not stop

Separate accounts and pools reduce what a hacked site can do. They do not turn one server into several machines, so multiple WordPress sites on one server still share these things.

• The kernel. A flaw that lets any local account become root defeats every wall here. Patch automatically and reboot for kernel updates; see Harden Ubuntu Server.
• The web server. One nginx serves every site, and its account holds a key to every site folder, by design. Run nginx -t before every reload.
• The database server. Separate logins, one MariaDB. A server flaw, a runaway query or a full disk reaches every site. See the MariaDB guide.
• Redis. A stock install listens on loopback without a password. In our lab one site's account read a key another site's account had written, then ran FLUSHALL and wiped it. Ubuntu 26.04 packages both Redis 8.0 and its fork Valkey 9.0, and both behaved the same way. Database numbers are a filing system, not a lock; read the WordPress Redis object cache guide before sharing one Redis, or skip it for small sites.
• Resources. A pool caps workers, not CPU, disk space or disk activity. One site can still fill the disk.
• What accounts can see. Command lines are visible to every local account, and the folders under /var/www list your domains.
• The break-in itself. A weak admin password or a vulnerable plugin still compromises that site. Isolation limits the damage; keeping every site updated prevents it.

Going further: one PHP-FPM service per site

Everything above shares one PHP-FPM service, hence one OPcache and one system temp folder. For the one or two sites that matter most, give the pool its own master process and systemd unit. We moved the second site into one.

sudo mkdir -p /etc/php/8.38.5/fpm/site-pools
sudo mv /etc/php/8.38.5/fpm/pool.d/sitetwo.conf /etc/php/8.38.5/fpm/site-pools/
sudo tee /etc/php/8.38.5/fpm/site-sitetwo.conf >/dev/null <<'EOF'
[global]
pid = /run/php-fpm-sitetwo/php-fpm.pid
error_log = /var/log/php-fpm/sitetwo-master.log
process_control_timeout = 20s
include = /etc/php/8.38.5/fpm/site-pools/sitetwo.conf
EOF
sudo tee /etc/systemd/system/php8.38.5-fpm@.service >/dev/null <<'EOF'
[Unit]
Description=PHP 8.38.5 FPM for site %i
After=network.target

[Service]
Type=notify
ExecStart=/usr/sbin/php-fpm8.38.5 --nodaemonize --fpm-config /etc/php/8.38.5/fpm/site-%i.conf
ExecReload=/bin/kill -USR2 $MAINPID
RuntimeDirectory=php-fpm-%i
PrivateTmp=yes
ProtectSystem=full
NoNewPrivileges=yes
MemoryMax=512M
TasksMax=200

[Install]
WantedBy=multi-user.target
EOF
sudo php-fpm8.38.5 -t --fpm-config /etc/php/8.38.5/fpm/site-sitetwo.conf
sudo systemctl daemon-reload
sudo systemctl reload php8.38.5-fpm          # lets go of the old socket
sudo systemctl enable --now php8.38.5-fpm@sitetwo

Site two answered normally through its own service while site one stayed on the shared one. A file site two wrote to /tmp was invisible to site one, and with opcache.validate_permission deliberately off, site two's probe could not run site one's cached wp-config.php, because the caches are separate. The price is a master process per site (about 39 MB with one workerabout 12 MB idle and about 74 MB after one WooCommerce page in our test) and one more unit to watch.

We keep it for sites where a break-in would be expensive.

Taking a site down cleanly

Retiring a site is the same steps in reverse: archive, look at the archives, then remove. A dump can fail quietly and leave an almost empty file, so check its size before the database is dropped. The archive holds wp-config.php, so keep it in a root-only folder. The group needs its own removal, because userdel leaves it while the web server's account is still a member.

DOMAIN=example.net; SITE=sitetwo

# archive first, then LOOK at the archives before going on
sudo install -d -m 700 /var/backups/retired-sites
sudo sh -c "mariadb-dump --single-transaction $SITE | gzip > /var/backups/retired-sites/$SITE.sql.gz"
sudo tar -czf /var/backups/retired-sites/$DOMAIN.tar.gz -C /var/www $DOMAIN
sudo ls -l /var/backups/retired-sites/
sudo zcat /var/backups/retired-sites/$SITE.sql.gz | wc -c

# then take the site apart, in this order
sudo rm /etc/nginx/sites-enabled/$DOMAIN.conf /etc/php/8.38.5/fpm/pool.d/$SITE.conf
sudo nginx -t && sudo systemctl reload nginx php8.38.5-fpm
sudo mariadb -e "DROP DATABASE \`$SITE\`; DROP USER '$SITE'@'localhost';"
sudo userdel "$SITE"; sudo groupdel "$SITE"
sudo rm -rf "/var/www/$DOMAIN"

In our lab the dump was about 2120 KB compressed and 113105 KB unpacked. Afterwards, id www-data should no longer list the old group, and the other sites should still answer.

Common mistakes

These are the slips to avoid when you run multiple WordPress sites on one server.

• Adding a site account to the www-data group, or leaving the stock "www" pool running.
• Running commands as root inside a site folder, or starting WP-CLI from a folder the site account cannot enter.
• Typing passwords into commands, where every account can read them.
• Using underscores in database names, or letting nginx create its own log files.
• Reloading PHP-FPM with process_control_timeout left at 0, or skipping opcache.validate_permission and trusting open_basedir instead.
• Changing a pool or a server block and not running the three tests again.

Keep it healthy: a monthly 15-minute routine

Isolation drifts quietly. A tool run as root, a package upgrade or one hurried chmod can open a gap, and nothing breaks to tell you. These four checks take a minute and print nothing alarming when all is well.

ps -eo user:12,args | grep 'php-fpm: pool' | grep -v grep
ls /etc/php/8.38.5/fpm/pool.d/
php-fpm8.38.5 -i | grep -E '^opcache.(validate_permission|restrict_api)'
for d in /var/www/*/; do u=$(stat -c %U "$d"); sudo find "$d" -xdev \( ! -user "$u" -o -perm /022 \) ! -type l -printf '%u %m %p\n' | head -5; done

The first line shows each pool's account; none may be www-data. The second shows the stock pool has not come back after a PHP package update (a reinstall did not bring it back in our test, but check). The third shows the shared OPcache settings active. The fourth lists files not owned by their site's account or writable by a group or everyone; a healthy server prints nothing, and in the lab it flagged a root-owned file and a group-writable file at once.

• Update WordPress core, plugins and themes on every site, and the operating system. Reboot when asked.
• Run the three tests from Step 9 after any change to a pool, a server block or a folder mode.
• Look for pool-cap warnings: sudo grep max_children /var/log/php8.38.5-fpm.log.
• Restore one site from backup onto a test machine and check that nginx can read it. Ownership and group membership are part of the restore.

Getting help

Doing this once is a good weekend project. Keeping multiple WordPress sites on one server right, with updates, backups and a way back when something breaks, is where help pays for itself. MEI's Infrastructure & Private Cloud service starts at $2,500, scoped by systems and scale, and covers provisioning and Linux administration, performance tuning, migrations, monitoring and updates, and documentation. For one site that needs speed or security work, WordPress Engineering & Plugin Development starts at $1,200. No one can promise perfect security; we focus on the highest-impact, most likely risks.

Still choosing between a shared host and a server of your own? Read VPS vs shared hosting and the Linux server hardening checklist, or begin with a Business Tech Rescue Audit, which starts at $497.