Deploy a Local WordPress Site to Production with WP Staging Desktop

By , Founder · Updated

WP Staging Desktop lets you develop and test a real WordPress site on your computer. When the local work is ready, WP Staging Pro can deploy it through the released backup-and-restore workflow: create a .wpstg backup from the local site, upload it to the destination WordPress site, and restore it there.

This is a full backup-based deployment workflow. It is not direct push, and restoring the backup can replace files and database content on the destination. Always create a fresh destination backup before you begin.

Get WP Staging Desktop

In this guide

TL;DR

Create a fresh backup of the production destination, create and download a .wpstg backup from the local Desktop site, upload that local-site backup to the destination running WP Staging Pro, review the restore scope, and restore it. WP STAGING updates the domain references for the destination. Direct push from Desktop is still in testing.

Warning: Restoring the local-site backup can overwrite newer production files and database content. Do not restore a stale local database over an active store, membership site, or other site receiving live data.

Throughout this guide, source and local site mean the WordPress site you built inside WP Staging Desktop on your computer. Destination and production mean the live WordPress site on another domain that will receive the deployment.

Understand the direction: Free versus Pro

The line between Free and Pro is not whether two domains match. It is the direction of the workflow and where the backup is going.

Workflow Destination Requirement
Import a downloaded backup into Desktop Any local domain WP Staging Desktop Free
Deploy a backup created from a local site Another live or production domain Any WP Staging Pro plan
Restore directly from a remote backup URL or pull production data Connected local workflow Developer or Agency
Direct push from Desktop Production Not released; in testing

WP Staging Desktop Free restores a downloaded .wpstg backup into a local site. That local site can use any local domain, such as mysite.local or client.local. Restore is not limited to the backup’s original domain, and Desktop performs the local domain search-replace for you automatically.

Deploying a backup created locally out to another live or production domain is the outbound direction, and that requires WP Staging Pro. Free versus Pro is determined by the direction and destination of the workflow. Desktop Free imports backups into local development. WP Staging Pro deploys a backup created locally out to another live domain.

Developer and Agency plans add connected workflows on top of this: direct restore from a remote backup URL, production connection and pull, and the WP STAGING CLI. Those are useful context, but they are not required for the basic downloaded-file deployment in this guide.

What this workflow changes

A restore writes the contents of the backup onto the destination. Before you start, understand what that means for the live site:

  • The destination receives the files included in the backup restore.
  • The destination receives the database content included in the restore.
  • WordPress URLs and domain references are updated for the destination during restore.
  • The destination may lose content created after the local copy was made.
  • A restore is not a content merge.
  • The destination login may use the credentials contained in the restored database.
  • Cache, permalinks, integrations, email, and scheduled tasks must be checked afterward.

The scope of a restore follows the scope of the backup. When you create the backup on the local site, you select which components to include (files, database, or both). The restore then applies what that backup contains. Choose the backup components deliberately, because that choice decides what gets written over on the destination.

Warning: Restoring a database that was captured on the local site can replace newer production posts, orders, users, settings, and submissions. Do not proceed until you understand the restore scope.

Prerequisites

Before you deploy, make sure you have all of the following:

  • A working local site in WP Staging Desktop.
  • The local changes tested and approved.
  • The ability to create a complete .wpstg backup on the local site.
  • A valid WP Staging Pro plan for deployment to another live domain.
  • WP Staging Pro installed and activated on the destination, following the current license flow.
  • Administrator access to the destination.
  • Enough destination disk space for the uploaded backup, its extraction, and the rollback backup.
  • A maintenance window for the production site.
  • A fresh destination backup created before you start.

For WooCommerce stores, memberships, LMS platforms, forms, forums, and other dynamic sites, add one more planning step:

Plan how to protect live transactions and user-generated content before restoring the local database. If production has changed since the local copy was created, a full database restore may remove those newer changes.

Step 1: Review what changed locally

Confirm exactly what you are about to deploy before you package anything.

  1. Open the local site from WP Staging Desktop.
  2. Review the site in the browser and in the WordPress admin.
  3. Confirm plugins, themes, PHP compatibility, settings, and content are correct.
  4. Decide whether the deployment includes files, the database, or both, based on the actual backup and restore options.
  5. Record any production-only integrations or credentials that will need to be verified again after deployment.

This workflow replaces content; it does not merge selected changes. Plan the deployment as a full-state restore of what the backup contains.

Step 2: Back up the destination production site

Create the rollback point first. This step must happen before you create or upload the deployment backup.

On the destination WordPress site, open WP STAGING > Backup & Migration, create a complete backup, and wait for it to finish. Download a copy or confirm it is stored somewhere you can reach if the deployment must be rolled back.

Before continuing, verify that:

  • The backup completed successfully.
  • The backup includes the required files and database.
  • The backup can be identified clearly as the pre-deployment restore point.
  • The restore action is available for it.

Warning: Do not continue if the destination backup fails. Without a verified rollback point, a failed deployment can leave you with no way back to the working production site.

Step 3: Create a backup from the local Desktop site

Now package the local state you want to deploy.

  1. Open the local site from WP Staging Desktop.
  2. Open its WordPress admin.
  3. Open WP STAGING > Backup & Migration.
  4. Choose Create Backup.
  5. Create a full-site backup unless your planned restore scope intentionally differs, then leave the component checkboxes as needed.
  6. Give it a descriptive name such as local-deployment-2026-07-18.
  7. Click Start Backup and wait for backup creation to complete.

This backup represents the local state that will be restored on the destination. When it finishes, it appears in the Your Backups list.

Step 4: Download the local-site backup

Move the backup off the local machine so you can upload it to the destination.

  1. Find the completed backup in the Your Backups list.
  2. Open its Actions menu.
  3. Choose Download.
  4. Save the .wpstg file to your computer.
  5. Confirm the download finished and the file is not zero bytes.

This guide deliberately documents the plan-independent Pro file workflow, so the downloaded .wpstg file is the path used everywhere below.

Developer and Agency plans can use connected or remote workflows where supported, such as restoring directly from a remote backup URL. This guide does not use that path, because the downloaded-file procedure works on any WP Staging Pro plan.

Step 5: Prepare the destination

Get the production site ready before anything destructive happens.

  • Put the destination into an appropriate maintenance state.
  • Pause content entry and any other deployments.
  • For active commerce or membership sites, stop or account for new orders, subscriptions, registrations, comments, and submissions.
  • Confirm there is sufficient disk space for the upload, extraction, and rollback backup.
  • Confirm WP Staging Pro is active on the destination.
  • Confirm the fresh destination backup from Step 2 is available.
  • Record the destination URL.

Warning: The next steps can replace destination data. Confirm the deployment window with everyone responsible for the live site before you upload the backup.

Step 6: Upload the local-site backup

Transfer the downloaded backup to the destination.

  1. On the destination, open WP STAGING > Backup & Migration.
  2. Choose Upload Backup.
  3. Select the downloaded local-site .wpstg file.
  4. Wait for the upload and validation to finish.
  5. Confirm the backup appears in the destination backup list.

Use the standard browser upload shown here first. If the file is large or the upload does not complete, see the migration to another host guide for alternative transfer methods. The remote backup URL import is a Developer and Agency feature, so it is not the default path in this guide.

Step 7: Review and start the restore

This is the step that overwrites the destination. Slow down and check before you confirm.

  1. Identify the uploaded local-site backup in the destination list.
  2. Open Actions > Restore.
  3. Review the exact files and database scope shown by the restore screen.
  4. Confirm that the selected source is the local deployment backup, not another backup.
  5. Confirm that the destination backup from Step 2 still exists.
  6. Read the overwrite warning shown before the restore starts.
  7. Start the restore only after all of these checks pass.

Warning: Restoring database content can replace newer production posts, orders, users, settings, and submissions. Stop and reassess if production has received important changes since the local copy was created.

This is a backup restore, not direct push. Nothing is merged, and there is no selective sync of only the changes you made locally.

Step 8: Wait for completion

Let the restore run to a clear result.

  • Keep the browser and site available unless the restore screen tells you the job can continue in the background.
  • Do not start another backup, restore, plugin update, or deployment at the same time.
  • Wait for the success state, which WP STAGING shows as a Finished Successfully result.
  • If the restore reports an error, record the exact message before you retry anything.

Restore time depends on the size of the backup and the destination server, so there is no fixed duration to expect.

Step 9: Verify the production site

Work through the destination methodically before you reopen it to visitors.

  • Homepage and key frontend pages load.
  • WordPress admin login works.
  • The site URL and home URL use the destination domain.
  • Permalinks work.
  • HTTPS works without mixed-content warnings.
  • Plugins and the theme are active as expected.
  • Media files load.
  • Forms work.
  • Transactional email is configured correctly.
  • Scheduled tasks and cron are running.
  • Cache and CDN are cleared.
  • Search engine visibility is set correctly for production.
  • Analytics and consent tools work.
  • Payment gateways and webhooks point to the production environment.
  • WooCommerce checkout works without placing an unintended real order.
  • No local-only development plugin, email catcher, debug setting, or test credential remains active.

Keep the destination in maintenance mode until the essential checks pass.

Step 10: Finish or roll back

Decide based on what the verification showed.

If verification succeeds:

  • Remove maintenance mode.
  • Resume content entry and transactions.
  • Monitor logs, forms, email, checkout, and key pages.
  • Keep both the pre-deployment backup and the local deployment backup according to your normal retention policy.

If verification fails:

  • Return to WP STAGING > Backup & Migration on the destination.
  • Restore the fresh pre-deployment destination backup from Step 2.
  • Recheck the destination.
  • Investigate the deployment copy away from production before trying again.

Warning: Do not repeat a failed restore against production blindly. Roll back to the pre-deployment backup first, then find the cause on a copy that is not serving live traffic.

Backup deployment versus direct push

This guide documents the released backup-based method. It is worth being explicit about how that differs from direct push, which is a separate, unreleased feature.

Backup-based deployment Direct push
Available today with WP Staging Pro Not released; in testing
Create, transfer, and restore a .wpstg backup Intended future connected push workflow
Requires explicit restore and overwrite review Do not rely on it until released
Suitable for controlled full-site deployment Future scope must not be assumed

Direct push from WP Staging Desktop will receive separate documentation after it is released. Until then, use the released backup-based method described above.

Common problems

Backup upload is too large

  • Check the destination upload and PHP limits.
  • Check available disk space.
  • Use the migration to another host guide for alternative transfer methods when a browser upload will not complete.
  • Do not broadly weaken server security to force a large upload through.

Backup does not appear after upload

  • Confirm the file uses the .wpstg extension.
  • Confirm the upload completed.
  • Refresh the backup list.
  • Check the documented backup directory and permissions only where the current documentation supports doing so.

Restore fails

  • Preserve the error message before doing anything else.
  • Check disk space and the server logs.
  • Confirm the plugin version and backup are compatible.
  • Do not repeatedly retry against production without understanding the failure.
  • See the backup and restore troubleshooting guide for common restore failures.

Login no longer works

  • The restored database can replace the destination credentials with the ones from the local site, so use the local site’s admin login after a full database restore.
  • If you are locked out, follow the steps to reset your WordPress admin password manually.
  • Open Settings > Permalinks and save the existing structure to flush the rewrite rules.

Redirect or mixed-content problems

  • Confirm the destination WordPress Address and Site Address in Settings > General.
  • Clear the page cache, object cache, CDN, and browser cache.
  • Confirm HTTPS is working and that the domain replacement completed.

New production data is missing

  • A full local database restore may have replaced production data created after the local copy was made.
  • Stop making further changes.
  • Assess a rollback from the pre-deployment backup created in Step 2.
  • There is no automatic merge recovery, so treat the pre-deployment backup as the way back.

FAQ

Do I need WP Staging Pro to deploy a Desktop site to production?

Yes. Desktop Free can restore a downloaded backup into a site under any local domain. Deploying a backup created locally to another live or production domain requires WP Staging Pro.

Do I need Developer or Agency?

Not for the downloaded-file backup deployment described here. Developer and Agency add remote backup URL restore, production pull, connected sync, and the WP STAGING CLI.

Is this direct push?

No. This is the released backup-and-restore deployment workflow. Direct push from Desktop is still in testing.

Does WP STAGING change the local domain to the production domain?

WP STAGING performs the required domain search-replace during restore. Verify the destination WordPress URLs, HTTPS, cache, and integrations after deployment.

Will this preserve new orders and production content?

Do not assume it will. Restoring the local database can overwrite orders, users, posts, submissions, settings, and other production data created after the local copy was made. Create a fresh production backup and plan the restore scope and maintenance window carefully.

Can I deploy only selected changes?

Use only the scope controls that the current backup and restore screens explicitly provide, such as choosing which components a backup includes. This workflow is not a content merge, and this guide does not document unreleased direct push.

Can I roll back?

Yes, if you created and verified the fresh destination backup before deployment. Restore that pre-deployment backup if the deployed site fails verification.

View WP Staging Pro Plans

Updated on July 20, 2026

Rene Hermenau

Author: Rene Hermenau

About the author: René Hermenau is the founder of WP STAGING. He works on WordPress backups, staging, migrations, database handling, and safe deployment workflows.