Install Homebrew Mac Mojave

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Install Homebrew Mac Mojave
Install Homebrew Mac Mojave Iso
Install Homebrew On Mac Os X Mojave

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

This is a detailed installation guide for ns-3. Basic installation instructions can be found in the ns-3 tutorial (see Getting Started chapter).

Install Go Lang on MacOS with Homebrew! I’ve started learning Go lang. It seems to be built by the right people with the right expectations. So, the first thing I did was install go on Mac with Homebrew. 👨‍💻 I’m teaching thousands of devs how to become VSCode Power Users → This site is super fast?! Apt-get install sshpass Installing on OS X. Installing on OS X is tricky, since there is no official build for it. Before you get started, you need install xcode and command line tools. Installing with Homebrew. Homebrew does not allow you to install sshpass by default. But you can use the following unofficial brew package for that. An extra warning: don't run this when a homebrew based python installed and occurs earlier in PATH (e.g. When you change /etc/paths): it would install pip with root credentials for the wrong python – acidjunk Jan 7 '16 at 13:56.

1Supported platforms
- 1.2Integrated development environment support
2Prerequisites
- 2.1Linux
3Installation
- 3.2Manual installation
4Building ns-3 with build.py
8Obsolete information

Supported platforms

ns-3 is primarily developed on GNU/Linux and macOS platforms, and the minimal requirements to run basic simulations are a C++ compiler; either g++ or clang++ compiler, and Python (version 3) interpreter. The below instructions are per-platform instructions for supplemental packages that enable optional features of ns-3 or companion tools.

Operating system and compiler support

ns-3 is supported and currently tested on the following primary platforms:

Linux (x86 and x86_64): gcc/g++ versions 4.9 and above
1. Note: If you are using RHEL or Centos, you will likely need to install a more up-to-date compiler than the default; search for how to enable 'software collections' or 'devtoolset' on these distributions. Other Linux distributions typically have a suitable default compiler (at least version 4.9).
MacOS Apple LLVM: version 8.0.0 and above (version 7.0.0 may work)
FreeBSD and Linux (x86_64): clang/LLVM version 3.9 and above (older versions down to 3.3 may work)

The minimum Python version supported is currently version 3.5 or greater (major version 3).

By supported, we mean that the project tries to support most or all of the build options on these platforms unless there is a good reason to exclude the option; and at least the debug build will compile. If you intend to do serious work using ns-3, and are forced by circumstances to use a Windows platform, consider virtualization of a popular Linux platform or using Windows Subsystem for Linux.

The following platforms are lightly supported:

Windows Visual Studio 2012 (presently being upgraded)

Some aspects of ns-3 depend on Unix (or specifically Linux) support, such as the emulation or TapBridge features, and those components are not enabled on the Windows or MacOS versions cited above.

Additional maintainers are invited to make more platforms, compilers and environments supported.

Integrated development environment support

Eclipse

The Eclipse IDE is not an officially supported platform, but some developers use it and have compiled a HOWTO.

NetBeans

NetBeans is not officially supported either, but there is a HOWTO as well.

QtCreator

Same rule applies to Qt Creator; it's not officially supported, but there are developers that use it and HOWTO is available.

Support for optional features

There are a few options that are not enabled by default and are not available on all platforms. At the end of the configuration process (explained below), the status of these options are shown as detected by a waf script:

Generally if the platform is missing some requirement for an option it is marked as 'not enabled.' Note that 'disabled by user request' will be shown when the user explicitly disables a feature (such as '--disable-python'); and if a feature defaults to disabled this will also be noted (e.g., option --enable-sudo not selected).

The table below is meant to help sort out the different features and on which platforms they are supported. This table reflects the status as of ns-3.15 and may have changed since then:

Option status
Option	Linux	FreeBSD	Mac OS X
Optimized build	Y	Y	Y
Python bindings	Y	Y	Y
Threading	Y	Y	Y
Real-time simulator	Y	Y	N
Emulated Net Device	Y	N	N
Tap Bridge	Y	N	N
Network simulation cradle	Y¹	?	N
Static builds	Y	Y	Y

Key:Y = supported; N = not supported; ? = unknown; dev = support in ns-3-dev (next release)

Notes:

NSC works best with gcc-3.4 or gcc-4.2 or greater series. Try to avoid using gcc-4.0 and gcc-4.1 series; some build problems have been found with these versions of compilers.

Prerequisites

The core of ns-3 requires a gcc/g++ installation of 4.9 or greater (Linux), or a recent version of clang compiler (OS X, Linux, or BSD), and Python 3.5 or greater. As mentioned above, different options require additional support. This is a list of packages (for Debian/Ubuntu systems) that are needed to support different ns-3 options. Note that other distributions (e.g., Fedora, FreeBSD) may have different package names or capitalization (e.g. ImageMagik). Installation should be similar for Red Hat/Fedora based systems, with 'yum' replacing 'apt-get', but some differences exist, so below is a guide for both Ubuntu (should generally apply to Debian) and Fedora/RedHat-based systems:

Linux

CentOS

Note: CentOS version 6 series (currently 6.8) requires an upgrade of both gcc and Python to meet current ns-3 requirements. See these instructions if you need to upgrade: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2667#c1

The below instructions are based on a CentOS 6.6 install in November 2014; other RedHat/Fedora-based installs are likely similar.

minimal requirements for C++ (release): This is the minimal set of packages needed to run ns-3 C++ programs from a released tarball.

minimal requirements for Python (release): Python development headers are necessary to enable the Python bindings (for writing ns-3 programs from Python):

The following additional packages add functionality to the build or documentation.

The netanim animator requires Qt5 development packages:

Mercurial is needed to work with ns-3 development repositories.

Doxygen and related inline documentation:

The ns-3 manual and tutorial are written in reStructuredText for Sphinx (doc/tutorial, doc/manual, doc/models), and figures typically in dia:

MPI-based parallel, distributed simulation support requires openmpi:

To read pcap packet traces generated by ns-3

Database support for statistics

Xml-based version of the config store (requires libxml2 >= version 2.7)

Support for utils/check-style.py style check program

Support for openflowswitch requires libxml2, if not installed above

Support for ns-3-pyviz visualizer

This is a bit more involved due to lack of package support in the standard repositories.

Some additional packages are needed (goocanvas and pygoocanvas). It is suggested to enable the RPMForge repo as described here: http://wiki.centos.org/AdditionalResources/Repositories/RPMForge. Then, try this:

Then obtain the RPM for pygoocanvas and pygoocanvas-devel from here: http://li.nux.ro/download/nux/dextop/el6/x86_64/

Or, if you prefer, build pygoocanvas from source code found here: https://wiki.gnome.org/Projects/PyGoocanvas

Note, if you perform this install successfully on a CentOS server that does not have a desktop installed (i.e. a CentOS 'minimal install'), you will still not be able to see pyviz enabled; you will see the configuration report:

because the Python gtk module opens the display upon import.

Git is needed to fetch click modular routing and pygccxml

An optional but recommended package (for improving some wireless model fidelity) is GNU scientific library:

A GTK-based configuration system

Debugging:

Ubuntu/Debian/Mint

The following list of packages should be accurate for Ubuntu 19.04 release; other releases or other Debian-based systems may slightly vary. Ubuntu 16.04 LTS release is probably the oldest release that is known to work with recent ns-3 releases.

Note: As of ns-3.30 release (August 2019), ns-3 uses Python 3 by default, but earlier releases depend on Python 2 packages, and at least a Python 2 interpreter is recommended. If working with an earlier release, one may in general substitute 'python' for 'python3' in the below (e.g. install 'python-dev' instead of 'python3-dev').

minimal requirements for C++ users (release): This is the minimal set of packages needed to run ns-3 from a released tarball.

minimal requirements for Python API users (release 3.30, 3.31, and ns-3-dev): This is the minimal set of packages needed to work with Python bindings from a released tarball.

minimal requirements for Python (development): For use of ns-3-allinone repository (cloned from Git), additional packages are needed to fetch and successfully install pybindgen and netanim.

Netanim animator: qt5 development tools are needed for Netanim animator; qt4 will also work but we have migrated to qt5.

Support for ns-3-pyviz visualizer

- For ns-3.28 and earlier releases, PyViz is based on GTK+ 2, GooCanvas, and GraphViz:

- For Ubuntu 18.04, python-pygoocanvas is no longer provided. The ns-3.29 release and later upgrades the support to GTK+ version 3, and requires these packages:

Support for MPI-based distributed emulation

Support for bake build tool:

Debugging:

Support for utils/check-style.py code style check program

Doxygen and related inline documentation:

- If you get an error such as 'convert ... not authorized source-temp/figures/lena-dual-stripe.eps', see this post about editing ImageMagick's security policy configuration: https://cromwell-intl.com/open-source/pdf-not-authorized.html. In brief, you will want to make this kind of change to ImageMagick security policy:

The ns-3 manual and tutorial are written in reStructuredText for Sphinx (doc/tutorial, doc/manual, doc/models), and figures typically in dia (also needs the texlive packages above):

Note: Sphinx version >= 1.12 required for ns-3.15. To check your version, type 'sphinx-build'. To fetch this package alone, outside of the Ubuntu package system, try 'sudo easy_install -U Sphinx'.

GNU Scientific Library (GSL) support for more accurate 802.11b WiFi error models (not needed for OFDM):

If the above doesn't work (doesn't detect GSL on the system), consult: https://coral.ise.lehigh.edu/jild13/2016/07/11/hello/. But don't worry if you are not using 802.11b models.

To read pcap packet traces

Database support for statistics framework

Xml-based version of the config store (requires libxml2 >= version 2.7)

Support for generating modified python bindings

and you will want to install castxml and pygccxml as per the instructions for python bindings (or through the bake build tool as described in the tutorial). The 'castxml' and 'pygccxml' packages provided by Ubuntu 18.04 and earlier are not recommended; a source build (coordinated via bake) is recommended. If you plan to work with bindings or rescan them for any ns-3 C++ changes you might make, please read the chapter in the manual on this topic.

Note: Ubuntu versions (through 19.04) and systems based on it (e.g. Linux Mint 18) default to an old version of clang and llvm (3.8), when simply 'libclang-dev' and 'llvm-dev' are specified. The packaging on these 3.8 versions is broken. Users of Ubuntu will want to explicitly install a newer version by specifying 'libclang-6.0-dev' and 'llvm-6.0-dev'. Other versions newer than 6.0 may work (not tested).

A GTK-based configuration system

To experiment with virtual machines and ns-3

Support for openflow module (requires libxml2-dev if not installed above)

Fedora/RedHat

The following list of packages should be aligned with recent Fedora releases; other releases may slightly vary. Note that these distributions sometimes change the package structure over time.

Important: If you are using RedHat or CentOS, either versions 6 or 7, the default compilers are too old to build recent ns-3 releases. You must upgrade gcc and g++ to a more recent version. See below.

Release-specific issues

Fedora 28 and Fedora 29 use gcc-8 by default, and this newer compiler raises warnings (that turn into compiler errors) with all ns-3 releases prior to ns-3.29.

RHEL 7 (and CentOS 7) use an older version of gcc (4.8.5) that is no longer compatible with ns-3 releases. An upgrade of gcc is needed; see these instructions on installing a devtoolset (such as devtoolset-7) if you need to upgrade: http://blog.stevedoria.net/20180214/how-to-install-gcc-7-on-centos-7

RHEL 6 (and CentOS 6) uses older versions of gcc (4.4) and Python (2.6) that are no longer compatible with ns-3 releases. An upgrade of both gcc and Python is needed; see these instructions on installing a devtoolset if you need to upgrade: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2667#c1

Required and optional packages

minimal requirements for C++ (release): This is the minimal set of packages needed to run ns-3 from a released tarball.

minimal requirements for Python (release): This is the minimal set of packages needed to work with Python bindings from a released tarball.

Mercurial and git are needed to work with ns-3 development repositories.

An optional but recommended package (for improving some wireless model fidelity) is GNU scientific library:

Support for netanim animator:

A GTK-based configuration system

Prior to ns-3.29, use GTK+ version 2:

Starting with ns-3.29, use GTK+ version 3:

Debugging:

Doxygen and related inline documentation:

The ns-3 manual and tutorial are written in reStructuredText for Sphinx (doc/tutorial, doc/manual, doc/models), and figures typically in dia:

Note: Sphinx version >= 1.12 required for ns-3.15. To check your version, type 'sphinx-build'. To fetch this package alone, outside of the Fedora package system, try 'sudo easy_install -U Sphinx'

The Network Simulation Cradle (nsc) requires the flex lexical analyzer and bison parser generator; note, this requires older compiler support (gcc-4 series):

To read pcap packet traces

Database support for statistics framework

Xml-based version of the config store (requires libxml2 >= version 2.7)

Support for utils/check-style.py style check program

Support for MPI distributed simulations

Steve Smith notes that the shell must be restarted after environment-modules package is installed, since environment-modules modifies the bash initialization scripts to enable the module command. Then, to find the programs mpic++ and mpiexec, one must do:

and then the commands should be found by the shell:

Support for openflowswitch requires libxml2, if not installed above

Support for ns-3-pyviz visualizer (ns-3.28 release and earlier)

Support for ns-3 pyviz visualizer (ns-3.29 release and later)

Support for generating modified python bindings

and you will want to install castxml and pygccxml as per the instructions for python bindings (or through the bake build tool as described in the tutorial). If you plan to work with bindings or rescan them for any ns-3 C++ changes you might make, please read the chapter in the manual on this topic.

Support for bake tool:

macOS

macOS installation of ns-3 relies on the Xcode command line tools provided by Apple, and the clang/llvm compiler used therein. A third-party package manager such as Homebrew can be used for optional extensions to ns-3 such as libxml2.

The current version of macOS is 'Catalina' (10.15) and the version of Xcode is 11.2, as of this writing.

If you are having problems with ns-3.29 and macOS, please look at the Errata page for some hints, or consider to use the development version (ns-3-dev) of ns-3 which should work now. ns-3.30 is not know to have macOS issues.

The main steps to follow to prepare your macOS machine for a base ns-3 install (Xcode tools, and Python) are as follows:

Download and install Xcode Command Line Tools (most recently tested version 11.2) from the App Store, or the full Xcode.
1. If you installed full Xcode, you still need to type `xcode-select --install` to obtain the command line tools.
2. You will also have to agree to Apple's license agreement to proceed; type 'sudo clang -v' in a terminal window to take this step.

At this point, you will likely be able to compile the main C++ libraries. The current macOS Catalina release ships with a basic Python 3 interpreter (version 3.7.3) which is enough to run the Waf build system but not much else. To use Python bindings or other Python features, a fuller install of Python is recommended. Visit https://www.python.org/downloads/mac-osx/ to download a Python 3 release (recommended), or else, if you prefer, use Homebrew or some other package manager to install a Python development environment.

At this point, you should be able to use ns-3 in C++ or Python programs. The following options are available to add some additional libraries for more ns-3 features. In general, a third-party installer like Homebrew or MacPorts is needed:

Recommended for Mojave users (for better Homebrew compatibility), install the legacy headers package found at: /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg. We are not sure whether this is available for Catalina (10.15).
If you wish to use the NetAnim animator, you must install Qt5 (although Qt4 version also works with current releases).
If you wish to use mercurial, you must install it. Follow the instruction in the mercurial web site. MacPorts and Homebrew are possible package managers to accomplish this.
If you wish to use the GTK-based ConfigStore GUI, we recommend homebrew: if you install Gtk+3 using homebrew, you must install gtk+3. You must install also 'adwaita-icon-theme' (not installed by default), or you'll miss elements in the Gtk views

.Note to Anaconda users: If you have installed Anaconda, you may encounter a build problem such as:

This can be worked around by configuring Waf to use the system Python instead of the Python version provided by Anaconda. At the Waf configuration stage, try:

When using build.py, the argument can be passed as follows:

See: issue 2778 in the ns-3 tracker for more information.

For OS X 10.8 (Mountain Lion) and earlier, using Xcode 4 series, please see HOWTO_get_ns-3_running_on_Mac_OS_X_(10.6.2_Intel) and follow steps 1 and 2 (prerequisites) and continue reading below if you want to work with a released version, and follow all steps if you want to work with a development version of ns-3.

Windows

For Windows 10, there are two main options. Both involve using a Linux environment from within Windows. ns-3 is not compatible with the Windows Visual Studio compiler and IDE (there have been a few efforts to add Visual Studio support, but they have been abandoned).

. Install a Linux virtual machine (e.g. using Hyper-V, VMware, etc.).
. Windows offers a Windows subsystem for Linux, providing an Ubuntu-like environment. From within this environment, one can follow the Ubuntu installation guide and obtain most ns-3 features.

Below is some other older (possibly out-of-date) information regarding Windows:

We provide HOWTO documents describing the process for installing Linux and getting ns-3 running using two popular virtualization products: VirtualBox (HOWTO use VirtualBox to run simulations on Windows machines) and VMware (HOWTO use VMware to set up virtual networks (Windows)).
There is an experimental project, Ns3 on Windows, using Visual Studio 2012.

Installation

Installation with Bake

Bake is a new tool for installing, building and finding out the missing requirements for ns-3 in your own environment.

To use Bake you need to have at least Python (2.7 or above) and Git in your machine (see the section Prerequisites above to see how to install these).

First you need to download Bake using Git, go to where you want Bake to be installed and call

It is advisable to add bake to your path.

After that you can use Bake to find the missing packages, download build and install ns-3 and its modules.

To find out what is missing in your system and may be needed for installing ns-3 you can call bake check:

You should have seen something like:

Before downloading and building ns-3 you need to configure bake to inform it which are the modules you want added to ns-3, the standard distribution for example.

Then to see the modules it has added, and the specific system requirements for this configuration, you can call bake show:

To download the modules, build and install you can call bake deploy

This will download the selected modules, all their dependencies and build ns-3 with all these independent modules. You can also perform this installation step by step, i.e. by calling download and build in different steps.

Manual installation

The ns-3 code is available in Mercurial repositories on the server http://code.nsnam.org (look for the latest release e.g., 'ns-3.26'). You can download a tarball of the latest release at http://www.nsnam.org/releases or you can work with our repositories using Mercurial. We recommend using Mercurial unless there's a good reason not to (See the end of this section for instructions on how to get a tarball release).

The simplest way to get started using Mercurial repositories is to use the ns-3-allinone environment. This is a set of scripts that manages the downloading and building of various subystems of ns-3 for you. We recommend that you begin your ns-3 adventures in this environment as it can really simplify your life at this point.

Downloading ns-3 Using Git

One practice is to create a directory called repos in one's home directory under which one can keep local Git repositories. If you adopt that approach, you can get a copy of ns-3-allinone by typing the following into your Linux shell (assuming you have installed Git):

As the git command executes, you should see something like the following displayed,

After the clone command completes, you should have a directory called ns-3-allinone under your ~/repos directory, the contents of which should look something like the following:

Notice that you really just downloaded some Python scripts and not yet the C++ code. The next step will be to use those scripts to download and build the ns-3 distribution of your choice.

If you go to the following link: https://gitlab.com/nsnam/ you will see a number of repositories. Many are the private repositories of the ns-3 development team. The repositories of interest to you will be prefixed with ns-3. Official releases of ns-3 will be numbered as ns-3.release.hotfix. For example, a second hotfix to a still hypothetical release nine of ns-3 would be numbered as ns-3.9.2 on this page.

The current development snapshot (unreleased) of ns-3 may be found at https://gitlab.com/nsnam/ns-3-dev/. The developers attempt to keep these repository in consistent, working states but they are in a development area with unreleased code present, so you may want to consider staying with an official release if you do not need newly-introduced features.

You can find the latest version of the code either by inspection of the repository list or by going to the Getting Started web page and looking for the latest release identifier.

To download the most recent release (assuming it is ns-3.30 in this case), type the following into your shell (remember you can substitute the name of your chosen release number, or omit specifying it to download the tip of ns-3-dev)

After download process completes, you should have several new directories under ~/repos/ns-3-allinone:

Go ahead and change into ns-3.30 under your ~/repos/ns-3-allinone directory. You should see something like the following there:

You are now ready to build the ns-3 distribution.

Downloading ns-3 Using a Tarball

The process for downloading ns-3 via tarball is simpler than the Mercurial process since all of the pieces are pre-packaged for you. You just have to pick a release, download it and decompress it.

As mentioned above, one practice is to create a directory called repos in one's home directory under which one can keep local Mercurial repositories. One could also keep a tarballs directory. If you adopt the tarballs directory approach, you can get a copy of a release by typing the following into your Linux shell (substitute the appropriate version numbers, of course):

If you change into the directory ns-allinone-3.30 you should see a number of files:

You are now ready to build the ns-3 distribution.

Building ns-3 with build.py

The first time you build the ns-3 project you should build using the allinone environment. This will get the project configured for youin the most commonly useful way.

Change into the directory you created in the download section above. If you downloaded using Mercurial you should have a directory called ns-3-allinone under your ~/repos directory. If you downloaded using a tarball you should have a directory called something like ns-allinone-3.13 under your ~/tarballs directory. Type the following:

You will see lots of typical compiler output messages displayed as the build script builds the various pieces you downloaded. Eventually you should see the following magic words:

Once the project has built you typically will not use ns-3-allinone scripts. You will now interact directly with Waf and we do it in the ns-3-dev directory and not in the ns-3-allinone directory.

Configuration with Waf

To see valid configure options, type ./waf --help. The most important option is -d <debug level>. Valid debug levels (which are listed in waf --help) are: 'debug' or 'optimized'. It is also possible to change the flags used for compilation with (e.g.):

or, alternately, the gcc compiler

Note: Unlike some other build tools, to change the build target, the option must be supplied during the configure stage rather than the build stage (i.e., './waf -d optimized' will not work; instead, do

The resulting binaries are placed in build/<debuglevel>/srcpath. For example, in a debug build you can find the executable for the first.cc example as build/examples/first. You can debug the executable directly by:

Of course, you can run gdb in emacs, or use your favorite debugger such as ddd or insight just as easily. In an optimized build you can find the executable for the first.cc example as build/examples/ns-<version>-first-optimized.

In order to forcibly disable python bindings, you can provide the following option:

In order to tell the build system to use the sudo program to set the suid bit if required, you can provide the following option:

To start over a configuration from scratch, type:

Or if you get stuck and all else fails:

followed by changing back into ns-3-allinone and doing:

will basically reset your build state.

To see all waf options:

Validating

ns-3 has unit tests that can be run to verify the installation:

which should produce output like:

Using Python

See this page.

Troubleshooting

See this page.

Obsolete information

Older versions of ns-3, prior to 3.15, supported using cygwin to run on Windows platform.

Windows

There are three basic options for Windows support:

We provide HOWTO documents describing the process for installing Linux support and getting ns-3 running using two popular virtualization products: VirtualBox (HOWTO use VirtualBox to run simulations on Windows machines) and VMware (HOWTO use VMware to set up virtual networks (Windows)).
There is an experimental project, Ns3 on Windows, using Visual Studio 2012. For support on Visual Studio 2010 see ns-3 on Visual Studio 2010
Cygwin has been supported in the past: gcc 3.4.4 (debug only), gcc 4.3.2 (debug and optimized). Note, however, that there are limitations with regard to Python bindings, and that Real-time simulator, Emulated Net Device, Tap Bridge and Network simulation cradle are not supported.

An alternative Windows platform is MinGW. There are maintainers who attempt to keep a subset of ns-3 running on MinGW, but it is not 'officially' suppported. This means that bugs filed against MinGW will be addressed as time permits.

Cygwin can sometimes be problematic due to the way it actually does its emulation, and sometimes interactions with other Windows software can cause problems. If you do use Cygwin or MinGW; and use Logitech products, we will save you quite a bit of heartburn right off the bat and encourage you to take a look at the MinGW FAQ.

Search for 'Logitech' and read the FAQ entry, 'why does make often crash creating a sh.exe.stackdump file when I try to compile my source code.' Believe it or not, the ``Logitech Process Monitor`` insinuates itself into every DLL in the system when it is running. It can cause your Cygwin or MinGW DLLs to die in mysterious ways and often prevents debuggers from running. Beware of Logitech software when using Cygwin.

Retrieved from 'https://www.nsnam.org/mediawiki/index.php?title=Installation&oldid=12233'

DDEV is an open source tool that makes it dead simple to get local PHP development environments up and running within minutes. It's powerful and flexible as a result of its per-project environment configurations, which can be extended, version controlled, and shared. In short, DDEV aims to allow development teams to use Docker in their workflow without the complexities of bespoke configuration.

System Requirements¶

Docker version 18.06 or higher. Linux users make sure you upgrade docker-compose and do the post-install steps

docker-compose 1.21.0 and higher (bundled with Docker in Docker Desktop for Mac and Docker Desktop for Windows)
OS Support
* macOS Mojave and higher (macOS 10.14 and higher; it should run anywhere Docker Desktop for Mac runs (Current Docker Desktop has deprecated macOS 10.13 High Sierra, but Docker Desktop versions prior to can still work with DDEV-Local on High Sierra.)
* Linux: Most Linux distributions which can run Docker-ce are fine. This includes at least Ubuntu 16.04+, Debian Jessie+, Fedora 25+. Make sure to follow the docker-ce post-install steps
* Windows 10 (all editions) with WSL2 (version 1903.1049, 1909.1049, 2004 or later)
* (Non-WSL2) Windows 10 Home, Pro, or Enterprise with Docker Desktop for Windows
Architecture Support
* AMD64 is supported on Windows 10 (with either traditional Windows or WSL2), macOS, and Linux.
* ARM64 machines are currently supported on Linux and in WSL2 in Windows ARM64 computers.
* Apple Silicon M1 (ARM64) is supported in v1.17-alpha1+ (edge versions).

Using DDEV alongside other development environments¶

DDEV by default uses ports 80 and 443 on your system when projects are running. If you are using another local development environment you can either stop the other environment or configure DDEV to use different ports. See troubleshooting for more detailed problem solving.

Installation¶

When upgrading, please run ddev poweroff and check the release notes for actions you might need to take on each project.

Docker Installation¶

Docker and docker-compose are required before anything will work with DDEV. This is pretty easy on most environments; see the docker_installation page to help sort out the details, especially on Windows and Linux.

Homebrew - macOS/Linux¶

For macOS (both amd64 and arm64) and Linux users, we recommend installing and upgrading via Homebrew (macOS) or Homebrew on Linux (Linux):

If you would like more frequent 'edge' releases then use brew install drud/ddev-edge/ddev instead.)

As a one-time initialization, run mkcert -install. Linux users may have to take additional actions as discussed below in 'Linux mkcert -install additional instructions'.

Later, to upgrade to a newer version of DDEV-Local, run:

Installation or Upgrade - Windows (WSL2)¶

This is the recommended installation method for all Windows users that are on Windows 10 1903.1049, 1909.1049, 2004 or higher If you don't have this version yet, or if you don't want to use WSL2, please follow the legacy instructions for Windows below.

All Windows 10 editions (including Windows 10 Home) support WSL2. Docker Toolbox support for DDEV has been removed. If you're already familiar with DDEV on Windows, you might have been using NFS for better filesystem performance. You won't need NFS anymore once you switch to WSL2, since it provides awesome filesystem performance out of the box.

The WSL2 install process involves:

Installing Chocolatey package manager (optional).
One time initialization of mkcert.
Installing WSL2, setting version 2 as the default version, and installing a distro like Ubuntu.
Installing or upgrading to the latest Docker Desktop for Windows with WSL2 enabled.
Installing DDEV inside your distro.

We'll walk through these in more detail. You may prefer other techniques of installation or may not need some steps, but this is the full recipe:

If you have previously installed Docker Toolbox, please completely uninstall Docker Toolbox.
Chocolatey: We recommend using Chocolatey for Chocolatey installing required Windows apps like mkcert. In an administrative PowerShell, Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
In an administrative PowerShell: choco install -y mkcert
In administrative PowerShell, run mkcert -install and answer the prompt allowing the installation of the Certificate Authority.
In administrative PowerShell, run the command setx CAROOT '$(mkcert -CAROOT)'; If ($Env:WSLENV -notlike '*CAROOT/up:*') { setx WSLENV 'CAROOT/up:$Env:WSLENV' }. This will set WSL2 to use the Certificate Authority installed on the Windows side.
Install WSL2. In an administrative PowerShell Enable-WindowsOptionalFeature -Online -FeatureName $('VirtualMachinePlatform', 'Microsoft-Windows-Subsystem-Linux') (Your computer will reboot.) (See detailed documentation.)
Download and install the WSL2 kernel from WSL2 kernel upgrade page.
Set the default WSL version to 2: wsl --set-default-version 2 You may be prompted to upgrade the WSL2 kernel.
Install a WSL2 distro from the Microsoft Store. We recommend Ubuntu. (You do not have to log in to the Microsoft Store, just 'X' out the dialog box requesting that.)
Docker Desktop for Windows: If you already have the latest Docker Desktop, configure it in the General Settings to use the WSL2-based engine. Otherwise install the latest Docker Desktop for Windows and select the WSL2-based engine (not legacy Hyper-V) when installing. Install via Chocolatey with choco install docker-desktop or it can be downloaded from download.docker.com. Start Docker. It may prompt you to log out and log in again, or reboot.
Go to Docker Desktop settings > Resources > WSL integration > enable integration for your distro (now docker commands will be available from within your WSL2 distro).
Double-check in PowerShell: wsl -l -v should show three distros, and your Ubuntu should be the default. All three should be WSL version 2.
Double-check in Ubuntu (or your distro): echo $CAROOT should show something like /mnt/c/Users/<you>/AppData/Local/mkcert
Check that docker is working inside Ubuntu (or your distro): docker ps
Optional: If you prefer to use the Windows ddev instead of working inside WSL2, install it with choco install -y ddev. The Windows ddev works fine with the WSL2-based Docker engine.
Open the WSL2 terminal, for example Ubuntu from the Windows start menu.
Install Homebrew: /bin/bash -c '$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)' (See https://brew.sh/.)
Add brew to your path as prompted, for example, echo 'eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv)' >> ~/.profile && source ~/.profile
brew install gcc && brew install drud/ddev/ddev
sudo apt-get update && sudo apt-get install -y xdg-utils to install the xdg-utils package that allows ddev launch to work.

That's it! You have now installed DDEV on WSL2. If you're using WSL2 for ddev (recommended), remember to run all ddev commands inside the WSL2 distro.

Make sure you put your projects in the Linux filesystem (e.g. /home/), not in the Windows filesystem (/mnt/c), because you'll get vastly superior performance on the Linux filesystem.

Note that nfs-mount-enabled (and running NFS) are not required on WSL2 because it's perhaps faster without NFS.

Installation or Upgrade - Windows (legacy)¶

If you use chocolatey (recommended), then you can just choco install ddev git from an administrative shell. Upgrades are just ddev poweroff && choco upgrade ddev.
A windows installer is provided in each ddev release (ddev_windows_installer.<version>.exe). Run that and it will do the full installation for you. Open a new git-bash or PowerShell or cmd window and start using ddev.
Most people interact with ddev on Windows using git-bash, part of the Windows git suite. Although ddev does work with cmd and PowerShell, it's more at home in bash. You can install it with chocolatey using choco install -y git.

Installation/Upgrade Script - Linux and macOS (ARM/ARM64 and AMD64 architectures)¶

Windows WSL2, Linux and macOS users can use this line of code to your terminal to download, verify, and install (or upgrade) ddev using our install script. Note that this works with both amd64 and arm64 architectures, including Surface Pro X with WSL2 and 64-bit Raspberry Pi OS. It also works with the new macOS Apple Silicon M1 machines.

The installation script can also take a version argument in order to install a specific version or a prerelease version. For example,

Later, to upgrade DDEV to the latest version, just run ddev poweroff and run the script again.

Manual Installation or Upgrade - Linux and macOS¶

You can also easily perform the installation or upgrade manually if preferred. DDEV is just a single executable, no special installation is actually required, so for all operating systems, the installation is just copying DDEV into place where it's in the system path.

ddev poweroff if upgrading
Download and extract the latest ddev release for your architecture.
Move ddev to /usr/local/bin: mv ddev /usr/local/bin/ (may require sudo), or another directory in your $PATH as preferred.
Run ddev to test your installation. You should see DDEV's command usage output.
As a one-time initialization, run mkcert -install, which may require your sudo password. Linux users may have to take additional actions as discussed below in 'Linux mkcert -install additional instructions. If you don't have mkcert installed, you can install it from https://github.com/FiloSottile/mkcert/releases. Download the version for the correct architecture and sudo mv <downloaded_file> /usr/local/bin/mkcert && sudo chmod +x /usr/local/bin/mkcert.

Installation via package managers - Linux¶

The preferred Linux package manager is Homebrew : brew install drud/ddev/ddev

We also currently maintain a package on Arch Linux (AUR)

As a one-time initialization, run mkcert -install, which may require your sudo password. See below for additional information.

Linux `mkcert -install` additional instructions¶

The mkcert -install step on Linux may provide you with additional instructions.

On variants of Linux you may be prompted for additional package installation to get certutil installed, but you can follow the instructions given by mkcert:

$ mkcert -install
Created a new local CA at '/home/username/.local/share/mkcert' 
Installing to the system store is not yet supported on this Linux  but Firefox and/or Chrome/Chromium will still work.
You can also manually install the root certificate at '/home/username/.local/share/mkcert/rootCA.pem'.
Warning: 'certutil' is not available, so the CA can't be automatically installed in Firefox and/or Chrome/Chromium! ⚠️
Install 'certutil' with 'apt install libnss3-tools' or 'yum install nss-tools' and re-run 'mkcert -install' 

(Note the prompt Installing to the system store is not yet supported on this Linux, which can be a simple result of not having /usr/sbin in the path so that /usr/sbin/update-ca-certificates can be found.)

Windows and Firefox `mkcert -install` additional instructions¶

The mkcert -install step on Windows does not work for the Firefox browser.
You need to add the created root certificate authority to the security
configuration by your self:

Run mkcert -install (you can use the shortcut from the start menu for that)
Run mkcert -CAROOT to see the local folder used for the newly created root
certificate authority
Open the Firefox settings
Enter certificates into the search box on the top
Click to Show certificates...
Select the tab Certificate authorities
Click to Import...
Go to the folder where your root certificate authority was stored
Select the file rootCA.pem
Click to Open