Regions
Last updated August 28, 2023
Table of Contents
Heroku applications can be deployed in various geographic regions. The regions available for a particular app depend on whether the app is deployed to the Common Runtime or to a Private Space.
For apps in the Common Runtime, you specify a region when you create the app. For apps in Private Spaces, the region is set when you create the Private Space itself. Each Private Space exists in a single region, and all applications in the Private Space run in that region.
Specifying an app’s region does not guarantee restriction of data residency for Heroku products, services, and add-ons to that region. See Data residency for more information.
Viewing available regions
Use the heroku regions
command to view the list of available regions:
$ heroku regions
ID Location Runtime
───────── ─────────────────────── ──────────────
eu Europe Common Runtime
us United States Common Runtime
dublin Dublin, Ireland Private Spaces
frankfurt Frankfurt, Germany Private Spaces
london London, United Kingdom Private Spaces
montreal Montreal, Canada Private Spaces
mumbai Mumbai, India Private Spaces
oregon Oregon, United States Private Spaces
singapore Singapore Private Spaces
sydney Sydney, Australia Private Spaces
tokyo Tokyo, Japan Private Spaces
virginia Virginia, United States Private Spaces
You can also filter the list to show only Common Runtime or Private Spaces regions by running heroku regions --common
or heroku regions --private
.
Heroku exposes more detailed information about available regions in the Platform API. For example, if you need to know which infrastructure provider is used for the Frankfurt region, you can make a direct API query:
$ curl -n -X GET https://api.heroku.com/regions/frankfurt -H "Accept: application/vnd.heroku+json; version=3"
{
"country":"Germany",
"created_at":"2015-08-20T01:37:59Z",
"description":"Frankfurt, Germany",
"id":"37095377-0fed-41e5-b2db-778818d362aa",
"locale":"Frankfurt",
"name":"frankfurt",
"private_capable":true,
"provider":{
"name":"amazon-web-services",
"region":"eu-central-1"
},
"updated_at":"2015-08-20T01:37:59Z"
}
The result indicates that the Frankfurt region maps to the Amazon Web Services eu-central-1 region.
Default regions
Apps in the Common Runtime are created in the us
region unless a different region is specified.
Private Spaces are created in the virginia
region unless a different region is specified.
Specifying a region
To specify a region when creating the app in the Common Runtime, provide the --region
flag in your heroku create
command:
$ heroku create --region eu
Creating calm-ocean-1234... done, region is eu
http://calm-ocean-1234.herokuapp.com/ | git@heroku.com:calm-ocean-1234.git
Git remote heroku added
If you create an app in a Private Space, its region is always the same as the Private Space’s region. See Private Spaces for more information.
Verifying an app’s region
To verify an app’s region, check the Region
value returned by the heroku info
command:
$ heroku info
=== calm-ocean-1234
Git URL: git@heroku.com:calm-ocean-1234.git
Owner Email: user@test.com
Region: eu
Repo Size: 164M
...
Migrating existing apps
To switch regions for existing apps in the Common Runtime, you must redeploy and set up your apps in the new region. There is no migration option.
If you are using Private Spaces, see the Migrate Apps section of the Private Spaces article.
Add-ons and region support
Add-ons that support your app’s region are provisioned in that region by default. Provision them as you normally would:
$ heroku addons:create heroku-postgresql
If an add-on doesn’t support your app’s region and it doesn’t require a low-latency connection to your app, it is provisioned in the default region.
If an add-on is latency-sensitive and is not available in your app’s region, provisioning will fail:
$ heroku addons:create cloudcounter
Adding cloudcounter on calm-ocean-1234... failed
! This app is in region eu, cloudcounter:basic is only available in region us.
You can find add-ons that support your app’s region in the Add-on Runtime Availability reference.
Deploying
Deploying a new release of your app never affects its region. After an app is created, all deploys to it will occur in the originally specified region.
One-off dynos
One-off dynos run in the same region as the rest of the app. This is also true of services (such as Heroku Scheduler) that provision one-off dynos to execute jobs.
Custom domains
Custom domain configuration is region-agnostic. Use the heroku domains
commands to manage custom domains.
Data residency
Dynos and databases reside physically in the region where you create them. However, Heroku consists of a number of additional services that are not always located in the same region.
Consider the following aspects of Heroku’s architecture to understand how data might be transmitted and stored geographically:
- No guarantees are made about the physical location of Heroku’s control surface APIs, through which all CLI commands and the management of your applications occur.
- Logs for the Common Runtime are routed in the same region the app is running within. For example, logs for an app in the
us
region gets routed through theus
infrastructure. - Logs for apps in Private Spaces stay within the same region as the space itself. For example, logs for an app in a Tokyo space routes through the infrastructure in Tokyo. You can deploy apps with strict compliance requirements in Shield Private Spaces, which uses Private Space Logging to route logs instead of Logplex.
- Heroku does not control where add-on providers store data. Contact add-on providers directly for more information.
- For more details on data residency in Heroku Postgres, please see the Data Residency section within the Heroku Postgres documentation.
See the Salesforce Infrastructure & Sub-processors document for the list of sub-processors Heroku uses and the list of countries where Heroku data is stored and processed.