Arnaud Porterie

Docker’s Experimental Binary

Arnaud Porterie

Docker is an incredibly fast-moving project. As the project grows and acquires users, making changes becomes more complex. In particular, any patch that impacts user experience is a tough call. Each feature that Docker ships is immediately adopted by hundreds or thousands of users.

We’ve seen on other projects, it’s quite common to distribute different flavors of an application, some of which move faster than others, and some of which might be less proof-tested than others.

Today, we add one such flavor by introducing Docker’s experimental binary.


About the Docker experimental binary

Docker’s experimental binary gives you access to bleeding edge features that are not in, and may never make it into, Docker’s official release.  An experimental build allows users to try out features early and give feedback to the Docker maintainers.  In this way, we hope to refine our feature designs by exposing earlier to real-world usage.

In all cases, experimental features have gone through the same level of refining and quality control than any code that makes it into Docker: the difference is that the user interface and APIs may change.

Network and volume plugins are the very first experimental features introduced: go read their documentation and give it a try!



How can I try the experimental binary?

Unlike the regular Docker binary, the experimental channels is built and updated nightly on From one day to the next, new features may appear, while existing experimental features may be refined or entirely removed.

Each experimental feature is documented in a dedicated experimental section.  This section explains the feature’s function and design goals. Because your feedback is essential to refine and decide on a feature’s future, you will also find links to GitHub issues where you can leave your comments, look for reported problems, or report on your experience.


Geek out: How we build our experimental binary

The experimental binary is built from Docker’s regular master branch using a slightly different compilation command line. A feature is marked as experimental by segregating either parts or all of its code using Golang’s build constraints mechanism and conditional compilation. The question of how much feature code should be conditionally built is an interesting one that typically answered on a case-by-case basis. At the bare minimum, the command-line and API elements users can use to access a feature drive the experimental buildtag.

For example, we used this strategy in the case of volume drivers, a recently introduced experimental feature. In that case, the vast majority of the feature code is actually in mainline. This is  acceptable as long as we have a sufficient level of confidence that the feature won’t negatively impact stability or performance of Docker’s official release in any way.

From an open-source perspective, the very nature of experimental features also makes it important that reverting always remains an option. Reverting could become challenging if subsequent patches are built on top of experimental code.

A key element in our build design was consideration of Golang build constraints. They are stricly file-based, and do not allow for fine-grained conditional compilation like, for example, C-derived languages allow with inline #ifdef directives. In other words, the unit of “compile-time branching” can only either be the function or the interface, not the statement or even the expression. This restriction is both an encouragement for better code separation, and a strong constraint to cope with when attempting to isolate a particular code path.

Finally, we also have continuous integration on our experimental build to ensure that no incoming patch merged to master can break the experimental build.

So – want to have a go living on the bleeding edge? Head over to to try out the experimental release. If you have any feedback on any of the new features in the release, open a thread on the mailing list or add comments on the associated GitHub issues.



Learn More about the Docker News from DockerCon 2015

Join our next Docker online meetup recapping all of the news from DockerCon including demos of the latest features of Docker 1.7. The meetup is on Monday, June 29 at 10:00 PDT / 19:00 CEST – click here to register!



Learn More about Docker



One thought on “Docker’s Experimental Binary

Leave a Reply