I’ve used a variety of local development environments over the years and some of them have done a decent job – but none of them have been the one. Back in January when I first saw DevKinsta announced over on WP Tavern I was excited to give it a try. I’ve finally tried it and wanted to share some thoughts and feedback on DevKinsta.

Installation (on Windows)

DevKinsta uses Docker to containerize the various services DevKinsta launches. Docker utilizes Windows Subsystem for Linux 2 (WSL2) under the hood which is part of the Windows Operating System. You’ll need to install it and Docker if you haven’t already.

The official documentation suggests you need to have Hyper-V and Containers enabled in Windows Features (Settings–>Control Panel–>Programs and Fetaures–>Turn Windows features on or off) but I have neither enabled on my system. All I have installed on my system is the Virtual Machine Platform and Windows Subsystem for Linux.

Once you have WSL2 and Docker installed and enabled you can actually install Kinsta. The Kinsta portion is straightforward.

Kinsta installs itself in Users\{user}\AppData\Local\Programs\DevKinsta which still seems a bit weird to me. But I’ve seen other apps doing this as well. I’m not a huge fan of having so many places to look for installation applications (above, Program Files, Program Files (x86), AppData\Roaming, etc.) but I’m guessing this is the new and Microsoft sanctioned way of doing things?

Once the install is complete you see the completed screen and can run DevKinsta. Woohoo!

Running DevKinsta for the First Time

The first time you launch DevKinsta it will take a while to launch (I’m guessing at least several minutes for most folks). This is because DevKinsta is downloading the images it uses with Docker…and I do mean images plural: devkinsta_fpm, devkinsta_db, devkinsta_nginx, devkinsta_mailhog, and devkinsta_adminer (that’s five images if you weren’t counting).

After this first time things move much more quickly. The normal loading screen you’ll see is gone in a flash. I expect there will still be occasional slowish starts as Kinsta makes changes to the underlying images and these changes need to be applied to the containers running on each of our local systems.

Creating a New Site

Once DevKinsta is loaded you are provided with a slick UI and three big options: New WordPress site, Import from Kinsta, and Custom site.

Adding a new site is extremely simple. Give the site a name and provide a username and password and Kinsta takes care of the rest.

Note that Kinsta is making all the decisions for you if you take this route. If you need to customize your install you’ll use the Custom Install option. Using this option you can choose a PHP version, enable HTTPS, select a specific WordPress version, create a Multisite and so on. Still pretty simple and straightforward.

The Docker Warning

At some point you’ll be warned by Docker that Docker has detected Windows files being shared into a WSL 2 container and that this may result in poor performance.

Lets break that down a little. Windows Subsystem for Linux 2 is a Windows component that provides a light Linux installation. Docker uses WSL 2 when creating containers. If you mount files from your Windows filesystem to the container (which is utilizing WSL 2) the speeds deteriorate. You really want to have your files mounted inside of the container.

I usually spin up containers from within WSL to avoid this problem but Kinsta didn’t. Why not? Because Kinsta wants you to be able to browse and edit those files in your native Windows filesystem and when they are inside the container they are available on the Linux filesystem and not the Windows filesystem.

Now technically that isn’t entirely true. You can setup a network share from which you can access files within your Linux container, but that all is a bit messy. Maybe someday they’ll add an option that allows you to have the files reside in the container rather than on the Windows side and we’ll see some performance boost, but I understand why they did it this way.

The Individual Site Dashboard

Once the setup of your new site is complete you get a nice dashboard that allows you to manage your site.

You can see the features yourself so let me just point out a few of the highlights:

• You can quickly open the site frontend or backend (WP Admin).
• The Database Manager (Adminer) is easily accessible.
• The site host provides the URL and the site path provides the file system location of your site.
• You can toggle SSL/HTTPS on.
• Information about the database is clearly presented allowing for easy remote access.
• You can easily toggle WP_DEBUG on and off.

There is one glaring omission – there is no one click access to the terminal. Instead you’ll need to whip out some command-line expertise – or read the DevKinsta documentation.

Settings

The Settings are rather sparse – two that I think deserve attention here. First there is the option to enter a site path – this is the local filesystem location for projects. This isn’t for a specific project but for all projects overall.

The second is configuring what you want the default username and password to be for WordPress installs. It’s a minor convenience but still nice.

Visual Studio Code Dilemma

VSC has this killer extension (err extensions) that allow one to work on remote (or virtual) systems as if they were local. Unfortunately, when you attempt to connect the kinsta_fpm container to VSC you are dropped in the root directory and the Kinsta files are nowhere to be found.

You can break out by using File–>Open Folder and navigating to /www/kinsta/public/some-site but it isn’t ideal. I’d love to see a tighter VSC integration.

How Does It Compare to Local?

Overall I’d say it compares pretty favorably to Local. Personally, I don’t like having my dev servers installed on my local host, I want them virtualized or containerized. This reduces the surface area open for attack on my local machine and helps avoid munging of my system which happens on occasion by even the best intentioned software.

How Does It Compare to VVV?

DevKinsta is simple to use and its reliance on Docker rather than Vagrant/VirtualBox is attractive to me. However, VVV still comes with more tools – PHPUnit, Xdebug, Composer, NodeJS, git, and Subversion being the most notable in my opinion.

I’d love to see these tools included with DevKinsta as well…NodeJS especially needs to be there for folks to do Gutenberg development.

Summarize/Expand on Missing

I like a lot about DevKinsta but there are some features that are missing of varying importance. I’m going to summarize up those I’ve already listed as well as add a few more below.

• High Priority
  • Addition of button on Site Info to launch shell.
  • Addition of NodeJS.
  • Addition of PHPUnit, xdebug, and Composer.
  • Addition of git and subversion.
  • Be open source.
• Medium Priority
  • Addition of Apache as a web server option.
  • Better integration with Visual Studio Code.
  • Provide the option to use the GUI to manage wp-env.
• Low Priority
  • Provide option to use WSL 2 filesystem rather than native Windows filesystem to improve performance.
• Low Low Priority
  • I’d like to see more logging detail on what DevKinsta is doing while updating my Docker containers. Not because I actually need to know but it soothes me to see the logging scrolling past indicating that no, this software has not frozen.
  • I’d like to see more logging detail in general without having to dig for logs.

Conclusion

DevKinsta is a solid option for a local dev environment. I’d like to see them open source it and think this would facilitate faster innovation. The lack of Gutenberg support built-in and the lack of native tooling is a big bummer for me. I’m leaning towards using wp-env at least for the moment.

Your thoughts?