11 min read

Our verdict

Cloudways Managed Cloud

Best for: Cloudways staging is free on every application and more careful than most: you can push only changed files, and only the database tables you choose, which is what protects a live shop's new orders. The tool is safe as long as you read the push dialog each time. Full DB pushes on a site that takes orders or sign-ups, real emails sent from the staging copy, and forgetting to clear caches afterwards cause nearly all the trouble.

Overall score

8.6/ 10

What we liked

Staging is free on every application, on every plan
Pushes can be incremental, sending only files that changed
Selected Tables pushes leave orders, users and form entries on the live site untouched
A backup of the live site can be taken automatically before each push
Staging copies are password-protected and hidden from search engines by default

What to watch

One staging copy per application
Incremental pushes do not delete files you removed on staging
You can exclude at most nine directories from a file push
The built-in search-and-replace only handles the primary domain
Deleted staging applications cannot be recovered

PriceFree on every Cloudways Flexible application; counts toward quota on Autonomous

Try Cloudways staging free →Affiliate link — we may earn a commission.

How to use Cloudways staging without losing live data

How to use Cloudways staging: create a copy, test changes, and push files or selected database tables to live without overwriting orders, users or comments.

By Tom Kessler · Senior Editor, Software & Automation

5 November 2026

How we pay for this

We buy the hardware and pay for the subscriptions we write about. Claim a deal through our link and we may earn a commission — our readers sometimes get a discount or a freebie out of it too, but it never pushes the price up, and it never changes what the review says.

Cloudways staging creates a full copy of an application where you can test changes, then push them to the live site, choosing whether to send all files or only changed ones, and the whole database or only selected tables. It is free on every Cloudways application. The selected-tables option is the one that matters for shops and membership sites, because it lets you push a change without overwriting orders or sign-ups that arrived after you made the copy.

This guide covers creating a staging copy, the push and pull options one by one, a safe routine for live stores, and the mistakes that most often cost people data.

Create a staging copy

Open the live application. In Cloudways Flexible, go to the server, open its applications, and pick the one you want to copy.
Open Staging Management under Application Management and click Launch Staging Application.
Choose where it goes. The same server is simplest. A different server works if it meets the application's requirements; if the two servers have different package versions, Cloudways warns you, and it is worth matching them first.
Tick Create as Staging and continue. The copy takes a few minutes, depending on the size of the site, and appears in your applications list with a staging tag.

The staging copy has its own temporary address, shown in Access Details, and is protected by a separate username and password by default, so the public and search engines cannot see it. Its WordPress admin login is the same as the live site's until you change it. On Cloudways Autonomous the process is similar, from the application's Workflow tools; there, staging does not count as an extra site but its visits, disk and bandwidth count toward your plan.

Before you change anything on staging

A staging site is a working copy of your live site, which means it can do things the live site does. Two need stopping straight away on any site that emails people or charges them:

Outgoing email. If the server's SMTP add-on is configured, the staging copy can send real emails to real customers, such as order updates or newsletters triggered by a test. Install a plugin that blocks or logs outgoing mail on staging.
Scheduled tasks and payments. Subscription renewals and other scheduled jobs can run on the copy. Some subscription plugins detect a changed URL and pause; check yours does before testing.

Pushing staging to live: every option explained

Open Staging Management on the staging application and click Push. The dialog has three parts.

Web application files sends the contents of public_html. Overwrite replaces all the live site's files with staging's, including configuration files. Incremental sends only files that changed on staging, which is faster and safer, but it does not delete files you removed on staging, so a deleted plugin folder will stay on the live site. You can exclude up to nine directories from either type, such as the uploads folder if customers upload files to the live site.

Database offers Full DB, which replaces the entire live database with staging's, or Selected Tables, which replaces only the tables you tick. Full DB is safe only when nothing has been written to the live site since you made the copy. On any site with orders, comments, form entries or new users, use Selected Tables.

Backup takes an on-demand backup of the live application before the push. Always tick it. It is the difference between a mistake and a disaster.

A safe routine for a live store

Pull before you start. If the staging copy is old, use Pull to bring the live files and database into staging, so you are working on current data.
Make and test your change on staging, logged in and logged out, and through checkout if it is a shop.
Push files incrementally and, for the database, push only the tables your change touched. A theme or settings change usually lives in the files and the options table (wp_options). WooCommerce orders live in their own tables on stores using its order storage (wp_wc_orders and related tables), or in wp_posts and wp_postmeta on older stores, in which case leave those two alone.
Tick the backup box and push during your quietest hour.
Clear caches in Breeze, Varnish if you use the Hybrid stack, and Cloudflare or any CDN, then check the live site.

The staging copy stays after a push, ready for the next change. Our WooCommerce guide covers store-specific tables in more detail.

Pulling live to staging

Pull works in the other direction, with the same choices: overwrite or incremental for files, full or selected tables for the database. It is the way to refresh a stale staging copy, or to bring the latest products and content in before testing an update. Because it only ever writes to staging, it carries no risk to the live site.

Domains and search-and-replace

When Cloudways copies and pushes, it replaces the primary domain with the staging address and back again. It only knows about the primary domain. If your site also uses other domains, for example a separate domain for a language version or an image subdomain, run a search-and-replace for those yourself in the database, with WP-CLI or a plugin, after creating staging and again after pushing.

When a push goes wrong

Live site shows the old version. A cache is serving the previous page. Clear Breeze, Varnish and your CDN, and check in a private window.
Recent orders or users disappeared. A Full DB push replaced them. Restore the live application from the backup taken before the push, then repeat the push with Selected Tables.
A plugin you deleted on staging is still live. Incremental pushes do not delete files. Delete it on the live site, or use an Overwrite push.
Links point to the staging address. A secondary domain or a hard-coded URL was not replaced. Run a search-and-replace for the staging address on the live database.
Errors when creating staging on another server. Package versions differ between the servers, or a custom PHP session path is in the way. Match the packages, or create staging on the same server.

Staging is one of the reasons Cloudways suits people who change their sites often. For keeping plugins updated across many sites without doing each push by hand, see our Site Manager review, and for the backup side, our backup and restore guide.