Utilizing DevOps and Kinsta’s staging environments for WordPress site development

Using Kinsta's staging environments to develop sites

If you picture a Venn diagram, Kinsta’s staging environments would converge with both developing for WordPress and your chosen DevOps Lifecycle. They can be a part of your workflow from the initial planning, right up to your operations phase. This includes working locally with WordPress, utilizing version control, and almost every other task you have during a cycle.

For this article, we’re going to look at developing sites alongside Kinsta’s staging environments. Throughout, we’ll link this to a typical DevOps Lifecycle. There’s a lot to get through, so let’s begin with why we think you should use the staging environments Kinsta offers.

The benefits of using Kinsta’s staging environments

Kinsta’s staging gives you versatility and flexibility when it comes to developing websites and testing them. These environments let you build in a setting that mirrors your live environment. Given that your live server will be on Kinsta, too, it’s a reliable and accurate testing ground to work from.

Of course, you can create, manage, clone, and delete staging environments through the MyKinsta dashboard:

The MyKinsta dashboard showing the 'Site Information' section with the 'Push to Live' button highlighted. There are also options to open the WordPress dashboard from MyKinsta or visit the front end of the site.
The MyKinsta dashboard.

If you need more flexibility, the premium staging environment add-on gives you an extra five environments. In addition, you’ll benefit from our robust infrastructure, which includes Google’s Premium Tier Network and Cloudflare integration.

As you’d expect, this also comes with more power under the hood. Depending on your plan, you get up to 12 CPUs and 8GB of memory, a matched PHP worker count relative to your live site, and the option to enable Kinsta CDN for enhanced performance. It’s a setup that suits a range of tasks, such as A/B testing, plugin compatibility checks, resource-intensive tests, and much more.

For local development, DevKinsta complements the whole experience. Once you get out of your initial phases, you can push your site straight to Kinsta’s staging environments.

The DevKinsta application startup screen with a large 'K' logo, stylized hand gestures, and chat icons. The text reads 'Starting Docker...' indicating the initialization of the local development environment.
The splash screen for DevKinsta.

On the whole, you can create, build, design, test, and debug all within Kinsta’s ecosystem. What’s more, it’s suited to your DevOps Lifecycle too. We’ll discuss this in more detail soon. However, let’s first offer some extra information about Kinsta’s staging environments.

Some incidentals about Kinsta’s staging

Kinsta’s staging environments are excellent when it comes to testing a site on a live – albeit non-production – server. However, there are some differences between staging and live on Kinsta that you’ll want to be aware of:

  • First, we disable both full page caching and OPcache by default. You can enable this if you wish, but without it, you’ll likely see higher page loading times.
  • In the same way, site indexing is also disabled within WordPress. While you can re-enable this if you need to, one aspect you can’t turn off is our temporary URL indexing restrictive headers.
  • Cron jobs also won’t run while in staging, although they are still ‘in place.’ This means you can make changes to them, which will replace the cron jobs on your live site once you push live. While in staging, though, they won’t fire.
  • Also, note that your WordPress login credentials will be the same for your staging site as they are for your live one.

There’s one more aspect we want to focus on quickly before we move on to workflow: how plugins interact with staging.

Using plugins in Kinsta’s staging environments

Kinsta already bans some plugins from installation in WordPress for security and performance reasons. However, when it comes to staging, you will also want to disable some of your site’s plugins.

There are three situations you’ll want to consider this:

  • If your plugin license is linked to your domain name, it may not work in your staging environment.
  • Plugins such as Jetpack will switch to a staging mode on an automatic basis. You may not see any difference, although none of the data you process will go to WordPress.com. Also, you won’t be able to disable Jetpack on staging.
  • Some plugins connect and post to social media, such as CoSchedule. In these instances, we recommend you turn them off until you push to live. This is because they can schedule and post URLs from your staging environment.

We have further information on this (and a lot more) in our documentation. It’s essential reading if you want to use Kinsta’s staging environments yet minimize any effects relating to your plugins and themes.