The Heroku provider is used to interact with the resources provided by Heroku Platform API and needs to be configured with credentials before it can be used.
Heroku is a fully-managed platform that gives you the simplest path to delivering apps quickly:
Development happens in the GitHub repo:
# Configure the Heroku provider
provider "heroku" {
api_key = var.heroku_api_key
}
# Create a new application
resource "heroku_app" "default" {
# ...
}
The Heroku provider offers a flexible means of providing credentials for authentication. The following methods are supported, listed in order of precedence, and explained below:
All authentication tokens must be generated with one of these methods:
heroku auth
command of the Heroku CLI🔐 See Secure Practices for help creating a safe API token.
⛔️ Direct username-password authentication is no longer supported by Heroku API.
Credentials can be provided statically by adding api_key
property
to the Heroku provider block:
variable "heroku_api_key" {
type = string
sensitive = true
}
provider "heroku" {
api_key = var.heroku_api_key
}
When the Heroku provider block does not contain an api_key
argument, the missing credentials will be sourced from the environment via the
HEROKU_API_KEY
environment variable:
provider "heroku" {}
$ export HEROKU_API_KEY="<heroku_auth_token>"
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
Credentials can instead be sourced from the .netrc
file in your home directory:
provider "heroku" {}
$ cat ~/.netrc
...
machine api.heroku.com
login <ignored, can be any value>
password <heroku_auth_token>
...
The directory containing the .netrc
file can be overridden by the NETRC
environment variable as described here.
The following arguments are supported:
api_key
- (Required) Heroku API token. It must be provided, but it can also
be sourced from other locations. See also Secure Practices.
email
- (Ignored) This field originally supported username-password authentication,
but has since been deprecated.
Instead, simply set an auth token in the api_key
property.
headers
- (Optional) Additional Headers to be sent to Heroku, as a string-encoded JSON object,
for example: {"X-Custom-Header":"yes","X-Custom-Header-Too":"no"}
. If not provided, it will be
sourced from the HEROKU_HEADERS
environment variable (if set).
customizations
- (Optional) Various attributes altering the behavior of certain resources.
Only a single customizations
block may be specified, and it supports the following arguments:
set_app_all_config_vars_in_state
- (Optional) Controls whether the heroku_app.all_config_vars
attribute
is set in the state file. Normally a snapshot of all config vars is stored in state, even though they are
not managed by Terraform, such as secrets set via heroku config
CLI, web dashboard, or add-ons like
Postgres' DATABASE_URL
. Set to false
to only track managed config vars in the state. Defaults to true
.
See also Secure Practices.
set_addon_config_vars_in_state
- (Optional) Controls whether the heroku_addon.config_var_values
attribute
is set in the state file. The attribute stores each addon's config vars in Terraform state. This means
sensitive add-on config vars, such as Postgres' DATABASE_URL
, are always accessible in the state.
Set to false
to prevent capturing these values. Defaults to true
.
See also Secure Practices.
delays
- (Optional) Delays help mitigate issues that can arise due to
Heroku's eventually consistent data model. Only a single delays
block may be
specified, and it supports the following arguments:
post_app_create_delay
- (Optional) The number of seconds to wait after an
app is created. Default is to wait 5 seconds.
post_space_create_delay
- (Optional) The number of seconds to wait after a
private space is created. Default is to wait 5 seconds.
post_domain_create_delay
- (Optional) The number of seconds to wait after
a domain is created. Default is to wait 5 seconds.
timeouts
- (Optional) Define a max duration the provider will wait for certain resources
to be properly modified before proceeding with further action(s). Only a single timeouts
block may be specified,
and it supports the following arguments:
addon_create_timeout
- (Optional) The number of minutes for the provider to wait for an addon to be
created/provisioned. Defaults to 20 minutes. Minimum required value is 10 minutes.