Last updated May 03, 2023

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.

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
montreal   Montreal, Canada         Private Spaces
mumbai     Mumbai, India            Private Spaces
oregon     Oregon, United States    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 the us 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.