A Kinsta staging site is a working copy of your live WordPress site that runs on its own server environment, so you can test plugin updates, theme changes, PHP version bumps, or a full redesign without any risk to the real site. When the changes check out, you push them back to live in a single step. This guide covers both staging types Kinsta offers, how to create one in MyKinsta, how to work on it safely, and how to push changes in either direction without wiping out live data.
What a Kinsta Staging Site Is
Every site hosted at Kinsta can run its own staging environments. Each one is a separate copy with its own temporary address on the kinsta.cloud domain, its own SSL certificate, and its own SSH, SFTP, WP-CLI, and database access. Nothing you do on staging touches the live site until you deliberately push it across. It is also where a free Kinsta migration lands before the DNS cutover, so if you are moving a site in first, the how to migrate WordPress to Kinsta guide walks through that path and this guide picks up once the site is on the platform.
Staging sites are blocked from search engines by default. The kinsta.cloud address carries robots headers that cannot be removed, so Google never indexes your sandbox and you will not create duplicate content by testing on it.
Standard vs Premium Staging: Choose Before You Create
Kinsta gives you two kinds of staging environment, and the right one depends on what you are testing. You can run up to six environments at once on a single site, one live plus five staging.
- Standard staging. Included on most plans at no extra cost, up to five per site. It runs on reduced resources (one CPU, two PHP threads, 8 GB of RAM) with no CDN or edge cache, and it goes to sleep after 24 hours of inactivity, waking on the next request. Right for quick plugin tests, theme tweaks, and update rehearsals.
- Premium staging. A paid add-on, billed hourly so you only pay while it runs (currently around $20 a month per environment). It matches live for CPU and memory, keeps the CDN and edge cache on, and never sleeps. Right for load testing, client demos, long-running builds, or anything that has to behave exactly like production.
If you are not sure whether the Premium add-on earns its cost on your plan, the Kinsta hosting guide breaks down what each tier includes.
How to Create the Staging Environment
Creating a staging environment takes a couple of minutes inside MyKinsta, the dashboard that replaces cPanel on Kinsta.
- In MyKinsta, open Sites in the left navigation and select the site you want a copy of.
- Click the environment selector next to the site name (it reads Live), then choose Create new environment. The Jump to or search box does the same thing.
- Pick Standard or Premium, then click Continue.
- Choose how to fill the new environment:
- Clone an existing environment copies your live site into staging. This is the usual choice when you want to test real changes against real content.
- Install new WordPress gives you a blank install with its own title, admin user, and password, for building something from scratch.
- Empty environment provisions the web server, PHP, and MySQL with no WordPress, for a Bedrock setup or a Duplicator import.
- Kinsta provisions the environment in a few minutes on a sitename.kinsta.cloud address with its own SSL. You can log straight into its wp-admin from MyKinsta.
Working on Staging
Once the environment is live you treat it like any other WordPress site. Make your changes through wp-admin, or connect over SSH, SFTP, or WP-CLI using the staging-specific credentials in MyKinsta. The staging database is separate too, so a bad query or a plugin that corrupts a table affects only the copy.
Two behaviours catch people out. Standard staging sleeps after 24 hours of inactivity, so the first request after a quiet spell is slow while it wakes, and a long test session may want Premium instead. Server-level cron also does not fire on staging the way it does on live, so scheduled jobs such as the WooCommerce action scheduler or backup plugins will not run on their own. Do not test cron-dependent behaviour on standard staging and expect it to match production.
How to Push Staging to Live
When the changes pass testing, you push the environment back to live. Click the environment selector, choose the staging environment, and click Push Staging to Live. Kinsta then offers two ways to do it.
- Full push. Overwrites the live files and the live database completely with the staging copy. It is fast, and it is the right call when nothing of value has changed on live since you cloned.
- Selective push. Lets you push files only, database only, or both, and exclude specific folders or tables. This is how you ship a theme or plugin change (files only) while leaving the live database untouched.
Here is the trap that costs people real data: a full database push overwrites every row that changed on live since you created the staging copy. New comments, new orders, new signups, and form entries recorded on the live site while you were working are all replaced by the older staging database. On a busy store or membership site, a full push can erase a day of genuine customer activity. If the live site takes any input at all, push files only, or use selective push and exclude the tables that collect live data. Kinsta runs the domain search-and-replace automatically on a standard push, so your links and serialized settings point at the live domain afterward. Domain-mapped multisite is the exception and needs a manual search-and-replace pass.
How to Push Live to Staging
Push runs the other direction too. Refreshing a stale staging environment with current live data is the way to start a new round of work from a clean, up-to-date copy, and it is also how you load live content into a Premium environment for a client review. Selective push applies here as well, so you can pull the live database into staging without overwriting code you are still building there. Remember that this direction overwrites staging, so anything you have not pushed to live yet can be lost if you run a full push the wrong way.
Common Problems and Fixes
- Staging is slow or returns a 502 on the first hit. Standard staging slept after 24 hours idle and is waking up. Retry after a moment, or move to Premium for an always-on environment.
- Scheduled tasks never ran on staging. Server cron is off on staging by design. Test cron-dependent features on live or on a Premium environment with cron enabled.
- Test emails reached real customers. Deactivate transactional email and social-scheduling plugins on staging before you work, so test orders and draft posts do not email buyers or post to social accounts with a kinsta.cloud link.
- Staging work disappeared after a push. A live-to-staging push overwrote it. Use selective push to protect code or content you still need on the staging side.
- A custom domain added to staging vanished. Custom domains on a staging environment are removed when that environment is deleted. Restore from a backup instead of deleting if you need the domain back.
Staging is one piece of the setup workflow on Kinsta, and it sits alongside migrations, DNS, and post-launch checks in the Kinsta setup and migration guide. Ready to try it yourself? Start a site on Kinsta and create your first staging environment from MyKinsta in a few minutes.
