CLI Usage
Last updated March 13, 2023
Running heroku help displays a usage summary:
Usage: heroku COMMAND
Help topics, type heroku help TOPIC for more details:
access manage user access to apps
addons manage add-ons
apps manage apps
authorizations OAuth authorizations
buildpacks manage the buildpacks for an app
certs a topic for the ssl plugin
ci run an application test suite on Heroku
clients OAuth clients on the platform
config manage app config vars
domains manage the domains for an app
drains list all log drains
features manage optional features
git manage local git repository for app
keys manage ssh keys
labs experimental features
local run heroku app locally
logs display recent log output
maintenance manage maintenance mode for an app
members manage organization members
notifications display notifications
orgs manage organizations
pg manage postgresql databases
pipelines manage collections of apps in pipelines
plugins manage plugins
ps manage dynos (dynos, workers)
redis manage heroku redis instances
regions list available regions
releases manage app releases
run run a one-off process inside a Heroku dyno
sessions OAuth sessions
spaces manage heroku private spaces
status status of the Heroku platform
teams manage teams
The commands are divided into two types: general commands and app commands.
General commands
General commands operate on your Heroku account as a whole, and are not specific to a particular app. For instance, to get a list of apps you created or are a collaborator on:
$ heroku apps
=== user@example.org Apps
example
example2
=== Collaborated Apps
collabapp owner@example.org
App commands
App commands are typically executed from within an app’s local git clone.
The app name is automatically detected by scanning the git remotes for the
current working copy, so you don’t have to specify which app to operate on
explicitly. For example, the heroku apps:info command can either be called with --app or be executed without any
arguments inside the working copy:
$ cd example
$ heroku apps:info
=== example-app-69977
Auto Cert Mgmt: false
Dynos:
Git URL: https://git.heroku.com/example-app-69977.git
Owner: your@emailaddress.com
Region: us
Repo Size: 0 B
Slug Size: 0 B
Stack: heroku-18
Web URL: https://example-app-69977.herokuapp.com/
If you have multiple heroku remotes or want to execute an app command outside of a local working copy, you can specify the remote name or an explicit app name as follows:
$ heroku apps:info --app example
$ heroku apps:info --remote production
Alternatively, the app name can be specified by setting the HEROKU_APP environment variable.
Using an HTTP proxy
If you’re behind a firewall that requires use of a proxy to connect with external HTTP/HTTPS services, you can set the HTTP_PROXY or HTTPS_PROXY environment variables in your local developer environment, before running the heroku command.
If you get the error UNABLE_TO_GET_ISSUER_CERT_LOCALLY or ECONNREFUSED this is likely the reason.
For example, on a Unix system you could do something like this:
$ export HTTP_PROXY=http://proxy.server.com:portnumber
or
$ export HTTPS_PROXY=https://proxy.server.com:portnumber
$ heroku login
On a Windows machine, either set it in the System Properties/Environment Variables, or do it from the terminal:
> set HTTP_PROXY=http://proxy.server.com:portnumber
or
> set HTTPS_PROXY=https://proxy.server.com:portnumber
> heroku login
This can go in your ~/.bashrc (or equivalent) to prevent running this every time you open a new shell session.
If your company’s internet requires the use of a MITM proxy, you might get a SELF_SIGNED_CERT_IN_CHAIN error . You’ll need to set NODE_EXTRA_CA_CERTS to the file location of the proxy’s Certificate Authority (CA) certificate in pem format. Or if issued the self-signed certificate directly, set SSL_CERT_FILE or SSL_CERT_DIR to a file/directory containing the MITM certificate.
$ export NODE_EXTRA_CA_CERTS=/path/to/ca_cert.pem
$ heroku whoami