DDEV, Docksal, and Lando: A Comparison

Over the past year or so, I've been looking to replace my standard local development environment with a Docker-based solution. I've been evaluating DDEV, Docksal, and Lando (listed alphabetically), trying to figure out not only was the best for me, but also the best for me to teach and recommend to the hundreds of folks I teach both long-form and full-day Drupal workshops to each year. As I've test-driven each of these three options, I've been periodically posting tutorials on various related topics.

As a long-time Mac OS X user, my previous go-to local development stack has been a mix of MAMP Pro and Acquia Dev Desktop. For teaching, I've mainly been recommending Acquia Dev Desktop, but I think the time has come for a more flexible and professional-level solution. The ability to customize each project's development environment with various versions of PHP, different database and search index servers (adding a Solr server to any of the options in this article is just plain easy), and other things is too big of an opportunity to let pass.

My evaluation of DDEV, Docksal, and Lando has not be quick. I've been using Docksal for several client projects for well over a year now. In fact, during the initial Mastering Professional Drupal Development Workflows with Pantheon course, I recommended it to all of our students. I've even written and shared a somewhat Pantheon-flavored version of a Docksal configuration. It includes custom scripts for automatically downloading and importing a copy of a remote Pantheon database to the local environment as well as running some initial Drush commands after the import is complete.

As the Lando project matured, I was attracted to it mainly for its recipe-based configuration, including a Pantheon-flavored recipe that outdid my custom Docksal scripts. Currently, I'm using Lando for about 5 different client projects (as well as my local development environment for DrupalEasy.com).

Finally, a few months ago, I saw down with a few folks from the DDEV project at BADCamp for an extended walkthrough. It took me another month or two before I really dove into it, using it for a new client project, but at this point (spoiler alert), I'm leaning towards it being my go-to local development environment for teaching.

Comparison

What follows below is just a summary of the various features that I've focused on while test-driving each option. By no means it is a comprehensive list of features, but I think it is safe to say that these are what are most important in my use cases. As I mentioned above, my needs are twofold: a solid local development environment for client work, and an easy-to-install-and-configure local development environment for my students on both Windows and Mac OS X. I imagine that most folks don't have the latter requirement, so be sure to select the best environment for your needs.

In no particular order, here's what I focused on:

User interface

All three options are only command-line driven at this point; none have a graphical user interface (yet). All three options provide a command-line tool with different (but similar) commands. For example:

  • To start a project's containers: lando start, fin start, ddev start ("fin" is Docksal's command-line tool)

  • To stop a project's containers: lando stop, fin stop, ddev stop

As Lando evolved from Kalabox, there is talk that a GUI may be part of a paid add-on in the future. The DDEV team has also made it known that a GUI is in currently being developed.

Hard drive space

As all three options are Docker-based; each project on your local has its own set of containers. I've found that for a typical project, these containers require (I think) around 500(ish)MB of hard drive space (not including your project's data). Obviously, this can add up quickly depending on the number of projects you have on your local. I've found that DDEV has an advantage in this area, as it stores your project's data (database, files directory) in a directory shared with the host operating system - so you can remove a project's containers without losing your site's data (database) - thus saving hard drive space. For someone like me who creates a lot of sites (for teaching), this is non-trivial. DDEV's "ddev remove" command that removes only the containers. If you want to remove a project's data as well, "ddev remove --remove-data" does the trick. Both Lando and Docksal have commands to remove a project's containers and data as well, but neither (currently) has an option to preserve data.

As someone who had zero knowledge/experience with Docker at the beginning of this process, estimating how much hard drive space this stuff takes up is a bit of a black art. The "500(ish)MB" number I mentioned in the previous paragraph isn't anything more than an estimate as I watch my available hard drive space grow and shrink as I create and remove sites. I would love to have easy-to-use commands (for someone that isn't familiar with Docker) showing how much space is being used, options for clearing Docker caches, and anything else that could help developers manage hard drive space.

Drush and Drupal Console support

DDEV, Docksal, and Lando's command line tool provide a command to run Drush commands: fin drush , lando drush , ddev exec .

Pantheon and other remote host support

I tend to use Pantheon quite a bit, both for clients and teaching. The ability to easily get a local environment's database up-to-date from a remote environment quickly is a huge time-saver (and solid development practice). Having integration with Pantheon (and hopefully other hosts in the future) is an important factor for me.

  • DDEV's Pantheon integration isn't as complete, but it does have the valuable "pull" command which will bring down the database and files directory. I really wish it had separate commands for pulling the database and files directory. Often, it only makes sense to only pull the database, and then use something like Stage File Proxy for local files.

  • Docksal lags behind in this area - it don't provide any built-in tools for interacting with remote hosts, but they do provide useful examples for creating your own custom commands.

  • Lando has the edge here, with its robust push-and-pull commands for moving databases, files directories, and codebases between your local and any remote Pantheon environment.

Pre-made configurations

  • DDEV has various "quickstarts", similar to Lando's recipes, including ones for Drupal 6, 7, and 8, as well as Backdrop, Wordpress, and Pantheon hosting.

  • Docksal provides some basic default stack configurations, including an Acquia Cloud one, but not on the same level as Lando or DDEV.

  • Lando provides local development environment "recipes" for a plethora of development projects - including recipes for Drupal 6, 7, and 8, as well as recipes for Pantheon, Python, Dotnet, Joomla, Wordpress, and several other commonly used frameworks and providers (it is really quite impressive).

It doesn't appear that any of the options support Acquia, Platform.sh, or any of the other so-called "modern" Drupal hosting solutions (yet), but I don't think there's anything stopping that from happening in the future. In fact, it is already starting to happen.

Support and Documentation

All three options have both issue queue support as well as real-time chat support. Your mileage may vary, but I've found all three projects have very responsive maintainers, with a slight edge going to DDEV for responsiveness.

In addition, they all have relatively good documentation, considering their rapid development schedules and frequent additions. With all three options, I've found that I've had to hunt down answers not easily found in the documentation.

As an example, a few times while creating a new DDEV-powered site, I kept getting a message that port 443 was in use, but I couldn't figure out by what. It was easy enough to change the DDEV config to use a different port number, but it wasn't until I stumbled on a blog post where I learned about "lando poweroff" - this command spins down all Lando containers, including a "traefik" container that holds on to - you guessed it - ports 80 and 443. While there is a documentation page for "lando poweroff", there's nothing on the "Getting started" documentation page about it. It was only by searching the web and finding a blog post that I was able to figure out what the root cause of the issue was. I'm not picking on Lando here (far from it), as I've run into similar documentation issues with DDEV and Docksal as well. Bottom line - use all the support resources available to you.

Frequency of updates

One measure of a project's health and momentum is the frequency of updates. In all three cases, development is clearly on-going in each project.

  • DDEV - 6 releases in 2018 (5 minor, 1 patch), 13 releases in 2017 (10 minor, 3 patch).  

  • Docksal - 0 releases in 2018, 11 releases in 2017 (1 major, 6 minor, 1 patch).  

  • Lando - 4 releases in 2018 (4 betas), 51 releases in 2017 (20 alphas, 31 betas).  

Windows support

While I'm a Mac OS X user, not all of my students always are. Therefore, it is important to me that I select a tool that works well on both Mac and Windows, with a minimum of any "unique configurations" on Windows. All three options utilize some form of automated testing to ensure that each build works on both platforms. To date, I haven't discovered any major issues with any of these tools on Windows. In all cases, I've found it to be much easier to use a 3rd-party command line emulator, rather than using Windows' default command line tools.  

Requires internet connection

  • DDEV works fine without an internet connection - no configuration necessary.

  • Docksal can be run without an internet connection by manually adding an entry to your hosts file via the "fin hosts add mysite.docksal" command.

  • Lando has a documentation page about offline development, but it is only for Mac OS X, and the process is a bit more involved.

PHP options

All three tools provide the ability to swap in different versions of PHP via their configuration files.

  • The latest version of DDEV (0.15.0) now supports overriding php.ini (and other) settings from your project's configuration.

  • Docksal allows you to place a partial php.ini file as part of your project's configuration. The directives in this file will override any default PHP settings provided by the container.

  • Lando has some support for some PHP settings as part of their configuration files and also supports a php.ini file as part of a project's configuration.

In all three tools, it is possible to ssh into the CLI container and modify the php.ini settings directly - using this approach, these changes are only temporary, however, as the next time the container is rebuilt, the custom php.ini changes will be lost.

Performance

While I didn't run a full suite of tests on all three options, I did want to quantify their relative speed in a real-world situation. My method was to take an actual (Drupal 8) client site, get it up-and-running in all three options (sequentially), and simply time how long it took to run a "drush cache-rebuild all". I ran the command three times for each option and then calculated the average. Other factors depending on your exact site and configuration may come into play (having Xdebug enabled is a bit of a performance hit), so your mileage may vary.

  • DDEV: 90 seconds
  • Docksal: 20 seconds  
  • Lando: 89 seconds  

Why the huge advantage for Docksal? It's pretty simple - I'm currently using Docksal in "virtual machine" mode instead of utilizing Docker for Mac (both Lando and DDEV utilize Docker for Mac/Windows). It's pretty well-known that native Docker for Mac/Windows solutions are a bit performance-challenged. According to Docksal documentation, Docker for Mac/Windows will eventually become the recommended way of working with Docksal, despite the performance losses.

Other stuff

  • Docksal has a cool "automatic stand-alone CLI container" - this is a container that is not tied to a specific project and is always available. One big advantage to this container is that it can be used to run Composer commands without having to have Composer installed on the host operating system. This is (IMHO) a big deal on Windows, where installing Composer can be tricky (due to its dependency on PHP). There is talk for doing something similar in Lando as well as DDEV.  

  • Docksal utilizes a separate command to start and stop its main virtual machine (fin vm start/stop). It's not a big deal, just a small extra step (but the performance gains are worth it, as mentioned above.)

  • DDEV automatically writes a settings.local.php file, overwriting the entire file. So, if you're like me and you like to have configuration settings specific to your local environment (Stage File Proxy, Environment Indicator, as well as some of the stuff found in example.settings.local.php, you'll have to either recreate your settings whenever DDEV overwrites the file, or you can create a second settings.local2.php file. There is an open issue about possibly modifying this behavior.

Summary

Things I love about each option

  • DDEV - the fact that I can completely remove a project's containers without losing the project's database (and other data) is really nice. While their Pantheon integration isn't as robust as Lando's, it does enough (for now). The team behind DDEV appears to have the most consistent release schedule, and I've found their various support channels to be the most responsive. Also - DDEV has a "ddev sequelpro" command that automatically launches the Sequel Pro app (Mac OS X) and connects to the current project's database. I know it's a trivial thing, but I love it so much.

  • Docksal - its fast. If/when the maintainers decide to make using Docker for Mac/Windows the default, it'll be back on even ground with DDEV and Lando, but for now, it's just plain fast. I also really like that Docksal includes a "fin run-cli" command that allows you to run Composer commands ("composer create-project", for example) before setting up a project's containers. So handy.

  • Lando - its Pantheon integration is second-to-none. The ability to push and pull code, database, and/or files makes it a breeze when integrating with Pantheon sites. I'm really looking forward to when additional hosting-based recipes are available.

Things I don't love about each option

  • DDEV - I use a MacBook Air with 8GB RAM and a 1.7GHz Intel Core i7 as my main development machine. The stunning performance gap between DDEV and Lando compared with Docksal is completely attributed to Docker for Mac. I don't know all the ins-and-outs about why its performance is so lame, but I find it maddening sometimes. Also, the settings.local.php issue I mentioned above, but fingers-crossed that gets resolved soon.

  • Lando - re-read what I just wrote about DDEV (except for the settings.local.php stuff). Same. Also, whenever Docker is restarted, the Lando proxy also automatically starts up and grabs hold of port 443 - regardless of if I have any local Lando sites up-and-running. This can cause conflicts with other processes that want to use that port. Lando's "push" command for Pantheon is a little too aggressive for my tastes - it automatically adds, commits and pushes all outstanding changes in your local codebase to the Pantheon repository (I don't care for "git add ." either).

  • Docksal - lack of Pantheon integration. Granted, it's not terribly difficult to write custom commands to automate pulling databases from Pantheon, but it sure would be nice if it was built-in.

While going through this exercise, I've realized that there's really no single globally "the best" solution. There are pros and cons for each option, and it's really up to the developer (or development team) to determine what's best for them.

Regardless of which option you decide to go with, here are some important things that I've learned:

  • Pay attention to updates and apply them appropriately (including Docker updates if you're using DDEV or Lando). The pace of each option is such that something that doesn't work today might very well be fixed in the very near future. Pay attention to the release notes for each update, as sometimes there are incompatibilities with specific versions of Docker.

  • All of these options take up a non-trivial amount hard drive space for each project. For projects that are dormant, go ahead and destroy the containers - that's the whole point of having a solid developer workflow. Recreate the containers (re-import the DB and files directory if you're using Lando or Docksal) when you need to work on the project again.

  • Get familiar with the real-time chat support for whichever option you go with. They can be real time-savers.

Which will I be using going forward? For client work, the answer is "probably all three". For more complex sites, I'm addicted to Docksal's performance. For teaching, I'll be test-driving standardizing on DDEV starting with the Spring, 2018 class of Drupal Career Online. It's ease of installation on both Windows and Mac OS X, along with its straightforward commands, hard-drive-space-saving architecture, and incredibly responsive support channels give it the edge (at least for me) over Lando.

Which solution should you use? It really depends on you and/or your team's situation. You're going to want to take into account factors such as host operating system (Mac OS X or Windows), hosting environment (on-site, managed VPS, Acquia/Pantheon/Platform.sh), skill level, and other factors. We're experiencing a bit of a renaissance in local development environments with a good deal of innovation and momentum - which makes it a buyer's market, so take advantage and find the solution that works best for you.

Official project links

Blog posts

Acknowledgements

Thanks to Mike Pirog from the Lando project, Rick Manelius from the DDEV project, and David Hernandez from the Docksal project for their input on this blog post.

Original Article: