compare VPS plans side by side<\/a> in our comparison table to find an affordable staging box. What matters is that staging is isolated from production, reachable only by your team, and refreshed on a schedule you control.<\/p>\n\nWhat a Staging Environment Should Mirror<\/h2>\n\n
The closer staging matches production, the more useful it is. At minimum, replicate the operating system and major package versions, the web server configuration, the application code, and a recent copy of the database. The two things you should deliberately change are access control (staging should be password-protected) and any data you do not want developers to see, such as customer emails or payment records.<\/p>\n\n
Step 1: Provision the Staging VPS<\/h2>\n\n
Provision a second VPS from your provider using the same operating system image and PHP version as production. If production uses a control panel such as Hestia or CyberPanel, install the same panel on staging so configuration paths match and you can copy settings verbatim. Note the staging server’s IP address and confirm SSH key access works before continuing.<\/p>\n\n
ssh root@STAGING_IP\n# verify OS and PHP version match production\ncat \/etc\/os-release\nphp -v<\/code><\/pre>\n\nStep 2: Point a Subdomain at Staging<\/h2>\n\n
Create a subdomain such as staging.example.com<\/code> and add an A record pointing to the staging server’s IP. Then configure a web server block. With Nginx, a minimal server block looks like this:<\/p>\n\nserver {\n listen 80;\n server_name staging.example.com;\n root \/var\/www\/staging;\n index index.php index.html;\n\n location \/ {\n try_files $uri $uri\/ \/index.php?$args;\n }\n\n location ~ \\.php$ {\n include snippets\/fastcgi-php.conf;\n fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;\n }\n}<\/code><\/pre>\n\nProtect the subdomain with HTTP Basic Auth so search engines and random visitors cannot reach it:<\/p>\n\n
sudo apt install apache2-utils\nsudo htpasswd -c \/etc\/nginx\/.htpasswd deploy\n# then add inside the server block:\n# auth_basic \"Staging\";\n# auth_basic_user_file \/etc\/nginx\/.htpasswd;<\/code><\/pre>\n\nStep 3: Sync Code and Files with rsync<\/h2>\n\n
Copy the application code from production to staging with rsync. Use --delete<\/code> so files removed in production disappear from staging too, and exclude caches, logs, and uploads that should stay local:<\/p>\n\nrsync -avz --delete \\\n --exclude 'wp-content\/cache' \\\n --exclude '*.log' \\\n root@PROD_IP:\/var\/www\/prod\/ \/var\/www\/staging\/<\/code><\/pre>\n\nFor large sites, run the first sync inside screen<\/code> or tmux<\/code> because it can take a while over a slow uplink. Subsequent syncs are incremental and finish in seconds.<\/p>\n\nStep 4: Clone and Sanitize the Database<\/h2>\n\n
Dump the production database and import it on staging. For WordPress, wp-cli makes this one command per side:<\/p>\n\n
# on production\nwp db export \/tmp\/prod.sql\n\n# on staging\nwp db import \/tmp\/prod.sql<\/code><\/pre>\n\nBefore the site is usable, sanitize personal data and rewrite the domain. Replace customer emails and anonymize anything sensitive so staging never becomes a data-leak risk, then swap production URLs for the staging subdomain:<\/p>\n\n
wp search-replace 'user@example.com' 'dev@staging.local' --all-tables\nwp search-replace 'https:\/\/example.com' 'https:\/\/staging.example.com' --all-tables<\/code><\/pre>\n\nStep 5: Automate the Refresh with cron<\/h2>\n\n
Manual refreshes go stale within days, and testing against stale data produces false confidence. A cron job that runs the sync and database import nightly keeps staging useful. Wrap the commands from steps 3 and 4 in \/usr\/local\/bin\/sync-staging.sh<\/code> and register it:<\/p>\n\n30 2 * * * \/usr\/local\/bin\/sync-staging.sh >> \/var\/log\/staging-sync.log 2>&1<\/code><\/pre>\n\nAlternative: Docker-Based Staging<\/h2>\n\n
If production already runs in containers, run staging as the same compose stack on the staging VPS with different environment values for the domain and database credentials. You get identical images and can tear the whole environment down with docker compose down<\/code> when a test cycle ends, which keeps the staging VPS clean between sessions.<\/p>\n\n