---
title: "Local Drupal Development Roundup"
url: "/articles/local-drupal-development-roundup"
type: article
date: 2018-01-24
updated: 2023-09-14
---

# Local Drupal Development Roundup

#  Local Drupal Development Roundup 

 What’s a developer lead to do? Let's review the options available for 2018!

 By

 [  Andrew Berry   ](/about/andrew-berry) 

 January 24, 2018

  

If you’d asked me a decade ago what local setup for web development would look like, I would have guessed “simpler, easier, and turn-key”. After all, WAMP was getting to be rather usable and stable on Windows, Linux was beginning to be preinstalled on laptops, and Mac OS X was in its heyday of being the primary focus for Apple.

Today, I see every new web developer struggle with just keeping their locals running. Instead of consolidation, we’ve seen a multitude of good options become available, with no clear “best” choice. Many of these options require a strong, almost expert-level of understanding of \*nix systems administration and management. Yet, most junior web developers have little command line experience or have only been exposed to Windows environments in their post-secondary training.

What’s a developer lead to do? Let's review the options available for 2018!

## 1. The stack as an app: \*AMP and friends

In this model, a native application is downloaded and run locally. For example, [MAMP](https://www.mamp.info) contains an isolated stack with Apache, PHP, and MySQL compiled for Windows or macOS. This is by far the simplest way to get a local environment up and running for Mac or Windows users. It’s also the easiest to recover from when things go wrong. Simply uninstall and reinstall the app, and you’ll have a clean slate.

However, there are some significant limitations. If your PHP app requires a PHP extension that’s not included, adding it in by hand can be difficult. Sometimes, the configuration they ship with can deviate from your actual server environments, leading to the “it works on my local but nowhere else” problem. Finally, the skills you learn won’t apply directly to production environments, or if you change operating systems locally.

## 2. Native on the workstation

This style of setup involves using the command line to install the appropriate software locally. For example, Mac users would use [Homebrew](https://brew.sh) and [Homebrew-PHP](https://github.com/Homebrew/homebrew-php) to install Apache, PHP, and MySQL. Linux users would use `apt` or `yum` - which would be similar to setting up on a remote server. Windows users have the option of the [Linux subsystem now available in Windows 10](https://learn.microsoft.com/en-us/windows/wsl/about).

This is slightly more complicated than an AMP application as it requires the command line instead of using a GUI dashboard. Instead of one bundle with “everything”, you have to know what you need to install. For example, simply running `apt install php` won’t give you common extensions like `gd` for image processing. However, once you’ve set up a local this way, you will have immediately transferable skills to production environments. And, if you need to install something like the PHP mongodb or redis extensions, it’s straightforward either through the package manager or through `pecl`.

### Linux on the Laptop

Running a Linux distribution as your primary operating system is a great way to do local development. Everything you do is transferable to production environments, and there are incredible resources online for learning how to set everything up. However, the usual caveats around battery life and laptop hardware availability for Linux support remain.

## 3. Virtual Machines

Virtual machines are actually [really old technology](https://en.wikipedia.org/wiki/IBM_CP-40)—older than Unix itself. As hardware extensions for virtualization support and 4GB+ of RAM became standard in workstations, running a full virtual machine for development work (and not just on servers) became reasonable. With 8 or 16GB of memory, it’s entirely reasonable to run multiple virtual machines at once without a noticeable slowdown.

[VirtualBox](https://www.virtualbox.org) is a broadly used, free virtual machine application that runs on macOS, Linux, and Windows. Using virtual machines can significantly simplify local development when working on significantly different sites. Perhaps one site is using PHP 5.6 with MySQL, and another is using PHP 7.1 with MariaDB. Or, another is running something entirely different, like Ruby, Python, or even Windows and .Net. Having virtual machines lets you keep the environment separate and isolated.

However, maintaining each environment can take time. You have to manually copy code into the virtual machine, or install a full environment for editing code. Resetting to a pristine state takes time.

### Vagrant

Clearly, there were advantages in using virtual machines—if only they were easier to maintain! This is where [Vagrant](https://www.vagrantup.com) comes in. For example, instead of spending time adding a virtual machine with a wizard, and manually running an OS installer, Vagrant makes initial setup as easy as `vagrant up`.

Vagrant really shines in my work as an architect, where I’m often auditing a few different sites at the same time. I may not have access to anything beyond a git repository and a database dump, so having a generic, repeatable, and isolated PHP environment is a huge time saver.

Syncing code into a VM is something Vagrant handles out of the box, with support for NFS on Linux and macOS hosts, SMB on Windows hosts, and rsync for anywhere. This saves from having to maintain multiple IDE and editor installations, letting those all live on your primary OS.

Of course, someone has to create the initial virtual machine and configure it into something called a “base box”. Conceptually, a base box is what each Vagrant project forks off of, such as `ubuntu/zesty`. Some developers prefer to start with an OS-only box, and then use a provisioning tool like [Ansible](https://www.redhat.com/en/ansible-collaborative?intcmp=7015Y000003t7aWQAQ) or [Puppet](https://www.puppet.com/) to add packages and configure them. I’ve found that’s too complicated for many developers, who just want a straightforward VM they can boot and edit. Luckily, Vagrant also supports custom base boxes with whatever software you want baked in.

For [Drupal development](https://www.lullabot.com/resource/drupal-development), there’s [DrupalVM](https://www.drupalvm.com) or my own provisionless [trusty-lamp base box](https://github.com/Lullabot/trusty32-lamp). You can [find more base boxes on the Vagrant website](https://portal.cloud.hashicorp.com/vagrant/discover).

## 4. Docker

In many circles, [Docker](https://www.docker.com) is the “one true answer” for local development. While Docker has a lot of promise, in my experience it’s also the most complicated option available. Docker uses APIs that are part of the Linux kernel to run containers, which means that Docker containers can’t run straight under macOS or Windows. In those cases, a lightweight virtual machine is run, and Docker containers are run inside of that. If you’re already using Docker in production (which is its own can of worms), then running Docker for locals can be a huge win.

Like a virtual machine, somehow your in-development code has to be pushed inside of the container. This has been a [historical pain point for Docker](https://docs.docker.com/docker-for-mac/osxfs-caching/), and can only be avoided by running Linux as your primary OS. [docker-sync](http://docker-sync.io) is probably the best solution today until the osxfs driver gets closer to native performance. Using Linux as your primary operating system will give you the best Docker experience, as it can use bind mounts which have no performance impact.

I’ve heard good things about [Kalabox](https://www.kalabox.io), but haven’t used it myself. Kalabox works fine today but is not being actively developed, in favor of [Lando](https://docs.devwithlando.io), a CLI tool. Pantheon supports taking an existing site and making it work locally through a [Kalabox plugin](https://docs.pantheon.io/guides/local-development). If your hosting provider offers tooling like that, it’s worth investigating before diving too deeply into other options.

I did some investigation recently into [docker4drupal](https://wodby.com/stacks/drupal/docs/local/). It worked pretty well in my basic setup, but I haven’t used it on a real client project for day-to-day work. It includes many optional services that are disabled out of the box but may be a little overwhelming to read through. A good strategy to learn how Docker works is to build a basic local environment by hand, and then switch over to docker4drupal to save having to maintain something custom over the long run.

[ddev](https://github.com/ddev/ddev) is another “tool on top of docker” made by a team with ties to the Drupal community. It was easy to get going for a basic Drupal 8 site. One interesting design decision is to store site files and database files outside of Docker, and to require a special flag to remove them. While this limits some Docker functionality (like snapshotting a database container for update hook testing), I’ve seen many developers lose an hour after accidentally deleting a container. If they keep focusing on these common pain points, this could eventually be one of the most friendly Docker tools to use.

One of the biggest issues with Docker on macOS is that by default, it stores all containers in a single disk image [limited to 64GB of space](https://gist.github.com/stefanfoulis/5bd226b25fa0d4baedc4803fc002829e). I’ve seen developers fill this up and completely trash all of their local Docker instances. Deleting containers often won’t recover much space from this file, so if your Mac is running out of disk space you may have to reset Docker entirely to recover the disk space.

When things go wrong, debugging your local environment with Docker requires a solid understanding of an entire stack of software: Shells in both your host and your containers, Linux package managers, init systems, networking, docker-compose, and Docker itself.

I have worked with a few clients who were using Docker for both production and local development. In one case, a small team with only two developers ended up going back to MAMP for locals due to the complexity of Docker relative to their needs. In the other case, I found it was faster to pull the site into a Vagrant VM than to get their Docker containers up and running smoothly. What’s important is to remember that Docker doesn’t solve the scripting and container setup for you—so if you decide to use Docker, be prepared to maintain that tooling and infrastructure. The only thing worse than no local environment automation is automation that’s broken.

At Lullabot, we use [Docker to run Tugboat](https://www.tugboatqa.com/), and for local development of lullabot.com itself. It took some valiant efforts by [Sally Young](https://www.lullabot.com/about/sally-young), but it’s been fairly smooth since we transitioned to using docker-sync.

## What should your team use?

Paraphrasing what I wrote over in the [README for the trusty-lamp basebox](https://github.com/Lullabot/trusty32-lamp#choosing-between-xamp-vagrant-and-docker):

Deciding what local development environment to choose for you and your team can be tricky. Here are three options, ordered in terms of complexity:

1. Is your team entirely new to PHP and web development in general? Consider using something like [MAMP](https://www.mamp.info/) instead of Vagrant or Docker.
2. Does your team have a good handle on web development, but are running into the limitations of running the site on macOS or Windows? Does your team have mixed operating systems including Windows and Linux? Consider using Vagrant to solve all of these pain points.
3. Is your team using Docker in production, or already maintaining Dockerfiles? If so, consider using [docker4drupal](https://github.com/wodby/docker4drupal) or your production Docker containers locally.

Where do you see local development going in 2018? If you had time to completely reset from scratch, what tooling would you use? Let us know in the comments below.

 Published in:

- [  Drupal Development   ](/topics/drupal-development)
- [  Drupal Site Building   ](/topics/drupal-site-building)

 

   You must have JavaScript enabled to use this form.

## Get in touch with us

### Tell us about your project. We'd love to hear from you!

 First Name  

 Last Name  

 Your email address  

 Your organization  

 How you heard about us  

 Tell us more 

     Leave this field blank