CloudStick is a server control panel for developers and agencies that lets you manage cloud servers on AWS, DigitalOcean, Vultr, Linode, and Hetzner without using the command line. Plans start at $9/month — the Basic plan covers 1 server with unlimited websites; Pro at $19/month and Business at $49/month cover unlimited servers.

Will features I pay for ever get moved to a higher plan?

No. CloudStick is committed to keeping all features you currently pay for within your existing plan. New features may be added to higher tiers, but existing plan features will never be removed or require a forced upgrade.

What happens to my servers if I cancel CloudStick?

Your servers remain fully operational after cancellation. CloudStick does not host your servers — it manages them. If you cancel, you lose access to the CloudStick dashboard, but your servers continue running on your cloud provider.

Is there a free trial for CloudStick?

Yes. CloudStick offers a 7-day free trial on all paid plans with no credit card required. You can explore every feature and upgrade, downgrade, or cancel at any time during or after the trial.

WORDPRESS

July 1, 2026

How to Set Up a WordPress Staging Environment

8 min read

CloudStick Team

WordPress Engineer

Share this article

How to Set Up a WordPress Staging Environment

Migration Guide

Why Staging Exists

A staging environment is a private copy of your live site — same code, same database structure, same PHP version — that you can break without consequences. The single biggest cause of WordPress disasters is testing a plugin update, theme change, or PHP upgrade directly on production; staging exists to move that risk somewhere nobody but you can see.

Staging only works if it's a faithful copy. A staging site running a different PHP version, or with stale content from three months ago, will pass tests that then fail on production because the environments never actually matched. Rebuild staging from production regularly, not just once at setup.

Clone Production to Staging

Create a subdomain like staging.example.com pointing at the same server or a separate one, then copy files and database across exactly as you would for a full migration:

# Copy files into the staging document root
rsync -av /home/example/apps/example.com/ /home/example/apps/staging.example.com/
# Dump and import the database under a separate name
mysqldump -u dbuser -p wp_example > wp_example.sql
mysql -u dbuser -p wp_example_staging < wp_example.sql
# Point wp-config.php at the staging database and update the site URL
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --all-tables

CloudStick's WordPress manager has a one-click staging clone that automates this exact sequence — file copy, database export/import, and search-replace — directly from the site dashboard.

Isolate Staging from Search Engines

WARNING

Never leave a staging subdomain publicly indexable. Add a site-wide X-Robots-Tag: noindex header in Nginx, and password-protect the subdomain with HTTP basic auth so search engines and casual visitors can't reach it at all.

# In the staging site's Nginx server block
add_header X-Robots-Tag "noindex, nofollow" always;
# HTTP basic auth
auth_basic "Staging";
auth_basic_user_file /etc/nginx-cs/.htpasswd-staging;

Keep Staging in Sync

A staging environment that hasn't been refreshed in months is worse than no staging at all — it gives false confidence. Re-sync files and the database from production on a fixed schedule (weekly is reasonable for most sites), or right before any significant change you plan to test.

Workflow Going Forward

Once staging exists, the rule is simple: nothing touches production directly except emergency fixes. Plugin updates, theme changes, and PHP version bumps all go to staging first, get tested against real content, and only then get replicated to production using the push-live process covered in the next guide.