Who includes staging, from the vendors' own documentation
| Host | Staging included | Extra staging | Notes |
|---|---|---|---|
| Kinsta | Each WordPress install can have its own free standard staging environment | Premium staging add-on; up to 5; Kinsta's proration example prices one month at $20 | Custom plans may restrict the number of staging environments |
| WP Engine | Each site can have up to three environments: Production, Staging and Development | Not covered here | On shared plans only Production can have a live custom domain |
| SiteGround | Staging is available on GrowBig and GoGeek hosting accounts for WordPress sites | Not covered here | Full Deploy requires a database under 2GB and more than 51% free account space |
What push-to-live actually copies at each host
Kinsta's push documentation offers all files and folders or specific files and folders, and all database tables or specific database tables. It recommends selecting Run Search and Replace for database pushes, and says that before the push it creates a backup of the target environment so you can roll back. It also warns that pushing to a live site causes a couple of seconds of downtime at the final stage.
WP Engine's Copy Environment tool offers Full, which includes all files and all database tables, or Custom, where you choose whether to include the file system or the database and can select which tables to copy. Selected tables that exist in the destination are overwritten. WP Engine states that the destination is backed up before and after the copy.
SiteGround's Full Deploy, in its own words, overwrites your staging copy over your live site with a single click. Custom Deploy compares all changes made to the files and database of the staging copy so you can choose what goes live. SiteGround also notes the staging WordPress version must not be lower than live.
The danger: a staging database pushed over live orders and progress
Kinsta's staging documentation states that any changes to the live site's database since the staging site was created will be lost, and lists comments, new content, ecommerce purchases, membership sign-ups and forum posts as examples. WP Engine states it does not recommend pushing the entire database to production, because the production database is completely overwritten and the live site can lose data such as new orders or new users. SiteGround's example is the comments table you would not want to overwrite.
On a course site the losses are concrete. LearnDash stores enrolments, lesson completions and quiz attempts in the database. MemberPress stores members, transactions and subscription records there. A staging copy made on Monday and pushed on Friday rolls every student's progress back to Monday and erases every sale and renewal recorded in between, while your payment processor still holds the real charges.
The backups Kinsta and WP Engine take before a push are a rollback, not a merge. Kinsta notes that on dynamic sites, data created between the push and a rollback may be lost. Restoring the pre-push backup brings back Friday's orders but also discards anything recorded after the push.
A safer push procedure for course and membership sites
- Push files only for theme, plugin and code changes. Kinsta's selective push and WP Engine's Custom copy both allow a file-only push; SiteGround's Custom Deploy lets you leave database changes out.
- Make settings changes on live, in a quiet window, rather than pushing settings tables. Record them in a change log first on staging.
- If a table must be pushed, push only that table, and only if it holds no customer, order, enrolment or progress data. Confirm what each table holds before selecting it.
- Refresh staging from live immediately before testing so the comparison is against current data, then freeze content edits on staging.
- After pushing, place one test purchase and one lesson completion with a test account, and compare live order and enrolment counts before and after.
- Keep the payment gateway on staging in test mode; a staging copy with live keys can trigger real renewals. Our WooCommerce staging renewal checklist covers that case.
Picking a host for staging-heavy work
If you change the site often and want per-table control, Kinsta and WP Engine both document table-level selection and automatic backups around a push. SiteGround documents Custom Deploy with a change comparison, but it requires a GrowBig or GoGeek account and has database size and free-space prerequisites that a large LearnDash activity table can hit. Whichever host you use, the safe default for a site that takes payments is the same: code moves forward from staging, customer data never moves backward from staging.
Questions before you decide
Is it ever safe to push a full database from staging?
Only if the live site accepted no orders, sign-ups, renewals or lesson activity since the staging copy was made, for example during a maintenance freeze. All three hosts document that the live database is overwritten.
Does the automatic backup before a push protect me?
It lets you roll back the push, but rolling back discards anything recorded after the push. It is not a way to merge live and staging data.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Kinsta: Staging environment Accessed 13 Oct 2026
- Kinsta: Push environments Accessed 13 Oct 2026
- WP Engine: Copy environments via push or pull Accessed 13 Oct 2026
- WP Engine: Manage sites and environments Accessed 13 Oct 2026
- SiteGround: Staging tool Accessed 13 Oct 2026
- SiteGround: Full and custom deploy Accessed 13 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.