Building Docker Images with heroku.yml Is Generally Available

Listen to this article

Last October, we announced the ability for you to deploy pre-built Docker images to Heroku via Container Registry. Today, building Docker images with heroku.yml is generally available; you can now:

Use git push heroku master to build your Docker images on Heroku

to build your Docker images on Heroku Take advantage of review apps in Docker-based projects

For most teams, using containers in production requires you to spend time setting up and maintaining complex infrastructure. By using heroku.yml to build your Docker images, you get the power and flexibility of using Docker to package your app, combined with Heroku’s high-productivity developer experience, container orchestration, an add-ons ecosystem, and managed infrastructure.

To get started, simply reference your Dockerfiles in a heroku.yml file, set your app’s stack to container , and push your code to deploy:

$ cat heroku.yml # An example heroku.yml build: docker: web: Dockerfile run: web: bundle exec puma -C config/puma.rb

$ git push heroku master remote: Compressing source files... done. remote: Building source: remote: === Building web (Dockerfile) remote: Sending build context to Docker daemon 11.26kB remote: Step 1/2 : FROM alpine:latest … remote: Successfully built e3a5e126e300 remote: === Pushing web (Dockerfile) … remote: Verifying deploy... done.

For more detail, check out the building Docker images with heroku.yml Dev Center documentation.

With today’s release, your Docker-based projects can now take advantage of review apps, a powerful tool for team collaboration. Review apps allow team members to test code changes — before they are merged — on a live URL.

In the following screenshot, after a pull request is created on the project’s GitHub repo, a Docker build is triggered, and a new ephemeral Heroku app is created. The app can be shared with team members for review.

heroku.yml is a new, optional manifest that can be used to define your build. It includes 4 sections for specifying how an app should be set up, built, released, and run:

setup - Specify the add-ons and config vars you would like created at app provisioning

- Specify the add-ons and config vars you would like created at app provisioning build - Specify the Docker images to build

- Specify the Docker images to build release - Specify the release phase tasks to execute

- Specify the release phase tasks to execute run - Specify process types and the commands to run. Procfile is ignored.

In the following advanced example, heroku.yml is used to build multiple Docker images as well as reuse Docker images with multiple process types:

# Resources to provision on app creation setup: addons: - plan: heroku-postgresql as: DATABASE config: S3_BUCKET: my-example-bucket # Reference the Dockerfiles to build into Docker images build: docker: web: Dockerfile worker: worker/Dockerfile config: RAILS_ENV: development FOO: bar # Run a command on each release release: command: - ./deployment-tasks.sh # Use the worker image to execute the release command image: worker # The process types and commands to run run: web: bundle exec puma -C config/puma.rb worker: python myworker.py asset-syncer: command: - python asset-syncer.py # Use the worker image with this process type image: worker

If your team isn’t using Docker, you can also use heroku.yml with buildpacks.

With today’s release, combined with Container Registry, Heroku allows you to use the tools your know and love to package your apps, while benefiting from Heroku’s high-productivity developer experience, add-ons ecosystem, and managed infrastructure. Focus on building your app with Docker, without having to roll your own container orchestration infrastructure.