How to Set Up WordPress Staging on a Hostperl VPS

Start with a staging copy, not a risky edit

WordPress staging on a Hostperl VPS gives you a separate copy of your site where you can test theme changes, plugin updates, checkout fixes, and PHP changes before they reach production. That matters when your site brings in leads or sales, because one broken plugin can stop forms, payments, or admin access.

If you are planning a larger migration or a fresh launch, a Hostperl VPS gives you the control you need for staging, backups, and deployment workflows without pushing those changes onto your live site.

This tutorial takes you from the first SSH login on a fresh server to a working WordPress staging setup, basic Nginx protection, database cloning, and final verification. It assumes you want a real staging site for customer-facing work, not a throwaway demo.

Connect to the VPS and identify the operating system

On your local computer, open your terminal and connect as root first.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation example. Replace it with the public IP assigned to your Hostperl server. If you use a custom SSH port, the equivalent would be ssh -p 2222 root@203.0.113.10.

On the VPS as root, identify the distribution before you install anything.

cat /etc/os-release

You should see whether the server is Ubuntu, Debian, AlmaLinux, or Rocky Linux. The commands below are split for those families because package names and service management differ.

Create a non-root admin before you do the rest of the work

Keep the root session open until the new login is verified. That avoids lockout if you mistype a permission or SSH setting.

On Ubuntu or Debian as root, create the admin user, add sudo access, and prepare the SSH directory.

adduser deploy

Set a strong password when prompted. Then grant sudo access.

usermod -aG sudo deploy

mkdir -p /home/deploy/.ssh

On AlmaLinux or Rocky Linux as root, create the admin user and add wheel access.

useradd -m deploy

passwd deploy

usermod -aG wheel deploy

mkdir -p /home/deploy/.ssh

Now copy your public key from your local computer. Replace the example key path if yours is different.

On your local computer:

ssh-copy-id deploy@203.0.113.10

That command installs your SSH key for the new user. If your provider did not allow password SSH, paste the key manually into /home/deploy/.ssh/authorized_keys, then fix ownership and permissions.

On the VPS as root:

chown -R deploy:deploy /home/deploy/.ssh

chmod 700 /home/deploy/.ssh

chmod 600 /home/deploy/.ssh/authorized_keys

Open a second terminal from your local computer and test the new login.

ssh deploy@203.0.113.10

Then confirm sudo works.

sudo -v

If that succeeds, you can continue using the deploy account for the rest of the tutorial.

For a separate reference on this step, see How to Create a Non-Root Sudo User on Linux VPS.

Update packages and install the WordPress stack

On Ubuntu or Debian as the non-root sudo user, update package indexes and install Nginx, MariaDB, PHP, and the tools needed for WordPress.

sudo apt update

sudo apt -y upgrade

sudo apt -y install nginx mariadb-server php-fpm php-mysql php-xml php-curl php-zip php-gd php-mbstring php-intl php-bcmath unzip curl

On AlmaLinux or Rocky Linux as the non-root sudo user, install the same stack with DNF.

sudo dnf -y update

sudo dnf -y install nginx mariadb-server php-fpm php-mysqlnd php-xml php-curl php-zip php-gd php-mbstring php-intl php-bcmath unzip curl

Check versions so you know what you are deploying.

nginx -v

php -v

mysql --version

On a typical Hostperl VPS, this stack is enough for a small business site, an agency staging workflow, or a WooCommerce test store. If you expect a busier catalog or multiple sites, a larger VPS or a dedicated server may save you from CPU and memory pressure later.

For a broader look at server choice, you may also find Nginx vs Apache: Which Web Server Fits Your VPS? useful when you are deciding on your long-term web server layout.

Prepare the database for production-like testing

WordPress staging works best when it uses its own database. That keeps test changes isolated and makes rollback simpler.

On the VPS as the non-root sudo user, start and enable MariaDB.

sudo systemctl enable --now mariadb

Then secure the initial install.

sudo mysql_secure_installation

Use a root database password if prompted, remove anonymous users, disallow remote root login, and remove the test database. Those defaults make a fresh server less exposed.

Create a database and user for the staging site.

sudo mysql

CREATE DATABASE wp_staging DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpstage'@'localhost' IDENTIFIED BY 'Use-A-Long-Random-Password-Here';
GRANT ALL PRIVILEGES ON wp_staging.* TO 'wpstage'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Replace the password with a long random value. Do not reuse the same password for WordPress admin access.

Download WordPress into a staging directory

Create a clean document root for the site. This example uses a subdirectory on the same server, which is common for staging during migration work.

On the VPS as the non-root sudo user:

sudo mkdir -p /var/www/example.com/staging

cd /tmp

curl -LO https://wordpress.org/latest.tar.gz

tar xzf latest.tar.gz

sudo rsync -a wordpress/ /var/www/example.com/staging/

Set ownership so the web server can write uploads while you still retain admin control.

On Ubuntu or Debian as the non-root sudo user:

sudo chown -R www-data:www-data /var/www/example.com/staging

On AlmaLinux or Rocky Linux as the non-root sudo user:

sudo chown -R nginx:nginx /var/www/example.com/staging

Create the WordPress config file from the sample.

On the VPS as the non-root sudo user:

cd /var/www/example.com/staging

sudo cp wp-config-sample.php wp-config.php

Edit the file and set the database credentials.

sudo nano wp-config.php

Replace the database values with the ones you created earlier:

define( 'DB_NAME', 'wp_staging' );
define( 'DB_USER', 'wpstage' );
define( 'DB_PASSWORD', 'Use-A-Long-Random-Password-Here' );
define( 'DB_HOST', 'localhost' );

Save and exit the editor. While you are in the file, you can also set the authentication unique keys later if you want a more complete hardening pass, but the site will work without that edit for now.

Configure Nginx for the staging site

Use a dedicated server block so your staging site stays separate from production. That makes it easier to protect with basic authentication or IP restrictions later.

On Ubuntu or Debian as the non-root sudo user, create the site file.

sudo nano /etc/nginx/sites-available/example.com-staging

Paste this configuration.

server {
    listen 80;
    server_name staging.example.com;
    root /var/www/example.com/staging;
    index index.php index.html;

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

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

    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg)$ {
        expires 30d;
        access_log off;
    }
}

On Ubuntu and Debian, the PHP-FPM socket name can vary by version. If /run/php/php-fpm.sock does not exist, list the directory and replace it with the actual socket shown there.

On AlmaLinux or Rocky Linux as the non-root sudo user, create the file with the equivalent PHP-FPM socket for your installed version.

sudo nano /etc/nginx/conf.d/example.com-staging.conf

Paste this configuration.

server {
    listen 80;
    server_name staging.example.com;
    root /var/www/example.com/staging;
    index index.php index.html;

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

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Now enable and test the configuration.

On Ubuntu or Debian as the non-root sudo user:

sudo ln -s /etc/nginx/sites-available/example.com-staging /etc/nginx/sites-enabled/

sudo nginx -t

On AlmaLinux or Rocky Linux as the non-root sudo user:

sudo nginx -t

If Nginx reports syntax is OK, reload it.

sudo systemctl enable --now nginx

sudo systemctl reload nginx

If you need help deciding whether Nginx or Apache fits your site better, Hostperl’s guide on Nginx vs Apache: Which Web Server Fits Your VPS? explains the practical tradeoffs for hosting buyers.

Open the firewall and keep SSH safe

Before you remove any existing access path, make sure the new one is open and tested. That avoids locking yourself out during setup.

On Ubuntu or Debian as the non-root sudo user, install and enable UFW if needed, then allow SSH and web traffic.

sudo apt -y install ufw

sudo ufw allow OpenSSH

sudo ufw allow 'Nginx Full'

sudo ufw enable

sudo ufw status verbose

On AlmaLinux or Rocky Linux as the non-root sudo user, use firewalld.

sudo systemctl enable --now firewalld

sudo firewall-cmd --permanent --add-service=ssh

sudo firewall-cmd --permanent --add-service=http

sudo firewall-cmd --permanent --add-service=https

sudo firewall-cmd --reload

sudo firewall-cmd --list-all

For SSH hardening, do not disable password login until your key-based login is working in a second terminal. After that, edit /etc/ssh/sshd_config and set PasswordAuthentication no only if you are certain the deploy account can still connect.

Launch the WordPress installer and finish setup

Now open the staging URL in your browser. Use http://staging.example.com after your DNS record points to the VPS, or test locally with a hosts file entry if DNS is not ready yet.

The WordPress installer should ask for the site title, administrator account, password, and email. Use a distinct admin username, not admin. That lowers the chance of trivial brute-force attempts.

After installation, log in to the dashboard and check these items:

• Settings > Permalinks: save a clean permalink structure.
• Plugins: remove anything you do not need in staging.
• Appearance: confirm the theme loads without PHP warnings.
• WooCommerce: if this is a shop, test a sandbox checkout before you touch production.

For online stores, the staging workflow is only useful if checkout stays accurate. Hostperl’s WooCommerce Staging That Won’t Break Checkout article covers the extra care needed around payments, taxes, and webhook callbacks.

Check the server, the site, and the logs

Verification should happen from both the server and a client machine. That catches permission errors, PHP-FPM issues, and DNS mistakes faster than a visual check alone.

On the VPS as the non-root sudo user, confirm services are up and listening.

sudo systemctl status nginx mariadb php-fpm

sudo ss -tulpn | grep -E ':80|:443'

Then inspect logs if the page does not load.

sudo tail -n 50 /var/log/nginx/error.log

From your local computer, test the HTTP response.

curl -I http://staging.example.com

You should see a 200 or a WordPress redirect chain, depending on whether you have already enabled TLS and canonical redirects. If the browser shows a 502 error, the first place to check is PHP-FPM and the socket path in the Nginx configuration.

Add HTTPS before you let anyone use it widely

Staging sites often stay private, but if your team needs browser access from outside your office or from clients, add TLS. Let’s Encrypt is the common path.

On Ubuntu or Debian as the non-root sudo user:

sudo apt -y install certbot python3-certbot-nginx

On AlmaLinux or Rocky Linux as the non-root sudo user:

sudo dnf -y install certbot python3-certbot-nginx

Run Certbot for the staging hostname after DNS points to the server.

sudo certbot --nginx -d staging.example.com

Follow the prompts, choose the redirect option if offered, and then confirm renewal is scheduled.

sudo certbot renew --dry-run

Keep staging useful after day one

A staging site is only valuable if it stays current enough to reflect production. Schedule a periodic refresh from production data, but scrub customer data first. If you manage multiple client sites, that cadence is usually part of the handoff process after a migration or redesign.

For panel-based migrations and handover work, Hostperl’s Migrate a Hosting Panel Account Without Downtime in 2026 guide pairs well with staging because it keeps launch risk down while you validate the new environment.

Backups matter too. If your staging copy becomes the pre-launch source of truth, keep a restore point before every major plugin or theme change. A VPS snapshot or a database dump gives you a fast rollback path if a plugin update breaks the admin area.

FAQ

Should staging use a subdomain or a separate domain?

A subdomain such as staging.example.com is usually simplest. It keeps DNS, SSL, and web server rules clear.

Can I use the same database as production?

No. Use a separate database for staging so test changes do not affect live content or customer orders.

Why do I get a 502 Bad Gateway error?

Check the PHP-FPM socket path in Nginx, then confirm the PHP service is running with systemctl status php-fpm. The error log usually shows the exact mismatch.

Do I need HTTPS on staging?

Yes, if the staging site is accessible over the public internet. TLS protects logins and keeps browser warnings away.

How often should I refresh staging from production?

Refresh it before major theme, plugin, or checkout changes. For busy stores, that may mean weekly or before every release.