WordPress hosting with staging for developers

Why use staging before you change a live site?

WordPress sites change all the time. WordPress itself, plugins and themes release updates, and site owners add features, forms and integrations. Most changes go smoothly, but the ones that do not tend to fail in front of visitors: a white screen after a plugin update, a broken checkout, or a layout that falls apart on mobile.

A WordPress staging site is a private copy of your live site on the same hosting platform. You make the change there, check it, and only then apply it to the live site. Good staging gives you:

• A faithful copy of the live site, on the same server software and PHP version
• Easy creation, so making a fresh copy takes a click rather than an afternoon
• Control over what goes live, so you can push code without overwriting new orders or comments
• A safety net, with a backup taken before every push so you can roll back
• Separate access, so developers and contractors can work on staging without touching live

For agencies and in-house developers, staging is the centre of a wider workflow that runs from local development through version control to live. The rest of this page covers each part, and how the three hosts provide it.

Staging at each host

Staging is now common on managed WordPress hosting, but how many copies you get, and which plans include them, varies:

A few limits are worth knowing. Krystal notes that staging sites do not count towards your site limit, but clones do, and both use disk space. WP Engine's three environments give you room for a separate development copy as well as staging.

Update-testing tools try plugin and theme updates on a copy first, so routine updates do not need a developer each time. Cloudways says its Site Manager Pro add-on tests updates on a staging clone, and WP Engine's Smart Plugin Manager runs visual regression testing on updates.

Pushing changes to live: whole site, files or database

The hardest part of staging is the database. While you work on staging, the live site keeps changing: new orders, form entries, comments and user sign-ups all land in the live database. Pushing the whole staging database back would overwrite them.

That is why selective push, the ability to choose exactly what moves from staging to live, matters. This is how the hosts describe it:

• Cloudways describes one-click push and pull between staging and live
• Krystal Manual merge: tick the files you want to publish, then the database tables. Krystal advises leaving the WooCommerce tables, or the users table, unticked where live data must be kept
• WP Engine Custom copy: choose files, all database tables or selected tables, from the current environment or a backup point

Two pieces of advice come up again and again in the hosts' own guides: push at quiet times, and take a backup just before you push. WP Engine warns that pushing the whole database to production "can cause the live website to lose important data like new orders", and Krystal says "If you are merging to an e-commerce site, you should always select manual merge". For shops and membership sites, a files-only push is the safe default for code changes. Our WooCommerce hosting guide covers shops in more detail.

Developer access: SSH, SFTP, WP-CLI and Git

Good WordPress hosting for developers gives you the command line and version control as well as a dashboard:

Git deployment works in two broad ways. In a pull model, you connect to the server over SSH and pull from your repository, by hand, with a deployment script or from a pipeline; Cloudways pre-installs Git on its servers, which suits this approach. In a push model, you send code from your own repository to the host: on WP Engine, GitPush lets you push from a local repository to a production, staging or development environment, and WP Engine publishes a GitHub Actions tutorial for continuous deployment.

A common pattern is to keep themes and custom plugins in Git, deploy them to staging from your pipeline, test there, then push files to live.

Local development tools

Building on your own computer is quicker than editing on a server, and keeps unfinished work away from everyone else. WP Engine publishes its own local tool, Local:

• Runs anywhere: Local runs WordPress on Mac, Windows and Linux, and sets up a site, with SSL, in one click
• Developer features: Local lists root SSH access, WP-CLI and "the ability to hot-swap PHP environments", so you can test a site on another PHP version before you switch it on the host
• Local Connect: pushes and pulls sites to and from WP Engine, which saves exporting and importing by hand

You can use any local tool with any host, by moving files with SFTP or Git and the database with WP-CLI or a migration plugin. A host's own tool simply saves steps. Pushing from local to staging, rather than straight to live, keeps a checking step before anything reaches visitors. For a local network of sites, see WordPress Multisite hosting.

PHP versions and APIs

PHP versions. WordPress runs on PHP, and each host decides which versions it offers. Cloudways lists PHP 7.4 to 8.4 on its WordPress hosting page; Krystal lets you choose a site's PHP version in its dashboard; and WP Engine lists its supported versions in its PHP guide and says it upgrades sites automatically when a version reaches end of life. Whichever host you use, switch staging first, test the site, then switch live.

APIs. An API lets you script routine hosting work instead of clicking through a dashboard:

• Cloudways describes its Platform API for managing apps, servers, add-ons and services
• WP Engine lists API tasks including managing account users, sites, environments and domains, creating backups, purging cache and managing SSH keys

For agencies and development teams, an API makes it possible to build a new site from a template, push a tested release or clear caches after a deployment as part of a script. Read Cloudways' API documentation (opens in a new tab) or WP Engine's developer page (opens in a new tab) for the full lists.

A safe change workflow from local to live

Here is a workflow that works on any of these hosts, using whichever tools each provides:

If something goes wrong, roll back from the backup taken at step 6. For sites where routine plugin and theme updates should run without a developer each time, look at the update-testing add-ons described above. Our guide to managed WordPress hosting explains what else a managed host takes off your plate.

Next step: compare developer tools on the hosts' own sites

Before you compare hosts, note what your workflow needs:

• How many environments: one staging copy, or separate development and client-approval copies
• What you push: whole sites, files only, or chosen database tables
• Command line and Git: SSH, WP-CLI, Git pull or push, and CI/CD
• Local tools and APIs: whether a host's own tools would cut out steps
• Team access: who should reach staging only, and who can push to live

Then read each host's own pages: Cloudways (opens in a new tab), Krystal (opens in a new tab) and WP Engine (opens in a new tab). Plans, limits and prices are on the provider's own site. For agency workflows, see WordPress agency hosting, and for WP Engine in more depth, our WP Engine guide.