This page documents deployments using the next major version dpl v2, which currently is in a beta release phase. Please see our blog post for details. The current default version is dpl v1. Check dpl v1 documentation here.
Be sure to read the v2 deployment overview.
Travis CI can automatically deploy your Heroku application after a successful build.
For a minimal configuration, add the following to your
deploy: provider: heroku:git api_key: <encrypted api_key> edge: true # opt in to dpl v2
Alternatively, you can use
deploy: provider: heroku:git username: <username> password: <encrypted password>
Support for deployments to Heroku Git is in alpha. Please see Maturity Levels for details.
Known options #
Use the following options to further configure the deployment. Either
password are required.
||Heroku API key — secret, type: string|
||Heroku username — type: string, alias:
||Heroku password — secret, type: string|
||Heroku Git remote URL — type: string|
Shared options #
||Heroku deployment strategy — type: string, default:
||Heroku app name — type: string, default:
||Clean up build artifacts from the Git working directory before the deployment — type: boolean|
||Commands to execute after the deployment finished successfully — type: string or array of strings|
Environment variables #
All options can be given as environment variables if prefixed with
api_key can be given as
Securing secrets #
Secret option values should be given as either encrypted strings in your build
.travis.yml file) or environment variables in your repository
Environment variables can be set on the settings page of your repository, or
travis env set:
travis env set HEROKU_API_KEY <api_key>
In order to encrypt option values when adding them to your
travis encrypt <api_key>
--add to directly add it to your
.travis.yml file. Note that this command has to be run in your repository’s root directory:
travis encrypt --add deploy.api_key <api_key>
Specifying the application name #
By default, your repository name will be used as the application name.
You can set a different application name using the
deploy: provider: heroku # ⋮ app: <app_name>
Running commands #
In some setups, you might want to run a command on Heroku after a successful deploy. You can do this with the run option:
deploy: provider: heroku # ⋮ run: rake db:migrate
It also accepts a list of commands:
deploy: provider: heroku # ⋮ run: - rake db:migrate - rake cleanup
Take note that Heroku app might not be completely deployed and ready to serve requests when we run your commands. To mitigate this situation, you can add a
sleepstatement to add a delay before your commands.
Deploying branches to different apps #
In order to choose apps based on the current branch use separate deploy configurations:
deploy: - provider: heroku # ⋮ app: app-production on: branch: master - provider: heroku # ⋮ app: app-staging on: branch: staging
Or using YAML references:
deploy: - &deploy provider: heroku # ⋮ app: app-production on: branch: master - <<: *deploy app: app-staging on: branch: staging
Error Logs for Custom Commands #
Custom Heroku commands do not affect the Travis CI build status or trigger
Travis CI notifications, because Heroku’s CLI always exits
0, even if the command failed.
These add-ons have email notification systems that can be triggered when certain string matches occur in your Heroku logs. For example you could trigger an e-mail notification if the log contains “this and all later migrations canceled” or similar messages.
Restarting Applications #
Sometimes you want to restart your Heroku application between or after commands. You can easily do so by adding a “restart” command:
deploy: provider: heroku # ⋮ run: - rake db:migrate - restart - rake cleanup
Deploy Strategy #
Travis CI supports different mechanisms for deploying to Heroku:
- api: Uses Heroku’s Build API. This is the default strategy.
- git: Does a
git pushover HTTPS.
It defaults to api, but you can change that via the strategy option:
deploy: provider: heroku # ⋮ strategy: git
Using .gitignore on the Git strategy #
When you use any of the
git strategies, be mindful that the deployment will
.gitignore file matches something that your build creates, use
before_deploy to change
Pull Requests #
Note that pull request builds skip the deployment step altogether.