anchor.diff:  
   Even though the buildkite agent cleans up the images after each run, inevitably over time your Docker host can fill up with a lot of unused images.
   
  -We recommend running [docker-gc](https://github.com/spotify/docker-gc) or similar tool on a daily basis.
  +Docker has released the [system prune](https://docs.docker.com/engine/reference/commandline/system_prune) command that will remove all unused containers, networks, and images from your environment. We recommend running either `docker system prune` or using a similar tool like [docker-gc](https://github.com/spotify/docker-gc) on a daily basis.
   
   ## Docker without Docker Compose
   
  
positive.code: 
  For Docker-based builds 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 Ruby on Rails application that depends on Postgres, Redis and Memcache:
  
  ```yml
  version: '2'
  
negative.code: Another example of a production docker-compose configuration is from the [buildkite-agent Golang source code](https://github.com/buildkite/agent):
  
  ```
  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
  
  