anchor.diff:      image: tutum/memcached
     app:
       build: .
  +    working_dir: /app
       volumes:
         - .:/app
       depends_on:
  
positive.code:       MEMCACHE_SERVERS: memcache
  ```
  
  **NOTE:** The `Dockerfile` must include a `WORKDIR` directive matching the mount point of the app. So you would use `WORKDIR /app` in the example above.
  
  Mounting `.` (the directory of current build) as a volume in the container allows any changes from inside the container to be visible to the outside build agent, which is required if you want the agent to be able to access and upload artifacts created by the build.
  
  Another example of a production `docker-compose.yml` configuration is from the [buildkite-agent Golang source code](https://github.com/buildkite/agent):
  
  ```yml
  version: '2.1'
  services:
    agent:
      build: .
      working_dir: /go/src/github.com/buildkite/agent
      volumes:
        - ./:/go/src/github.com/buildkite/agent:cached
      environment:
        - BUILDKITE_BUILD_NUMBER
        - BUILDKITE_JOB_ID
  ```
  
  The above example has an additional volume: the `buildkite-agent` binary itself, so the build scripts can use the `buildkite-agent artifact` and `buildkite-agent meta-data` commands. It also passes through environment variables needed for the artifact command.
  
  ## Testing the config
  
  To test everything is set up correctly you can invoke the `docker-compose` command yourself on a development machine:
  
  ```bash
  docker-compose run app script/tests
  ```
  
  Once you've got everything working, you can configure your build pipeline and run it with Buildkite.
  
  ## Configuring the build step
  
  To run your steps in a container, we recommend using [plugins](/docs/agent/v3/plugins). If you want to use Docker without plugins, see [Using Docker without plugins](/docs/builds/docker-containerized-builds#using-docker-without-plugins)
  
  At the start of your `pipeline.yml`, add a step to build an image with the Docker plugin. In this example, we use the `docker-compose` plugin to prebuild the `app` image and upload it to a registry:
  
  ```yml
  steps:
    - name: "Docker Build"
      plugins:
        docker-compose#v2.0.0:
          build: app
          image-repository: index.docker.io/org/repo
  ```
  
  If you don't have a registry set up, [Docker Hub](https://hub.docker.com/) provides both public and private registries for free.  
  
  <div class="Docs__note">
  <p class="Docs__note__heading">Pinning plugin versions</p>
  <p>Specifying the version of your plugin using the <code>plugin-name#vx.x.x</code> format is recommended, to ensure that no changes are introduced without your knowledge.</p>
  </div>
  
  To run later steps in the image you have built, use the `plugins` attribute on command steps. This example runs a test suite concurrently in the `app` image that was built in the previous example:
  
  ```yml
  - name: "Docker Test %n"
    command: test.sh
    parallelism: 25
    plugins:
      docker-compose#v2.0.0:
        run: app
  ```
  
  For more examples and information on using this plugin, have a look at the [Docker Compose Plugin on GitHub](https://github.com/buildkite-plugins/docker-compose-buildkite-plugin).
  
  ## Adding buildkite-agent to the Docker group
  
  To allow buildkite-agent to use the Docker client you’ll need to ensure its user has the necessary permissions. For most platforms this means adding the `buildkite-agent` user to your system’s `docker` group, and then restarting the Buildkite Agent to ensure it is running with the correct permissions. See your platform’s [Docker installation instructions](https://docs.docker.com/installation/) for more details.
  
  ## Adding a cleanup task
  
  
negative.code: 
  <%= toc %>
  
  ## Overview
  
  To run your steps using Docker, we have two [plugins](/docs/agent/v3/plugins): the [Docker Compose plugin](https://github.com/buildkite-plugins/docker-compose-buildkite-plugin), and the [Docker plugin](https://github.com/buildkite-plugins/docker-buildkite-plugin).
  
  - the docker compose plugin gives you fine grained control over your docker configuration (need to use this one if you've got multiple containers or dependent services, use this if you need to build an image or have a docker-compose.yml file in your repo)
  - the docker plugin is for single container applications, less setup, no docker-compose.yml, can't build an image
  
  ## Creating a Docker Compose configuration file
  
  For most projects we recommend using [Docker Compose](https://docs.docker.com/compose/) as it allows each pipeline to define its own `docker-compose.yml` with dependent containers and environment variables to be passed through.
  
  Here's a example of a `docker-compose.yml` file for a Ruby on Rails application that depends on Postgres, Redis and Memcache:
  
  