What DevKinsta is and what it includes
Kinsta describes DevKinsta as a local development suite for WordPress. It installs the required components in the background on Windows, Mac or Linux. The documented stack is Docker, Nginx, MySQL, PHP and WordPress, with a database manager (Adminer) and a per-site email inbox. A Kinsta hosting plan is not required to use it locally, but it connects to MyKinsta when you want to move a site to or from Kinsta.
Two of those components matter for course sites. Adminer lets you inspect and edit the local database directly, which is useful for removing personal data after a pull. The email inbox, which Kinsta says runs MailHog behind the scenes, catches outgoing email sent through PHP's mail() function, so password resets and enrollment emails triggered on the local copy land in a local inbox instead of a student's mailbox.
Pull and push: what moves where
Both directions ask you to sign in to MyKinsta inside DevKinsta's settings, with two-factor authentication if it is enabled on your account.
| Action | Allowed environments | Choices | Who can do it |
|---|---|---|---|
| Pull from Kinsta to DevKinsta | Live, Standard Staging or Premium Staging | Selected files, database only, or both | Company Owners, Administrators, Developers, and Site Developers with access to the site |
| Push from DevKinsta to Kinsta | Standard or Premium Staging only; never directly to live | Selected files, database only, or both | Users with access to the selected site |
| Push staging to live in MyKinsta | Staging to live | All or specific files and folders; all or specific database tables | MyKinsta users with access |
What a push overwrites
Kinsta's DevKinsta documentation says a push overwrites the selected files, and the database if the database is selected. It changes the site URL from the local address to the staging environment's primary domain, and when the database is pushed every WordPress user in the local copy goes with it. A push does not change the MySQL password, MyKinsta redirects or the PHP version.
The staging-to-live push is where live data is at risk. Kinsta says that pushing the database replaces live data, so any comments, orders or sign-ups on live since the staging copy was made are lost. MyKinsta does not separate new WooCommerce orders from old ones. Its suggested ways around this are to push files only, exclude the order tables, or sync live to staging before pushing.
Kinsta does take a backup of the target environment before a staging-to-live push, so you can roll back. It also warns that on a dynamic site, data created between the push and a rollback can be lost, that the live site has a couple of seconds of downtime at the end of a push, and that password protection and higher Bot Protection levels do not transfer and must be re-enabled on live. Environment settings such as redirects, PHP and Nginx settings are always pushed, even in a selective push.
Student data on a local copy
Pulling the database from live copies every student account, email address, enrollment, quiz attempt, certificate record and order onto your computer. Treat the laptop as holding production data: full-disk encryption on, no shared user accounts, and delete the local site when the work is finished.
Often you do not need the live database at all. For theme, template or plugin-settings work, pull files only, or pull from a staging environment whose database has been cleaned. If you do need realistic data, pull once, then in Adminer or with WP-CLI replace student emails with test addresses and delete orders you do not need before you start working.
Remember what the inbox does not catch. Kinsta documents that DevKinsta catches email sent through PHP mail(). If the site uses an SMTP or email-API plugin, that plugin may still deliver real messages to real students from the local copy. Deactivate it locally before you trigger anything that sends email, such as course completion, drip releases or renewal reminders.
Payment keys on a local copy
A pulled database usually includes the payment plugin's settings, which can include live API keys. Stripe's documentation is clear about the difference: sandbox keys start with pk_test_, rk_test_ and sk_test_, and in a sandbox card networks do not process payments; live keys start with pk_live_, rk_live_ and sk_live_, and live mode processes real payments.
If a local copy keeps live keys, any action that calls Stripe from that copy uses your live account, including a scheduled renewal or retry if the scheduler runs locally. Right after a pull, switch the payment plugin to test mode with sandbox keys, or remove the keys, before you browse the site. Stripe also advises against putting secret keys in source code or configuration files checked into version control, so do not commit a wp-config.php or .env file that contains them.
Webhook signing secrets are separate from API keys and are set per endpoint in Stripe. Your live endpoint keeps pointing at the live domain, so a local copy will not receive live webhooks, but a local copy also cannot prove that webhooks work. Test those on staging with a sandbox endpoint.
A safe sequence for a course-site change
- Pull files only, or files plus a staging database, unless you truly need live data.
- If you pulled live data, scrub student emails and switch payments to sandbox keys before anything else.
- Deactivate SMTP or email-API plugins locally.
- Make and test the change locally.
- Push files to staging. Push the database only if the change lives in the database, and know that it carries your local users with it.
- Re-test on staging with sandbox payments: enroll, take a quiz, finish a lesson, check out.
- Push staging to live in MyKinsta with specific files and folders. Push specific tables only if you must, and never the user, order, enrollment or progress tables.
- Re-enable password protection or Bot Protection on live if you used them, and check the live site immediately.
Who it fits and who should skip it
DevKinsta fits a course creator or developer already on Kinsta who changes themes, templates or plugin settings and wants a local copy that moves cleanly through staging. The enforced route through staging is a useful safety rail for a site with paying students.
Skip it, or use it for files only, if most of your content changes happen in the WordPress editor on live, or if your site's value is in data that changes every hour, such as orders, enrollments and progress. For those sites, the hard part is not making the change locally but getting it to live without overwriting what students did in the meantime.
Questions before you decide
Can DevKinsta push directly to my live site?
No. Kinsta's documentation says you cannot push to a live site directly from DevKinsta. You push to Standard or Premium Staging, then push staging to live in MyKinsta, where you can choose specific files and tables.
Will emails sent from DevKinsta reach real students?
Email sent through PHP mail() is caught by DevKinsta's local inbox. An SMTP or email-API plugin may still deliver real messages, so deactivate it on the local copy before triggering emails.
Does pushing the database from DevKinsta overwrite users?
Yes. When the database is selected, Kinsta says the push overwrites the staging database and pushes every WordPress user in the local copy. Pushing that to live would replace live users and orders made since.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Kinsta: DevKinsta documentation Accessed 30 Oct 2026
- Kinsta: DevKinsta Kinsta integration (pull and push) Accessed 30 Oct 2026
- Kinsta: DevKinsta email inbox Accessed 30 Oct 2026
- Kinsta: DevKinsta database manager Accessed 30 Oct 2026
- Kinsta: Push environments (staging to live) Accessed 30 Oct 2026
- Stripe: API keys Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.