Introducing Experimental Distributed Application Bundles

Michael Friis

Jun 20 2016

The built-in orchestration features announced today with Docker 1.12 will revolutionize how IT teams build, ship and run containerized apps. With Docker 1.12, developers and ops now share a set of simple and powerful APIs, tools, and formats for building agile delivery pipelines that ship software from development through CI to production in the cloud with Docker for AWS and Azure.

To facilitate that revolution, we’re introducing Distributed Application Bundles—an experimental open file format for bundling up all the artifacts required to ship and deploy multi-container apps: a DAB contains a description of all the services required to run the application and details images to use, ports to expose, and the networks used to link services.

Once you start using the service feature to run replicated, distributed, and load balanced services on Docker 1.12 swarms (or if you’ve used Docker Compose for deployments in the past), you’ll probably realize that starting and stopping individual containers is not that efficient. What matters is reliably deploying apps, and that requires orchestrating the deployment and linking of many containers representing databases, queue systems, and app containers potentially built from several different codebases.

The Distributed Application Bundle (DAB) helps you do that. Developers and CI systems can build and test containerized apps and then wrap all the app artifacts into stable .dab files. Ops teams can take those .dab artifacts and deploy exactly what the developers intended and what the CI systems tested, again and again, with zero variability.

Developers can use Docker Compose 1.8 to create DABs from docker-compose.yml files and ops can use Docker 1.12 to deploy apps by creating stacks of services from DABs.

To create a DAB, a developer or CI system uses Compose to package up an app:

$ docker-compose build
$ docker-compose push
$ docker-compose bundle
Wrote bundle to example.dab

The ops team can then deploy the DAB on Docker 1.12:

$ docker deploy example
Loading bundle from example.dab
Creating network app-network
Creating service example-db
Creating service example-web

Dockerfiles and Docker images are good analogies for understanding the usefulness of DABs: A Docker image can be created from a Dockerfile and then deployed millions of times with the exact same outcome because the image contains all libraries and dependencies required for it to run. In the same way, an app described with a docker-compose.yml file can now be bundled into a DAB and the DAB deployed repeatedly with a predictable outcome.

The example above shows how a single docker-compose.yml file can be packaged into a bundle. The DAB format is fully independent of Docker and Docker Compose, and can be used to package non-dockerized software. DABs can also be used to package multiple codebases, each with their own docker-compose.yml file, into a single bundle describing a complex stack. This is potentially useful for bundling micro-service deployments and could make them easier to configure and deploy.

In addition to making deployments stable and repeatable, DABs also take away the tedium of creating many individual services comprising a complex app. This makes them a convenient abstraction on top of the service concept introduced in Docker 1.12.

DAB is a JSON-based format. Here’s a very simple example representing an app consisting of a database and a web-frontend:

  "services": {
    "db": {
      "Image": "postgres@sha256:f76245b04ddbcebab5bb6c28e76947f49222c99fec4aadb0bb1c24821a9e83ef",
      "Networks": [
    "web": {
      "Image": "gordon-the-turtle/web-frontend@sha256:df16d85fba95eef19d2d53f1ee5367c22aa4956fab0977ed9a187d69ec15dab0",
      "Networks": [
  "version": "0.1"

Specifying the images is optional but highly recommended to make the DAB a fully stable deployment artifact. Check out the documentation for all the details on DABs and stacks.

We’re excited about the experimental distributed application bundle format, and we’re looking forward to seeing how you’ll use it in your software delivery pipelines. If you’re building developer tools, CI/CD tools or other components for shipping software, we’d love to get in touch and see how we can help you integrate support. You can contribute issues and improvements on the Docker and Compose repos and discuss the file format on the Docker Forums.


7 thoughts on “Introducing Experimental Distributed Application Bundles

  1. Can you elaborate how data volumes will be factored when a DAB is deployed, data sharing between services in a DAB, migration of services and their data.

    • Michael Friis

      Michael Friis

      Volumes are a deployment environment specific concern. We're trying to work out the best design for this. It could be that you maintain per-environment configs that specify scale, plugins, port-mappings and so on.

  2. I use docker 1.12 on ubuntu, Can I use Distributed Application Bundles ? I see it is not exist docker deploy command….

    • Although Docker Swarm Mode is available in 1.12 Stable Channel (you can create services, scale, etc) DAB seems to be still in an experimental phase (1.12.1) therefore you will only be available to execute this new functionality if you download the experimental build. To do that go to the download page and select "Beta Channel" instead of "Stable Channel". In Mac, for example you can easily choose to download the Beta dmg file here: You should find something similar but with Ubuntu.

  3. Hi Michael,

    Can you elaborate on how services belonging to different stacks could communicate to each other?


  4. Is the intention to continue supporting everything available in the docker-compose.yml (version 2), including volumes, alias, depends_on etc? I'm currently deploying distributed micro services on Docker 1.11 with docker-compose and Swam but am unable to make the move to 1.12's Swarm mode. My hope is 1.13 will allow be to reuse my existing docker-compose.yml files using the method you have outlined here.

  5. How do I deploy my distributed application (built using microservices or the like) that will be run on multiple nodes (in a public or private or hybrid cloud) having fail-over, replication, load-balancing features using this feature?. As you could see, there is a lot of container duplicity here or several containers here as well. The problem is how do I update a single Docker image and run it as a container while releasing a new feature in my distributed application?. Ideally (world is not flat so, I would not expect idealism), I would want my great Ops-guys to do this with a single click from some 'container-manager' software portal of the cloud vendor.

    Note: I am not using any of the popular or otherwise 'container orchestration' software. I would expect our customer to use Docker container (at least that is what we support now, let us say!).

Leave a Reply