Install WordPress Nginx Ubuntu 24.04 & 26.04: 9 Secure Steps

If you searched for how to "install WordPress Nginx Ubuntu", you probably want a site that works today and is still safe to update next year. This guide builds exactly that on Ubuntu 24.04 LTS or 26.04 LTS, so pick yours with the switch below: one WordPress site with Nginx, PHP-FPM and MariaDB, running as its own Linux user and installed with WP-CLI, so no password ever sits on a command line. Plan on about an hour and some comfort with a terminal.

We ran every command below twice in disposable test machines before writing it down: once on Ubuntu 24.04 LTS (Nginx 1.24, PHP 8.3.6, MariaDB 10.11) and once on Ubuntu 26.04 LTS (Nginx 1.28.3, PHP 8.5.4, MariaDB 11.8.6). Both used WP-CLI 2.12.0 and WordPress 7.1.3, in October 2026. We also reproduced the common failures, such as a 404 on every page or a 502, so you can recognize them.

Where the two releases differ, the page shows only the one you picked, and where common advice turned out to be wrong, we say so.

Before you start: what you need and a way back

You need a fresh Ubuntu Server 24.04 LTS or 26.04 LTS machine and an admin account that can use sudo and logs in with an SSH key; our 12-step server hardening guide sets that up. You also need a domain name, but DNS only matters once real visitors and HTTPS arrive. Every test below uses curl against the server itself, so you can build first and point DNS later.

• Take a snapshot first. A fresh server is cheap to rebuild and a production one is not. The 3-2-1 backup rule explains how many copies to keep.
• Keep a second SSH session open while you change web server settings, so a mistake never locks you out.
• Test before you reload. Run sudo nginx -t and sudo php-fpm8.38.5 -t first. If a test fails, the old configuration keeps serving while you fix the new one.
• Swap the placeholders. We use example.com for your domain, siteuser for the site's Linux account and PHP pool, sitedb and sitedb_user for the database and its account, and alex for you.

Install WordPress Nginx Ubuntu: why this way and not the other ways

There is more than one sensible way to run WordPress. This table compares them in plain English, so you can see why the guide takes this path and when another one is the better choice.

WordPress.org's requirements page recommends Apache or Nginx as the most robust and featureful servers for WordPress. It also notes that hosting is more secure when PHP applications run under your account's username instead of the server's default shared username. This guide follows both points.

Read the diagram from top to bottom. A visitor's request reaches Nginx, which runs as the www-data account and only reads files. Anything ending in .php goes through a private socket to a PHP-FPM pool running as siteuser, the account that owns the site's files. WordPress then asks MariaDB for content through an account that can use one database and nothing else. Each hop uses the least powerful account that can do its job.

Step 1: Install Nginx, PHP-FPM and MariaDB

Everything comes from Ubuntu's own repositories, so security updates arrive through the same apt you already use. Besides the three servers, the command installs the PHP extensions that WordPress's hosting handbook lists as required or highly recommended, plus php8.38.5-cli, which WP-CLI needs.

sudo apt update
sudo apt install -y nginx mariadb-server php8.38.5-fpm php8.38.5-cli php8.38.5-mysql \
  php8.38.5-curl php8.38.5-gd php8.38.5-imagick php8.38.5-intl php8.38.5-mbstring php8.38.5-xml php8.38.5-zip \
  unzip curl

Each service starts by itself. Confirm that, check the versions, and let a small loop report any extension that is missing. No "missing" line means the set is complete.

systemctl is-active nginx php8.38.5-fpm mariadb
nginx -v; php -v | head -1; mariadb --version
for m in mysqli curl dom exif fileinfo gd hash imagick intl mbstring openssl xml zip; do
  php -m | grep -qix "$m" || echo "missing: $m"
done

Compare what you got with what WordPress.org asks for on its requirements page.

Step 2: Create a dedicated Linux user for the site

Instead of running WordPress as the shared www-data account, give the site its own account. Think of it as giving each tenant in a building their own key: a lost key opens one apartment, not the whole floor. The account has no password and no login shell, so nobody can sign in as it, but you can still run commands as it with sudo -u.

sudo useradd --system --user-group --no-create-home \
  --home-dir /var/www/example.com --shell /usr/sbin/nologin siteuser
sudo install -d -o siteuser -g siteuser -m 711 /var/www/example.com
sudo install -d -o siteuser -g siteuser -m 755 /var/www/example.com/public
ls -ld /var/www/example.com /var/www/example.com/public

The first command makes a system account with a group of the same name. --no-create-home is deliberate, because we create the folders ourselves with exact modes. Mode 711 on the site folder lets Nginx walk through to public/ without being able to list what else is there. Mode 755 on public/ lets Nginx read the files WordPress will put there.

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

PHP-FPM keeps groups of PHP worker processes ready to run WordPress. Each group is a pool, and each pool has its own account, its own socket and its own limits. Ubuntu ships one pool called www. We add a pool for the site and retire the default one. Write the pool file first; the table below the commands explains every value.

sudo tee /etc/php/8.38.5/fpm/pool.d/siteuser.conf > /dev/null <<'EOF'
[siteuser]
user = siteuser
group = siteuser

; a private socket for this site; only Nginx's account may connect
listen = /run/php/php8.38.5-fpm-siteuser.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; start workers when requests arrive, stop them when idle
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 20s
pm.max_requests = 500

; log PHP errors, never show them to visitors
catch_workers_output = yes
php_admin_flag[log_errors] = on
php_admin_flag[display_errors] = off

; WordPress limits (Nginx's client_max_body_size and fastcgi_read_timeout must agree)
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[max_execution_time] = 120
php_admin_value[max_input_vars] = 3000
EOF
sudo php-fpm8.38.5 -t
sudo mv /etc/php/8.38.5/fpm/pool.d/www.conf /root/www.conf.disabled
sudo systemctl restart php8.38.5-fpm
ls -l /run/php/

Look for a socket named php8.38.5-fpm-siteuser.sock, owned by www-data with permissions srw-rw----. Ignore the php-fpm.sock link, which points at the retired default pool, and the .pid file. There are no worker processes yet. With ondemand they appear when the first request arrives and exit after 20 idle seconds.

How big should pm.max_children be? Measure rather than guess. ps -u siteuser -o rss,args | grep 'php-fpm: pool' lists each worker's resident memory in kilobytes. In our lab a plain WordPress front page used about 4650 MB per worker, but most of that is shared: ten busy workers added up to about 110116 MB of real memory. Plugins, page builders and shop software raise this, so check your own site under load.

The memory_limit is a ceiling per request, so the theoretical worst case is workers times limit, here 10 times 256 MB, or 2.5 GB. When /var/log/php8.38.5-fpm.log contains the warning server reached max_children setting (10), consider raising it, requests are queuing for a free worker. Raise the cap only if you have the memory.

Step 4: Install WP-CLI and check that it is genuine

WP-CLI is the command-line tool for WordPress. It can download, configure, install, update and repair a site without a browser. It is not in Ubuntu's repositories, so you install the single-file .phar build from the project. Download it, then check its signature before it gets a place on your system path. Run these as your admin user, not as root.

cd ~
curl -fLO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
curl -fLO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar.asc
curl -fL https://raw.githubusercontent.com/wp-cli/builds/gh-pages/wp-cli.pgp | gpg --import
gpg --fingerprint [email address]
gpg --verify wp-cli.phar.asc wp-cli.phar

Compare the fingerprint with the one printed on the project's "Verifying downloads" page; they must match exactly. gpg --verify should report Good signature from "WP-CLI Releases <[email address]>". A warning that the key is not certified is normal, because you have not personally signed it. Only then install the file.

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
rm wp-cli.phar.asc
wp --info | head -4

Now define a small helper for the rest of this guide. It runs WP-CLI as siteuser, never as root, pointed at the site. It exists only in this terminal window; add the line to ~/.bashrc if you want it back next time.

wps() { ( cd /tmp && sudo -u siteuser -- wp --path=/var/www/example.com/public "$@" ); }

Step 5: Download WordPress and check it

Download the official archive, compare its SHA-1 checksum with the one WordPress.org publishes next to it, and unpack it as the site user. Then ask WP-CLI to compare every core file with WordPress.org's published checksums. This takes under a minute and proves you have the real thing, intact.

cd /tmp
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 siteuser tar -xzf /tmp/latest.tar.gz --strip-components=1 -C /var/www/example.com/public
rm /tmp/latest.tar.gz
wps core verify-checksums

You want latest.tar.gz: OK and Success: WordPress installation verifies against checksums. The archive holds a top-level wordpress folder, which --strip-components=1 removes so the files land directly in public/.

Step 6: Create the database and a least-privilege database user

WordPress keeps its content in a database. Create one database for this site and one database account that can use only that database. On Ubuntu the MariaDB administrator account is tied to your operating-system identity through a local socket, so sudo mariadb needs no database password. Generate the new account's password with openssl, and keep it in a shell variable, not in a command.

DB_PASS=$(openssl rand -base64 24 | tr -d '/+=')
sudo mariadb <<SQL
CREATE DATABASE sitedb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'sitedb_user'@'localhost' IDENTIFIED BY '$DB_PASS';
GRANT ALL PRIVILEGES ON sitedb.* TO 'sitedb_user'@'localhost';
SQL
sudo mariadb -e "SHOW GRANTS FOR 'sitedb_user'@'localhost'" | grep -v 'ON \*\.\*'

The tr step removes characters that need quoting in SQL and PHP, leaving roughly 30 letters and digits. utf8mb4 is MariaDB's name for full UTF-8, including emoji; plain utf8 is a three-byte subset. The account name ends in @'localhost', so it can only connect from the server itself. The grant covers everything inside sitedb and nothing outside it. The last command hides the first grant line, which contains a hash of the password.

Step 7: Configure and install WordPress with WP-CLI

Now WP-CLI writes wp-config.php, checks that the database login works, and installs WordPress. The password reaches WP-CLI through standard input, so it appears in no argument list. WP-CLI creates fresh secret keys and salts for you, and we pass --dbcharset=utf8mb4 because its default is the older utf8.

printf '%s\n' "$DB_PASS" | wps config create \
  --dbname=sitedb --dbuser=sitedb_user --dbhost=localhost --dbcharset=utf8mb4 \
  --prompt=dbpass --quiet
unset DB_PASS
wps db check
wps core install --url=http://example.com --title="Example Co" \
  --admin_user=alex --admin_email=[email address] --skip-email

The install prints Admin password: once. Copy it into a password manager now, then run clear. Name the administrator something like alex, not admin, the best-known default. Then tidy the defaults: pretty permalinks, no code editor in the dashboard, and no sample content.

wps rewrite structure '/%postname%/'
wps config set DISALLOW_FILE_EDIT true --raw
wps plugin delete hello
wps post delete 1 2 --force

Finally, prove the database account is boxed in. It should see only its own database, and every attempt to reach beyond it should be refused.

wps db query "SHOW DATABASES;"
wps db query "SELECT user FROM mysql.user;"
wps db query "CREATE DATABASE other_db;"

The first command lists information_schema and sitedb. The other two fail with ERROR 1142 ... SELECT command denied and ERROR 1044 ... Access denied. That is the point.

Step 8: Write the Nginx server block

Nginx reads one file per site from /etc/nginx/sites-available/ and serves the ones linked from sites-enabled/. First retire the packaged welcome site and add a catch-all for names you do not host. Then add the site itself.

sudo rm /etc/nginx/sites-enabled/default
sudo tee /etc/nginx/conf.d/00-default-server.conf > /dev/null <<'EOF'
# Answers requests for any hostname we do not host (bare IP address, stray DNS names)
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;    # nginx-specific: close the connection without sending a response
}
EOF
sudo tee /etc/nginx/sites-available/example.com.conf > /dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php;

    client_max_body_size 64M;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    # WordPress front controller: real files first, everything else goes to index.php
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Never execute PHP from the uploads folder. This must stay ABOVE the generic PHP location below
    location ~* ^/wp-content/uploads/.*\.php$ {
        deny all;
    }

    # Hide dotfiles (.git, .env, .htaccess) but keep /.well-known/ reachable for Let's Encrypt
    location ~ /\.(?!well-known) {
        deny all;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.38.5-fpm-siteuser.sock;
        fastcgi_read_timeout 120s;
    }

    # Let browsers cache static files for 30 days
    location ~* \.(?:css|js|mjs|jpe?g|png|gif|webp|avif|svg|woff2?)$ {
        expires 30d;
        access_log off;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf
sudo nginx -t && sudo systemctl reload nginx

The test should print syntax is ok and test is successful. Here is what each part of the site file does and why it is there.

Step 9: Lock down ownership and permissions

Everything WP-CLI and tar created belongs to siteuser, but the exact modes depend on the umask of whoever ran them, so set them explicitly. Directories get 755: the owner can read, write and enter, everyone else can read and enter. Files get 644: the owner can read and write, everyone else can only read. The configuration file gets 640, so only the site account can read it.

sudo find /var/www/example.com/public -type d -exec chmod 755 {} +
sudo find /var/www/example.com/public -type f -exec chmod 644 {} +
sudo chmod 640 /var/www/example.com/public/wp-config.php
sudo find /var/www/example.com \( -type d -o -type f \) -perm -0002
sudo find /var/www/example.com ! -user siteuser
sudo -u www-data cat /var/www/example.com/public/wp-config.php

The two find commands should print nothing: no world-writable entries and nothing owned by another account. The last command should fail with Permission denied, proving Nginx's account cannot read your database password. The 755 and 644 pattern is the one WordPress's own hardening guide gives. That guide suggests 400 or 440 for wp-config.php; we use 640 so WP-CLI can still edit it, and the file's group is the site's private group.

The payoff is that WordPress can update itself without being world-writable. Before writing files, WordPress creates a test file and compares its owner with the owner of its own core files. If they match it writes directly; otherwise it asks for FTP details. We checked what WordPress decides inside PHP-FPM in four situations.

Check your work with curl

Test from the server itself with --resolve, which pretends DNS already points at the machine. Each line prints a status code and what it means. A 000 means the connection was closed with no reply.

R="--resolve example.com:80:127.0.0.1"
curl -s -o /dev/null -w '%{http_code}  home page\n'                  $R http://example.com/
curl -s -o /dev/null -w '%{http_code}  login page\n'                 $R http://example.com/wp-login.php
curl -s -o /dev/null -w '%{http_code}  dotfile (want 403)\n'         $R http://example.com/.env
curl -s -o /dev/null -w '%{http_code}  unknown page (want 404)\n'    $R http://example.com/no-such-page/
curl -s -o /dev/null -w '%{http_code}  bare IP address (want 000)\n' http://127.0.0.1/
curl -sI $R http://example.com/wp-includes/js/jquery/jquery.min.js | grep -i -E '^(cache-control|expires)'

Now prove the uploads rule, the most important negative test. Create a harmless PHP file where it must not run, request it, and delete it. If you see 200 and the words PHP RAN, your rules are in the wrong order.

sudo -u siteuser mkdir -p /var/www/example.com/public/wp-content/uploads
echo '<?php echo "PHP RAN";' | sudo -u siteuser tee /var/www/example.com/public/wp-content/uploads/probe.php > /dev/null
curl -s -o /dev/null -w '%{http_code}  PHP in uploads (want 403)\n' $R http://example.com/wp-content/uploads/probe.php
sudo rm /var/www/example.com/public/wp-content/uploads/probe.php

Finally, check who runs what and what is listening. Nginx workers should run as www-data and the pool as siteuser (it appears after the first request). Port 80 should be open on all addresses, and MariaDB's port 3306 only on 127.0.0.1.

ps -eo user:12,args | grep -E 'nginx: worker|php-fpm: pool' | grep -v grep
sudo ss -tlnp | grep -E ':(80|3306) '
wps core verify-checksums

To see the site from another computer, open the web ports in the firewall with sudo ufw allow "Nginx Full", as our UFW guide explains, and point DNS (or a line in your computer's hosts file) at the server. Then log in at /wp-login.php and open Tools, then Site Health. Expect notices about HTTPS, page caching and unused default plugins and themes. The PHP version, extensions and database checks should be green.

What to do next

That completes the install, but a public site needs a few more things before launch. Do them in this order.

• HTTPS. Follow Certbot with Nginx on Ubuntu first. If you switch WordPress to https before it works, /wp-admin/ redirects to an address that does not answer, and you lock yourself out of the dashboard. Once HTTPS works, run wps option update home 'https://example.com', the same for siteurl, and wps search-replace 'http://example.com' 'https://example.com' --all-tables.
• Speed. Add the Nginx FastCGI cache and, if you need it, the Redis object cache. See also why is my WordPress site so slow.
• Scheduled tasks. WordPress runs its jobs when someone visits. Systemd timers versus cron shows how to run them on a clock instead.
• Backups. Set up server backups with restic and test a restore.
• Hardening. Apply the server hardening steps, add security headers and consider fail2ban.
• Email. A new server cannot send reliable mail by itself. Start with why a WordPress form is not sending email.

Common mistakes

• Testing by IP address. With the catch-all in place the IP shows nothing, and without it you see the Nginx welcome page. Test with the real name or --resolve.
• A 404 on every page and 403 on images. The site folder is mode 750 and Nginx cannot enter. Use 711.
• 502 Bad Gateway. fastcgi_pass points at a socket that does not exist, often the default one you retired. Read the Nginx error log for connect() to unix:... failed.
• 413 when uploading. client_max_body_size is still the 1 MB default.
• The FTP prompt on updates. The files and the PHP account do not match. Fix ownership, not modes.
• A deny rule below the PHP location. It never fires. Test it with the probe file.
• Passwords in commands. They reach the process list, shell history and the sudo log.
• Skipping the checksum check. It catches a damaged unpack and later tampering.
• Trusting .htaccess promises. A plugin that says it updated .htaccess did nothing on Nginx. WordPress's own Nginx documentation says it cannot change the server configuration.

Keep it healthy: a monthly routine

• Apply Ubuntu updates and reboot when asked: sudo apt update && sudo apt full-upgrade. Our WordPress maintenance checklist covers the application side.
• Check for updates with wps core check-update, wps plugin list --update=available and wps theme list --update=available.
• Verify integrity with wps core verify-checksums and wps plugin verify-checksums --all.
• Look for ownership drift and loose modes with the two find commands from Step 9.
• Read the last lines of /var/log/nginx/example.com.error.log and /var/log/php8.38.5-fpm.log. Both rotate on their own: Ubuntu's rules cover every .log file in /var/log/nginx/; our logrotate nginx guide covers per-site log folders and the permission trap that breaks them.
• Update WP-CLI itself with sudo wp cli update. Delete plugins and themes you do not use, but keep one default theme as a fallback.
• Restore a backup to a test machine and load the site.

Getting help

Building one server by hand is a good afternoon; keeping several consistent is where mistakes creep in. MEI's WordPress Engineering & Plugin Development service starts at $1,200, with fixed scope or hourly work, and covers performance, security hardening, migrations and custom plugins. If you would rather not run the server yourself, Managed Website & IT Care starts at $149 per month, with scope-based tiers for updates, backups, monitoring and help. We say plainly that no one can promise perfect security; we focus on the highest-impact, most likely risks.

For a wider look at your hosting, backups and exposure, start with a Business Tech Rescue Audit, which starts at $497.