heroku container push and release: Deploy Images
heroku container:push builds and pushes a Docker image to the Heroku registry, and heroku container:release promotes it to run the dyno.
Container deploys are a two-step push then release. In CI you authenticate the registry with an API key and target the app explicitly.
What it does
heroku container:push PROCESS builds the Dockerfile and pushes the image to registry.heroku.com for the app's process type (e.g. web). heroku container:release PROCESS then swaps the running dyno to the new image. heroku container:login authenticates Docker to the registry.
Common usage
# HEROKU_API_KEY authenticates non-interactively
export HEROKU_API_KEY=xxxxxxxx
heroku container:login
heroku container:push web --app my-app
heroku container:release web --app my-appOptions
| Command / flag | What it does |
|---|---|
| container:push <process> | Build and push the image for a process type |
| container:release <process> | Promote the pushed image to the dyno |
| container:login | Authenticate Docker to the Heroku registry |
| --app <name> | Target Heroku app |
| --recursive | Push images from nested Dockerfiles |
| HEROKU_API_KEY | API key for non-interactive auth |
In CI
Set HEROKU_API_KEY as an env var; both the CLI and container:login use it, so no interactive heroku login is needed. Always pass --app, and remember the deploy is not live until container:release runs after the push.
Common errors in CI
"Invalid credentials provided" or "Your API key is invalid" means HEROKU_API_KEY is missing or wrong. "denied: requested access to the resource is denied" on push means container:login did not run. "Couldn't find that app" means a wrong --app. A push that succeeds but does not go live means container:release was skipped.