Reviewing Craft Nitro & DevKinsta for WordPress Local Development

By Jonathan Bossenger

One of the cool things about my job as Developer Educator at Delicious Brains is that sometimes I get to try out new things that I might otherwise never discover. Over the past few months, I’ve been testing out two new local development environments: Craft Nitro and DevKinsta.

Craft Nitro

Craft Nitro is a Docker-powered local development environment from the folks behind Craft CMS. If you’ve never heard of Craft CMS, it’s an open-source CMS built on top of the Yii PHP framework, which uses Twig for templating and the Vue JavaScript framework powering the dashboard. Craft CMS (originally called Blocks CMS) was created by Pixel & Tonic, a software development company that built the most popular addons for ExpressionEngine CMS. However, due to some changes EllisLabs (the company behind ExpressionEngine) had made to the CMS, Pixel & Tonic decided to build a competitor.

And you thought WordPress had drama!

The developers behind Craft CMS also decided to build and release their own local development environment, explicitly tailored to Craft CMS developers. It was officially launched in early 2020 and was built on top of Multipass, an application created by Canonical, the folks behind Ubuntu. Multipass provides a virtualization platform similar to Vagrant with Virtual Box or Docker, but is easier to use and set up and uses fewer resources. Unfortunately, at the time, Multipass had a series of bugs that were frustrating users, so they decided to switch to using Docker instead.

That’s a pity because I think Multipass has the potential to be the next big thing in local development environments. It just needs some time to mature as a platform.

Because Craft CMS and WordPress have similar technical requirements, we thought it might be interesting to see if Nitro would work as a drop-in local development environment for WordPress.

Installing And Configuring Craft Nitro

The first thing about Nitro is that it’s pretty technically challenging to set up. Everything is detailed in the installation instructions, but you will need to install Docker yourself first. Depending on what operating system you use, this can vary in difficulty level.

Once you have Docker installed, there are a few alternative installation options, depending on your OS.

If you’re on macOS or Linux, you can run a single terminal command to install Nitro.

bash <(curl -sLS

This downloads and runs the installer script, which downloads and installs the Nitro executable.

jonathan@jonathan-zenbook:~$bash <(curl -sLS

Downloading package to /home/jonathan/temp_nitro_extract/nitro_linux_x86_64.tar.gz

Download complete.

  The script was run as a user who is unable to write
  to /usr/local/bin. To complete the installation the
  following commands may need to be run manually:

  sudo cp ./nitro /usr/local/bin/nitro
  nitro init

Because I am on Linux, I also needed to copy the nitro executable to a specific directory by running sudo cp ./nitro /usr/local/bin/nitro. This allows any normal system user to run the nitro executable.

On macOS, you also have the option to install Nitro via Homebrew. Windows users have a slightly more involved set of install steps, making use of WSL 2, so best to check the install doc.

Then, you run nitro init to initialize the Nitro environment. The process asks you some questions about what specific environment configuration you want and sets everything up.

jonathan@jonathan-zenbook:~$ nitro init
Setting up Nitro…
Would you like to use MySQL [Y/n]? y
Select the version of MySQL
  1. 8.0
  2. 5.7
  3. 5.6
Enter your selection: 1
Would you like to use PostgreSQL [Y/n]? n
Would you like to use Redis [Y/n]? n
Checking Nitro…
  … creating network ✓
  … pulling image ✓
  … creating volume ✓
  … creating proxy ✓
Checking network…
  ✓ network ready
Checking proxy…
  ✓ proxy ready
Checking databases…
  … checking mysql-8.0-3306.database.nitro   … downloading mysql:8.0 ✓
Checking services…
  … checking dynamodb service ✓
  … checking mailhog service ✓
  … checking redis service ✓
Checking proxy…
  … updating proxy ✓
Updating hosts file (you might be prompted for your password)
  … getting Nitro’s root site certificate ✓
Installing certificate (you might be prompted for your password)
Nitro certificates are now trusted &#x1f512;
Nitro is ready! &#x1f680;

Adding or Creating a Nitro Site

Once you have Nitro installed and initialized, you can run the nitro add command inside any website project directory. This will ask you about which hostname you would like to use for the site, as well as which PHP version you want to use. It will also ask if you want to create a database and ask for the database name. Once it has all the data it needs, it will go ahead and configure the site for you.

jonathan@jonathan-zenbook:~$ cd /development/sites/new-site
jonathan@jonathan-zenbook:~$ nitro add
Adding site…
Enter the hostname [new-site.nitro]:
  ✓ setting hostname to new-site.nitro
  ✓ adding site ~/development/websites/new-site
Enter the webroot for the site [web]: /
  ✓ using webroot /
Choose a PHP version:
  1. 8.0
  2. 7.4
  3. 7.3
  4. 7.2
  5. 7.1
  6. 7.0
Enter your selection: 2
  ✓ setting PHP version 7.4
Add a database for the site [Y/n] y
Starting Nitro…
  … starting mysql-8.0-3306.database.nitro ✓
  … starting nitro-proxy ✓
Nitro started &#x1f44d;
Enter the new database name: newsite
  … creating database newsite ✓
Database added &#x1f4aa;
New site added! &#x1f389;
Apply changes now [Y/n]? y
Checking network…
  ✓ network ready
Checking proxy…
  ✓ proxy ready
Checking databases…
  … checking mysql-8.0-3306.database.nitro ✓
Checking services…
  … checking dynamodb service ✓
  … checking mailhog service ✓
  … checking redis service ✓
Checking sites…
  … checking new-site.nitro ✓
  … checking wordpress.nitro ✓
Checking proxy…
  … updating proxy ✓
Updating hosts file (you might be prompted for your password)

As soon as this is done, you can browse to your local URL (in this case, new-site.nitro) and see an Nginx error page, which is expected because the Nginx server doesn’t have anything to display for that site.

You can also use nitro create, requiring you to pass a parameter for the project name. This will create a new Craft CMS project directory and install the Craft CMS code, ready for Craft CMS development. Not ideal for WordPress development, but useful to know.

Nitro automatically includes things like the DynamoDB and Redis services. However, if you don’t need these things, it’s a bit of overkill. Obviously, it’s tailored to Craft CMS development, and I assume Craft CMS developers use those services. I do like the fact that it comes bundled with MailHog, which is a great way to test email sending on a local development environment.

Using Nitro For WordPress Development

I wanted to see if Craft Nitro could work with WordPress, so my next step was to download and extract a copy of the WordPress core files to a local wordpress.test site I had set up with Nitro. I already have WP-CLI installed on my workstation, so I could just run wp core download inside the site directory. If I didn’t have WP-CLI, I’d just download and extract the archive from

Next up, I decided to run the famous 5-minute install. I know I can do this via WP-CLI, but I wanted to see if I could do it the usual way, through the WordPress installer. Unfortunately, that’s where things started to go wrong.

The first problem I encountered was that the default database username and password weren’t documented anywhere I considered logical. That’s probably because most Craft CMS developers will use nitro create, which also sets up the project credentials for you. After some digging, I found the details at the bottom of the Project Setup help doc. I also learned that running nitro context on the command line inside the project directory outputs the database name, username, password, and hostname.

With those details, I clicked through the WordPress installer. I got to the database credentials screen, entered the relevant details, hit Submit, and was presented with a generic WordPress “critical error” message.

WordPress Critical Error

Because the error message didn’t really help me understand what was going wrong, I started digging. I first checked the PHP error log, but nothing was reported. So I tried stepping through the /wp-admin/setup-config.php file using Xdebug and PHPStorm and learned that this file disables PHP error reporting.

 * Disable error reporting
 * Set this to error_reporting( -1 ) for debugging
error_reporting( 0 );

I turned this on, which lead me to discover that Nitro does not enable the PHP mysqli extension by default, which WordPress needs. After some reading through the Nitro docs, I fixed this by running nitro extensions inside the project directory and enabling mysqli.

The error changed this time, and WordPress gave me the Error establishing a database connection error screen. As I had turned on PHP error reporting earlier, I looked in the PHP error log, and saw the following error reported.

php_network_getaddresses: getaddrinfo failed: Name does not resolve

To my limited understanding of how Docker works, this error meant that the Docker instance that powers the site could not resolve the hostname of the Docker instance that powers the database, so WordPress couldn’t connect to the Docker database instance. So I used the nitro ssh command to log into the Nitro Docker instance and pinged the database hostname that Nitro creates. This gave me the IP address of the database instance, which I used in the WordPress setup instead of the hostname, which worked.

So eventually, I have a working WordPress install using Nitro, but it was a bit of a pain to get it installed. I’m not sure if that database IP address will ever change, meaning I’d have to update my wp-config.php if it ever did. I’m also not entirely sure everything else will work as I expect it to, and by the time I managed to get WordPress installed, I was too frustrated to care to find out.

To be honest, I was a little disappointed. Sure, Craft Nitro is made with Craft CMS in mind, but so is Laravel Homestead or Laravel Valet made with Laravel in mind. The difference is you can run WordPress out of the box with either.


On the other end of the Docker-based WordPress local development environment landscape is the newly released DevKinsta, from the folks at Kinsta. If you’ve not heard of Kinsta, they are a managed WordPress host that launched around the same time as Craft CMS. To the best of my knowledge, they were one of the first to build their entire technology stack on top of Google’s Cloud Platform and have quickly become a popular managed WordPress host.

Following in the footsteps of Flywheel’s LocalWP offering, Kinsta released DevKinsta as a way to design, develop, and deploy WordPress sites from your local machine. The goal of tools like LocalWP and DevKinsta is to give you the ability to use the benefits of Docker for local development with WordPress but without all the hassle. DevKinsta is aimed at both those who would develop on or for WordPress and those who would just use it to build WordPress sites for clients, using no-code tools like the Block Editor or Elementor.

Installing And Configuring DevKinsta

Clicking on the download link on the DevKinsta site will present you with links for installers for Ubuntu, Windows, and Mac. I’m guessing that DevKinsta doesn’t anticipate any possible users running non-Debian-based Linux distributions. That, or they’ve done their research, and they know this is not the case. Either way, it was nice to see a Debian install option available about four months after the initial Mac and Windows versions were launched.

When you visit the download page, a “Sign up to download DevKinsta” form appears and asks you to enter your email address to access the download. The actual download links are just below the form, and in my case, I could just ignore the form and click the download link.

DevKinsta Download

Once you run the installer, it handles everything else for you, from downloading and installing Docker to configuring the Docker containers. It does take a little while to get everything set up, so once you kick things off, you can grab your choice of beverage and let the installer do its thing.

One thing to note is that, depending on your internet connection, it can take a long time to download and install everything before you can start building websites. I boiled the kettle, brewed my pour-over, and drank my coffee before it was all finished.

Using DevKinsta For WordPress Development

Being built by a managed WordPress host means that DevKinsta is built for use with WordPress. From the dashboard you can create a new local WordPress site using the defaults DevKinsta provides, download any site from your Kinsta account (if you have one) to use with DevKinsta, or create a custom site, which mostly allows you to customize things like the PHP version or the WordPress version.

DevKinsta Dashboard

Like Nitro, DevKinsta will handle things like mapping a local hostname to your site, so you can browse it in a web browser and map the database instance hostname so that the WordPress site can talk to the database. But, unlike Nitro, this all works perfectly out of the box for WordPress.

I liked the site dashboard. It’s clean but gives you all the site info you need and includes links to open the site locally in a browser, push the site to your Kinsta staging environment, view the database manager (which uses Adminer), or open WP Admin. You also have options to view the local site’s email inbox (I assume this is if the site has sent out emails, and you need to view the contents).

DevKinsta also has some nice touches in the settings that I appreciated, like configuring your local site’s directory, if you don’t want to use the default DevKinsta uses, or setting a default admin username and password for newly created local sites.

My biggest gripe with any of these host-based local environment tools is that they don’t support any other hosting platforms. From a marketing/business point of view, I understand the reason behind making it possible to push a local DevKinsta site to Kinsta hosting. Still, I’d love to see one of these tools make it possible to configure FTP and database details for any other type of hosting. As someone who niched down his freelance WordPress development career in the plugin development space, I rarely was part of the client’s hosting decisions, and so it means I could never use any of these tools.

I probably shouldn’t complain, though, because then we wouldn’t need products like WP Migrate DB Pro, and I might be out of a job!

Final Thoughts

The WordPress local development environment space is interesting. I recently posted a question about this on Twitter and had at least 12 (if not more) options mentioned, including applications that have been around forever, like MAMP and XAMPP.

And I understand why. These applications are tried and tested, don’t rely on any specific hosting platform, and just work.

They do have limitations though, which is why host-based solutions like DevKinsta exist. If you’re not specifically a Flywheel customer, but you use LocalWP and are considering trying out DevKinsta, I recommend it. I’ve used both, and they’re both good, so really, it’s up to personal preference. Of course, if you are a Flywheel customer or a Kinsta customer, then using each host’s local development tool makes complete sense. I’m just not convinced someone would switch hosting based on the local development tool they offer.

As for Craft Nitro, I can’t say I’d recommend it as a WordPress local development solution. I do like some of the things it offers, but It’s too tied to the Craft CMS.

What is your preferred local WordPress development environment? Do you use some modern Docker solution or rely on tried and tested apps like MAMP? Let us know in the comments.

About the Author

Jonathan Bossenger

Jonathan is an open-source enthusiast, developer, and writer from Cape Town, South Africa. He enjoys learning about new web technologies and sharing that knowledge with others. Prone to drinking too much coffee!