WordPress Deployment: Methods, Database Sync and a Safe Release Routine

WordPress deployment means moving a site from where you build it to where visitors use it, and it is harder than copying files because content lives in the database, so a safe routine separates code, uploads and data and treats each differently.

The mistake behind most deployment disasters is treating WordPress like a folder. It is a folder plus a database that the site owner keeps changing.

Table of contents

• Three things that are not deployed the same way
• Method one: manual upload
• Method two: Git and automated deploys
• Staging and syncing data safely
• The release routine
• Managed hosting and the dashboard route
• Caching, performance and what to check after a deploy
• How this fits the rest of the stack
• FAQ

Three things that are not deployed the same way

A WordPress site is made of three layers, and each one needs its own rule.

Code. Themes, plugins and your custom code. This is the part developers write and should move from development to production, ideally from version control.

Uploads. Media files in wp-content/uploads. Editors add these on the live site, so production is the source of truth. You rarely deploy uploads from development.

Data. The database: posts, pages, settings, menus, users, orders and comments. On a live site, editors and customers keep changing it. Overwriting production’s database with a development copy erases whatever happened since you last pulled.

That last point is the heart of WordPress deployment. In a typical web application the rule is code moves up and data stays put. WordPress follows the same rule with an awkward twist: some site configuration, such as widget layout or a page builder’s settings, lives in the database but feels like code.

The hosting vendors that publish deployment guides tend to describe the same philosophy: code moves up, content moves down. Develop changes on a copy, deploy code to production, and when you need realistic content for testing, copy it from production down to the copy, not the other way around.

If you are moving a site for the first time rather than deploying changes, the post on migrating a WordPress website to a new host covers that different job.

Method one: manual upload

The simplest method is transferring files over SFTP and importing a database dump. It requires no tooling and suits small sites, emergency fixes and one-off setups.

The outline: export the database from the source, upload the files to the target, create an empty database and user there, import the dump, and update wp-config.php with the new database credentials. Then fix the site URL, because WordPress stores its address in the database, and a changed domain breaks links.

wp search-replace 'https://old.example.com' 'https://www.example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old.example.com' 'https://www.example.com' --skip-columns=guid

Use WP-CLI’s search-replace rather than a plain text replace on the dump, because WordPress stores serialised data with string lengths, and a naive replacement corrupts it. The dry run shows what would change.

Manual deployment has real costs. Nothing records what changed, a missed file is easy, and doing it under pressure invites mistakes. Always take a backup of production first: database dump plus files. If you cannot restore it, you do not have a backup.

Use it for what it is good at, and move to something repeatable once deploys become routine. The post on backing up a WordPress site covers the backup half.

Method two: Git and automated deploys

For teams, keep the code in Git and deploy it automatically. What goes in the repository matters. A common structure tracks only your own theme, your own plugins and a configuration for dependencies, and leaves WordPress core, third-party plugins and uploads out.

wp-content/themes/my-theme/
wp-content/plugins/my-plugin/
composer.json
.gitignore

Managing third-party plugins with Composer keeps versions pinned and updates reviewable. Core can be handled the same way or installed as part of the build.

A deploy pipeline then does a few things on each merge to the main branch: build assets, run tests, copy changed files to the server and clear caches. A short workflow might run the build, sync the theme folder with rsync, and call WP-CLI to flush caches.

Add a database backup step before the file sync, so a bad release can be reversed. Exclude wp-config.php and uploads from the sync, since they differ per environment and must not be overwritten.

Secrets such as database passwords and authentication salts belong in environment configuration on the server, not in the repository. Use separate configuration per environment so staging cannot accidentally write to production.

Staging and syncing data safely

A staging site is a copy of production where you test changes before release. It is only useful if it resembles production.

Refresh it by copying production down: export the production database, import it into staging, search-replace the URLs, and sync the uploads. Then block search engines from indexing it and disable outgoing email and payment processing, so staging never emails real customers or charges real cards.

For releases that need data changes, such as new settings or pages, script them. WP-CLI commands and migration scripts are repeatable, while clicking through the admin is not. If you must change something by hand in production, record it so staging can match.

Be careful with plugins that store configuration in the database, such as page builders and form tools. Deploying their templates may need an export and import process, since pushing files does not move the settings.

Test the release on staging with a short checklist: the home page, a post, a form submission, the checkout if there is one, and the admin login. A deploy that passes those checks has handled the most common failure modes. The key habit is that staging should be disposable. If you cannot rebuild it from production in an hour, it has drifted.

The release routine

Whatever method you use, follow the same routine.

1. Announce and freeze. Pause content edits and orders if the release touches the database.
2. Back up production. Database and files, and confirm the backup can be restored.
3. Put the site in maintenance mode if downtime is likely.
4. Deploy the code.
5. Run database updates. Many plugin and core updates need a database upgrade step.
6. Clear caches, at the plugin, server and CDN layers.
7. Test the main flows on the live site.
8. Watch the error log for a while.
9. Keep the rollback ready. Know the exact steps to restore the backup.

Do releases at a quiet time, small and often. A small release has a small blast radius and an obvious culprit if something goes wrong. A quarterly mega-release is the one that ruins a weekend.

Keep WordPress core, themes and plugins updated on the same routine, in staging first. Updates are deployments too, and an unattended automatic update on production is how a site wakes up broken.

Managed hosting and the dashboard route

The fourth option is to let the host handle the infrastructure side. Managed WordPress hosting provides the server, database, certificates, caching and backups, and gives you tools to move files and data without SFTP and database clients.

RunxBuild offers managed WordPress on its own plan ladder, from a free plan and a $3 Starter plan up. Two things help deployments in particular: a file manager in the dashboard to browse, edit, upload, unzip and download files, and a database browser to view tables and rows, run SQL, and export or import. Both remove the need for separate SFTP and phpMyAdmin access. Autoscaling is available for traffic peaks. Root access and arbitrary server software are not, which is the trade.

For a typical release, upload and unzip the changed theme or plugin through the file manager, run any SQL you need in the database browser and export a backup first. The docs for the WordPress file manager and database browser show the screens. For deployments driven from Git, many teams still use their pipeline for code and the dashboard for content and data.

Caching, performance and what to check after a deploy

Caching hides deployment mistakes. After you release, the old version may still appear because of a page cache plugin, a server cache, a CDN or the visitor’s browser. Clear each layer deliberately, and confirm the change on a private window and a different network.

Check performance as well as correctness. A new plugin can add database queries to every page, and a theme change can bring heavy scripts. Compare the load time of the home page before and after, and keep an eye on the error log for notices that did not exist yesterday.

How this fits the rest of the stack

A deployment routine is only as good as the environment it targets, and that environment has a monthly price. Compare WordPress plans and the infrastructure you would otherwise run in the RunxBuild hosting calculator. When you want file and database tools built in, the RunxBuild dashboard is where a managed WordPress site is created.

Useful related references:

• WordPress 6.8.2: What a Maintenance Release Is and How to Handle It
• Squarespace vs WordPress: The Question Behind the Question
• 1 Click WordPress: What the Installer Does, and What It Leaves to You
• Managed WordPress on RunxBuild

FAQ

What is the safest way to deploy a WordPress site?

Keep code in version control, deploy it through an automated pipeline, leave uploads and the database in production, test on a staging copy and always back up production before a release.

Should I overwrite the production database with my local one?

Almost never. Content on the live site changes constantly, so overwriting it loses data. Move code up and copy production data down to staging when you need realistic content.

Why does the site break after changing the domain?

WordPress stores its URL in the database, including inside serialised data. Use WP-CLI search-replace, which handles serialisation, instead of a plain text replacement on a dump.

Do I need a staging site?

For anything beyond a small brochure site, yes. Staging lets you test updates and releases against realistic data without risking visitors or customers.

Is managed WordPress hosting easier to deploy to?

Usually, because the host handles the server, backups and certificates, and often provides file and database tools. You trade away root access and custom server software.