Your WordPress sites on a dedicated server of their own

Is a server of your own worth it for WordPress?

It is when your sites have outgrown sharing: a shop whose checkout slows at busy hours, a membership site with heavy plugins, or an agency hosting its clients' sites. On a dedicated hosting server the processor, memory and storage are assigned to you alone, so nobody else's traffic decides how fast your pages load.

It is not worth it for a small site you would rather not look after. Our web hosting runs your website for you, with no server to patch.

What WordPress needs, in plain terms

The official list is short. Here is each item, and what it means when you choose an operating system:

• PHP 8.3 or newer, recommended on wordpress.org. The Hosting Handbook goes further and suggests PHP 8.4 or later for live sites. WordPress 7.0 and 7.1 still support PHP 7.4, but that version is out of support itself.
• MariaDB 10.11+ or MySQL 8.0+ for the database. Note that the handbook gives MySQL 8.0 an end-of-life date of April 2026, so a new server should start on MySQL 8.4 or a current MariaDB.
• HTTPS, so logins and visitors' data travel encrypted.
• A web server: nginx, or Apache with its mod_rewrite module.
• PHP memory, from the handbook: 128M is the floor, 256M a sensible default, and 512M or more for WooCommerce, page builders or multilingual plugins.

Ubuntu 26.04 covers all of it from its own packages, with PHP 8.5 and MariaDB 11.8. What wordpress.org does not give you is a CPU, RAM or disk figure. That is decided by your plugins, your traffic and how much of it a cache can answer, so think in PHP workers: each one can use up to its memory limit, and the database wants memory of its own beside them.

The server that fits

Our hosting servers are enterprise machines with SSD storage, HPE on most lines and Dell or Supermicro on some, and the CPU, RAM and storage on each one belong to your account only. You get root, a port that is not shared with any other customer at the access switch, and nothing counts the traffic on your port, so a sale or a viral post does not turn into a traffic charge. There is no contract, and a server that is already racked is yours about 30 minutes once the order is approved.

For a shop or anything you cannot afford to have down, look at our enterprise dedicated servers: machines you can order with hardware RAID, each with its own iLO, iDRAC or BMC management console, reachable from your dashboard after you create a login for it. One wrong firewall rule then can't shut you out of your own server. And if your plan is to sell WordPress hosting to clients, Nexo turns the server into that business, with one-click WordPress and a PHP version chosen per website.

Up and running before anyone else can claim it

The browser installer has one weakness: whoever opens it first sets up the site and its admin account. So you will finish the install from the command line with WP-CLI, before the domain points at the server, and that page never faces the internet. Start as your normal sudo user with the firewall, set to cover IPv6 before any rule is added, then the software:

sudo apt update && sudo apt -y full-upgrade
sudo sed -i 's/^IPV6=.*/IPV6=yes/' /etc/default/ufw
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw --force enable
sudo apt -y install nginx mariadb-server php-fpm php-mysql php-curl php-gd \
  php-imagick php-intl php-mbstring php-xml php-zip certbot python3-certbot-nginx
sudo curl -o /usr/local/bin/wp \
  https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
sudo chmod 755 /usr/local/bin/wp

Next, type sudo -i for a root shell. This part gives the site a Linux user of its own, makes its database, and installs WordPress. Notice that you never type the database password: it is generated into a file only root can read, handed to MariaDB and to WP-CLI on standard input, and after that it exists only inside wp-config.php.

adduser --system --group --no-create-home --home /srv/mysite mysite
install -d -o mysite -g www-data -m 750 /srv/mysite /srv/mysite/www
install -d -o mysite -g mysite -m 700 /srv/mysite/backups
(umask 077; openssl rand -hex 24 > /root/mysite-db.pass)
mariadb <<SQL
CREATE DATABASE wp_mysite CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_mysite'@'localhost' IDENTIFIED BY '$(cat /root/mysite-db.pass)';
GRANT ALL PRIVILEGES ON wp_mysite.* TO 'wp_mysite'@'localhost';
SQL
cd /srv/mysite/www
sudo -u mysite wp core download
sudo -u mysite wp config create --dbname=wp_mysite --dbuser=wp_mysite \
  --dbcharset=utf8mb4 --prompt=dbpass < /root/mysite-db.pass
rm /root/mysite-db.pass
sudo -u mysite wp config set DISALLOW_FILE_EDIT true --raw
sudo -u mysite wp config set FORCE_SSL_ADMIN true --raw
chmod 400 wp-config.php
sudo -u mysite wp core install --url=https://yourdomain.com --title="My Site" \
  --admin_user=choose-a-name --admin_email=you@yourdomain.com --skip-email

Because you left out --admin_password, WP-CLI makes a strong one and shows it once. Save it in your password manager now. The config file is now readable by the site's user and nobody else. The last part runs PHP for this site under its own user and tells nginx where the site lives, following the WordPress nginx article:

cat > /etc/php/8.5/fpm/pool.d/mysite.conf <<'EOF'
[mysite]
user = mysite
group = mysite
listen = /run/php/mysite.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 8
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
EOF
cat > /etc/nginx/sites-available/mysite <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    root /srv/mysite/www;
    index index.php;
    client_max_body_size 64m;
    location / { try_files $uri $uri/ /index.php?$args; }
    location ~ /\.(?!well-known) { deny all; }
    location ~* /(?:uploads|files)/.*\.php$ { deny all; }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/mysite.sock;
    }
}
EOF
ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/
nginx -t && systemctl restart php8.5-fpm && systemctl reload nginx

1. Point your domain at the server. Most of our lines include a free IPv6 address; if yours has one, add an AAAA record next to the A record.
2. Get the certificate: certbot --nginx -d yourdomain.com -d www.yourdomain.com. The dashboard needs it, since FORCE_SSL_ADMIN makes logins HTTPS only.
3. Log in at https://yourdomain.com/wp-admin/ and open Tools → Site Health to see what WordPress thinks of its new home.

Keeping it fast and locked down

Speed first. WordPress's own caching article covers three separate kinds of cache, and nothing stops you using all three: OPcache, so PHP is not compiled on every request; a page-cache plugin such as WP Super Cache, W3 Total Cache or Cache Enabler, which turns pages into static files; and an object cache that persists between requests, kept in Redis or Memcached. Our guide to running Redis yourself covers the last one.

Then safety. You have already switched off the built-in theme and plugin editor, kept PHP from running inside uploads, and left the database with no open port. The hardening guide adds a few habits: delete plugins you are not using, never name the admin account admin, and keep an eye on your logs for password-guessing.

WordPress's hardening guide notes that updates are carried out by whoever owns the files. On this setup the site's PHP pool runs under that same owner, so our reading is that WordPress is able to apply updates by itself; minor core releases are applied automatically by default. For everything else, back up, then run sudo -u mysite wp core update followed by the same command with plugin update --all and theme update --all.

Backups you run yourself

You manage the server; we keep the hardware and the network running. So set up your own backups on day one. WordPress keeps your posts in the database and your themes, plugins and media in files, and you need both to bring a site back. Its backup guide suggests daily copies for a busy site, a fresh one before every upgrade, and three to five recent sets kept in different places. Open the site user's schedule with crontab -u mysite -e as root and add two lines:

• 15 2 * * * /usr/local/bin/wp db export - --path=/srv/mysite/www --quiet 2>> /srv/mysite/backups/errors.log | gzip > /srv/mysite/backups/db-$(date +\%F).sql.gz
• 35 2 * * * tar -czf /srv/mysite/backups/site-$(date +\%F).tar.gz -C /srv/mysite www 2>> /srv/mysite/backups/errors.log

WP-CLI reads the database login from wp-config.php, so the schedule never holds a password. Copy the backups folder to somewhere off the server each night, clear out old ones, and every so often restore one to a test site to check it really works.

Room for every client site

Hosting many sites on one machine comes down to a choice between two approaches.

1. One install per site. Repeat the user, database, PHP pool and nginx steps for each new site. If one site is broken into, the intruder finds only that site's files and database, which is the containment the WordPress hardening guide suggests. You update each site separately.
2. One Multisite network. All sites share a single WordPress, with their own tables and upload folders. Switch on WP_ALLOW_MULTISITE in the config file (chmod 600 wp-config.php, then sudo -u mysite wp config set WP_ALLOW_MULTISITE true --raw), then follow Tools → Network Setup and swap in the matching server block from the nginx article. Copy the lines that screen shows into wp-config.php and lock the file down once more with chmod 400 wp-config.php. Choose subdomains or subfolders carefully: the docs warn a later change of mind might not be easy, and letting people create subdomain sites themselves needs wildcard DNS. One faulty plugin can affect the whole network.

Moving sites in from somewhere else? Our migration guide explains how the switch-over goes and who does what.

Questions people ask

How much server does a WordPress site need?

wordpress.org publishes software requirements, not hardware ones: PHP 8.3 or newer, MariaDB 10.11+ or MySQL 8.0+, and HTTPS. Memory is the part to plan, because each PHP worker can use up to its limit, 256M by the handbook's default, with the database alongside. Your plugins and visitor numbers decide the rest.

Will my site be safe while I am setting it up?

Yes, if you install with WP-CLI before your domain points at the server, as shown above. The browser installer is the risky part, because the first visitor to reach it can create the admin account. With the install finished from the command line, that screen is never on offer.

Can clients' sites share one server safely?

They can if each gets its own Linux user, PHP pool and database user, so one hacked site cannot read another's files. Multisite is simpler to update but shares one set of plugins, so a bad one reaches every site. If you sell hosting, Nexo handles the separation for you.

Do I have to use a control panel?

No. You have root, so nginx, PHP and MariaDB can be set up by hand as on this page. cPanel and Plesk are available when you order if you would rather click than type, and Nexo suits selling hosting under your own name.

Who helps if something goes wrong?

Our support team is available around the clock by phone or live chat, and live chat is usually answered in under a minute. WordPress itself, with its plugins and backups, stays in your hands.