WordPress

Using Staging: Pushing to Production and Pulling From Production

Once a staging copy exists, two operations keep it useful: pushing your tested changes up to the live site, and resetting staging back to a fresh copy of production. This guide covers both directions in detail, the confirmations that protect your live site, and the cases where pushing a database would destroy data.

If you have not created a staging environment yet, start with Using Staging Environments. This article picks up from the point where staging exists.

The Two Directions

OperationWhat it overwritesUse it when
Push to ProductionYour live siteChanges on staging are tested and ready to go live
Reset from ProductionYour staging siteYou want a clean copy of the current live site to work against

Both live on the same screen: Websites, then your site, then Environments, then Staging.

Staging tab on a site in KPanel

The card at the top of that screen shows your staging domain, its status, how long ago it was last synced from production, and when it was last pushed. WP Admin signs you straight into the staging site's dashboard, and Visit site opens the staging front end.

A staging copy that has not been synced for a week or more is flagged in amber on that card. Old staging is worse than no staging: you end up testing against a site that no longer resembles the live one. Reset before you start a new piece of work, not after.

Pushing Staging to Production

This replaces part or all of your live site with what is on staging.

  1. Open Environments, then Staging.
  2. Scroll to Push Staging to Production.
  3. Choose what to push with the checkboxes: Files, Database, or both.
  4. If you ticked Database, leave Rewrite URLs ticked. It runs a search and replace across every table so the staging hostname is swapped for your production one as part of the push.
  5. Tick I understand this modifies my live production site.
  6. Type your production domain into the confirmation box exactly as shown.
  7. Click Push to Production.

The button stays disabled until both the checkbox is ticked and the domain matches, so a mistimed click cannot start a push.

A push overwrites, it does not merge. Anything that changed on production since your last reset is replaced by whatever is on staging. That includes new posts, new customer accounts, new form entries and new orders.

A full backup of production is taken automatically before anything is written, and if the push fails partway through, production is rolled back to that backup. Small sites usually finish in well under a minute; a large database or a media library of several gigabytes takes longer.

Choosing Files, Database, or Both

This is the decision that matters most, and the answer is usually not "both".

Files only. The safe default for a site that collects anything from visitors. Theme edits, plugin updates, template changes and custom code all live in files. Pushing files alone leaves every post, comment, order and user on production untouched.

Database only. For content or settings changes made on staging, on a site where nobody edits production directly. Rare in practice.

Both. Correct for a redesign or a rebuild where staging is the new site and production is being replaced wholesale. Announce it, do it out of hours, and confirm you have a current backup first.

Pushing the database to a live store deletes orders. WooCommerce keeps orders, customers, subscriptions, coupons and stock levels in the database, so every order placed since your last reset from production disappears the moment the push completes. There is no partial recovery. On a store, push files only, and make database level changes on production directly. See Setting Up WooCommerce.

The same trap applies, less dramatically, to any site with comments, form submissions, membership signups or a mailing list stored in WordPress.

Resetting Staging From Production

This is the safe direction: it overwrites staging with the current live site and never touches production.

  1. Open Environments, then Staging.
  2. Find Reset from Production.
  3. Tick Files, Database, or both.
  4. Click Reset from Production.

Do this whenever:

  • Production has moved on, with new posts, new orders or content edits.
  • You are starting a new piece of work and want a realistic base.
  • Staging has drifted far enough that a test result there means nothing.

Anything on staging that has not been pushed is lost. If there is work on staging you still want, push it first, or copy the changed files out through Files, then File Manager before you reset.

How URL Rewriting Works

WordPress stores its own address in the database, in the siteurl and home rows of the options table, and absolute URLs also end up in post content, meta values, widget settings and theme options.

Your staging site runs at staging. followed by your domain, so every one of those values points at the staging hostname while you work there. Rewrite URLs on the push runs a proper search and replace across all tables, handling serialised plugin settings correctly, and swaps the staging hostname for your production one.

Leave it ticked unless you have a specific reason not to. If you push files only, or a stray staging URL survives, fix it with Running a Search and Replace.

A Workflow That Holds Up

  1. Reset from production so staging matches the live site.
  2. Take a backup of production before you begin, so you have a restore point independent of the push: Taking a Backup.
  3. Do the work on staging. Plugin and theme updates, new code, layout changes.
  4. Test on the staging domain. Load the pages you changed, and the pages you did not. On a store, run a test order end to end.
  5. Push files only unless you have deliberately decided the database must go too.
  6. Check production immediately. Home page, a deep page, the checkout, and the admin dashboard.
  7. Reset staging from production again once you are happy, so the next round starts clean.

Staging is managed entirely from your production site. It does not appear as a separate entry in the Websites list, so every control for it, including deleting it, lives on this one tab.

Deleting Staging

The Delete Staging card at the bottom of the same screen removes the staging copy. Production is unaffected. Delete it when a project is finished: staging counts towards your plan's storage, and a stale copy is a liability rather than an asset.

Troubleshooting

The Push to Production button will not activate. Both conditions must be met: the confirmation checkbox ticked, and the production domain typed exactly, with no https:// and no trailing slash.

The push finished but the site still shows old content. Caching. Flush from WordPress, then Quick Actions, then Flush Cache, purge the CDN from Performance, then Kapsule CDN, and reload in a private window.

Staging URLs are showing on the live site after a push. The database went across without Rewrite URLs ticked. Run a search and replace from the staging hostname to your production domain: Running a Search and Replace.

I pushed the database and lost orders. Restore the automatic pre-push backup straight away, before more orders arrive on the overwritten database: Restoring From a Backup.

Staging shows an error after a reset. A plugin that hardcodes the production domain is the usual cause. Sign in with WP Admin on the staging card and deactivate plugins there until the error clears, then fix or replace the offending one on production.

Still need help?

Email us at support@kapsulehost.com or open a chat in KPanel.

Open KPanel