Skip Navigation
Show nav
Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
Hide categories

Categories

  • Heroku Architecture
    • Compute (Dynos)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Developer Tools
    • Command Line
    • Heroku VS Code Extension
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery & Integration (Heroku Flow)
    • Continuous Integration
  • Language Support
    • Node.js
      • Working with Node.js
      • Troubleshooting Node.js Apps
      • Node.js Behavior in Heroku
    • Ruby
      • Rails Support
      • Working with Bundler
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Background Jobs in Python
      • Python Behavior in Heroku
      • Working with Django
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Working with Maven
      • Working with Spring Boot
      • Troubleshooting Java Apps
    • PHP
      • PHP Behavior in Heroku
      • Working with PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
      • Migrating to Heroku Postgres
    • Heroku Key-Value Store
    • Apache Kafka on Heroku
    • Other Data Stores
  • AI
    • Model Context Protocol
    • Vector Database
    • Working with AI
    • Heroku Inference
      • Quick Start Guides
      • Inference API
      • Inference Essentials
      • AI Models
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
      • Single Sign-on (SSO)
    • Private Spaces
      • Infrastructure Networking
    • Compliance
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
  • Heroku Architecture
  • Regions

Regions

English — 日本語に切り替える

Last updated May 19, 2025

Table of Contents

  • Viewing available regions
  • Default regions
  • Specifying a region
  • Verifying an app’s region
  • Migrating existing apps
  • Add-ons and region support
  • Deploying
  • One-off dynos
  • Custom domains
  • Data residency

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. Both the Cedar and Fir Private Spaces runtimes share the same 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.

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.
  • Besides logs, all telemetry generated by your apps and by Heroku’s infrastructure stay within the Fir Space itself. For example, if you deploy an application into a Fir space within the Tokyo region, all telemetry data generated by your application and the Heroku platform stays inside the Tokyo region.
  • Builds for apps in Fir Private Spaces occur in the same space. Other apps’ builds occur in a shared space that only Heroku’s engineering team has access to.
  • 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.

Keep reading

  • Heroku Architecture

Feedback

Log in to submit feedback.

The Procfile Slug Compiler

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices