DDEV, Docksal, and Lando: A Comparison

Published March 20, 2018

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.

DDEVAs 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 been 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.


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.

LandoAs 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 <drush-command>, lando drush <drush-command>, ddev exec <drush-command>.

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. UPDATE: I've been corrected - Docksal does example configurations available for Drupal 7, Drupal 8, WordPress, and a few other CMSs.

  • 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. UPDATE! I goofed! The previous link is if you want to manage your own local DNS, if you just want to work offline, it is much easier!

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.


DocksalWhile 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.


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


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.


Author comment

I've heard lots of good things about Docker4Drupal, but haven't tried it. As I said in the article, one of the main criteria was something that is approachable for my long-form training students (where I'm not looking to teach Docker on top of Drupal, Composer, PHP, etc...)

I've heard of Amazee's Lagoon - when I get some time, I'll check it out.

Really great post. Makes me want to try lando a little more. I see you didn't mention docker4drupal which I've used and like that it uses really small container images based on alpine instead of ubuntu (a few megabytes each instead of hundreds). I don't know what type of containers the other projects use.

Submitted by Joaquin Bravo (not verified) on Thu, 03/22/2018 - 08:24

Thanks for great and thorough review of all the options.

I just wanted to chime in a small correction to pre-made configurations. Docksal does provide "quickstarts" for Drupal 7, Drupal 8, Magento, Laravel, Grav CMS, Gatsby CMS and Static HTML site.

They are called examples and they actually live in separate repositories under http://github.com/docksal but for end user they are also easily available from the command line with fin project create.

Best regards.

Submitted by Oleksii Chekulaiev (not verified) on Thu, 03/22/2018 - 10:41

I've been using Docksal for over a year at this point, and it's been the best working experience of my life. I have yet to try the other tech mentioned in this article, but at the same time I just haven't seen the need? I guess if I had more time to experiment I'd try them out for giggles :) This is a great comparison post for me though, thanks for the putting it together.

Submitted by Les Peabody (not verified) on Thu, 03/22/2018 - 12:02

Thanks for the article Mike. Docker based web development is moving so fast, but I’m hoping it means better tools quicker, particularly for the agency/training space. As an example, I wrote a “Docker for web developers” presentation back in February 2018 looking at just Lando and Docksal, and I am already rewriting it for reuse in April for the local PHP user group, partly inspired by this article and also reading JAM’s article.

Keep up the good work and thanks again.

Submitted by David Thorne (… (not verified) on Sat, 03/24/2018 - 07:08

In regards to the issue of Lando taking over ports, I think it actually does it the correct way: it uses 80/443 if they’re available otherwise it chooses something else. Maybe it’s the other two that are lacking this feature?

Also about the always-on Composer container, I can see this causing more problems than it solves. Composer always needs to be run with the same minor version of PHP by everyone on the team. Otherwise in each commit there will be all sorts of other stuff changing unrelated to whatever package/version change. This makes merges a real bear.

Submitted by Dalin (not verified) on Sun, 03/25/2018 - 10:48

Author comment

That's actually a good point about Composer running in the same version of PHP and something I hadn't thought about.

As for Lando taking over ports, I didn't mean to imply that what Lando is doing is a bad thing - it's not. I was just making the point that I wasn't aware of the "lando poweroff" command to release those ports.

Composer can be configured to build for a specific version of PHP like this:

composer config platform.php 5.6.20

(see https://getcomposer.org/doc/06-config.md#platform ) I'd suggest this is worth using whether you're using any Docker-based solution or not anyway!
Plus, if it's actually the version of *composer* causing unrelated change (e.g. timestamp formats changed a while ago), you can ensure everyone on a project uses compatible versions with https://github.com/deviantintegral/composer-gavel

I think the best practice for running composer is to run it from the container, and make sure that it uses the same version of PHP as the production servers. You can also add a platform section to your composer.json: https://getcomposer.org/doc/06-config.md#platform

I have been using Lando. I just restarted Docker for Mac, and the traefik container did not start up automatically.

I have heard good things about ddev, and hope to try it soon.

I am not impressed with Docksal's architecture. Maybe I am stuck on an old version (set up by a client) but it seems that fin is a single bash script.

I like the way Lando lets me add sub-commands, like lando phpunit.

Submitted by Benji Fisher (not verified) on Fri, 03/30/2018 - 17:42

Thank you for writing this blog post. You kind of mentioned that support for HTTPS is available onn Lando and DDEV. Is that also true for Docksal?

Submitted by Maximo (not verified) on Tue, 04/17/2018 - 22:40

Since your post, Docksal has come a long way in providing tools for the Pantheon platform. The 1.8.0 release in April included terminus. They have had in the works for some time a pantheon-like stack. They're still working on that one. In just days, we'll see the release of 1.9.0, which will be their 3rd release of the year. This one will bring with it a number of improvements to the cli as well as an improved unison option for running in Docker native mode.

Submitted by Shelane French (not verified) on Fri, 06/01/2018 - 17:47

In case anyone is curious - DDEV now offers a GUI for people who are not as comfortable with the command line. The DDEV UI is available in Alpha with a few caveats explained here:

The team would love feedback, especially from people coming from MAMP land, or looking for a modern alternative to Acquia's Dev Desktop!

Ping us on http://twitter.com/drud if you have any questions!

Submitted by Heather (not verified) on Thu, 09/13/2018 - 06:07

I've been loving Docksal now for several months. As mentioned above, I find it crucial to run composer, npm, etc from within a "build container" like the Docksal CLI container. These tools should never be run locally as they can install different packages based on the local OS of different devs. Having a single container with "all the tools" needed for dev that is separate from the containers needed to run the site is very useful and something I didn't see with Lando (and haven't tried DDev).

On performance issues, we are using Docksal with Docker4Mac but using the newer "native" mode that uses the Mac Osx Hyperkit vm rather than VirtualBox. The reason Docksal has such great performance by default is it uses unison to sync files between local and containers. This results in great performance, but can have issues when syncing lots of small files (like a "rm -rf node_modules && npm install"). I've even had unison crash in some cases, which is annoying because it happens silently and you just start wondering why your local changes aren't being seen within the containers.

With the Docksal Native option, we are getting only a 20% performance decrease over the unison performance. Would be interested in knowing if Lando or DDev also support the native Mac Osx hyperkit and file system rather than the slow VirtualBox + NFS default of Docker4Mac.

Submitted by mpotter (not verified) on Mon, 10/08/2018 - 13:55

ddev on macOS uses Docker for Mac, which usees Hyperkit, not Virtualbox. Performance is pretty good; we're also working on unison-like approaches to do even better. You can follow https://github.com/drud/ddev/issues/835 for updates. Thanks for trying it out!

Submitted by Randy Fay (not verified) on Mon, 12/03/2018 - 10:19

Sign up to receive email notifications of whenever we publish a new blog post or quicktip!