Heroku Private Spaces
Last updated 22 September 2016
Table of Contents
This feature is currently available in Heroku Enterprise.
Private Spaces are dedicated environments for running dynos and certain types of add-ons enclosed within an isolated network. Access to apps in a Private Space can be controlled at the network level. Outbound requests from apps in a Private Space originate from a set of stable IP addresses, which allows you to securely communicate with IP white-listed services on-premise or on other networks. Private Spaces enable you to build and run Heroku apps that meet strict requirements for data protection and change control as commonly required by corporate and regulatory governance standards.
You can deploy to Private Spaces with the familiar
git push heroku master command or take full advantage of Heroku Pipelines. The powerful governance and security features provided by Private Spaces do not change the standard Heroku developer experience.
Private Space management
Only organization administrators can perform management functions such as creating, destroying, and changing settings on Private Spaces. All organization members can view details about Private Spaces in the organization.
Private Spaces can be created in the following regions:
|oregon||Oregon, United States|
|virginia||Virginia, United States|
Sydney, Australia is now available as a Private Spaces region in beta. Contact your Salesforce account representative if you’re interested in trying it out.
To create a Private Space in a given region, specify the location when creating the space.
The region cannot be changed after the Private Space is created. All apps created in a Private Space will be in the same region as the space.
Not all add-ons are available in all regions.
Create a Private Space
Only organization administrators can create a new Private Space.
To create a Private Space using Dashboard, click the Spaces tab inside your organization and click “Create new Private Space”. When creating the Private Space, you can optionally choose a region (geographic location) for your apps and data services. When you fill out the form and click “Create Private Space” a Space will be created. This may take up to ten minutes.
To create a Private Space using the Heroku CLI, use the
$ heroku spaces:create my-space-name --org my-org-name Creating space my-space-name in organization my-org-name... done === my-space-name Organization: my-org-name Region: virginia State: allocating
To create a Private Space in a particular region, specify the
--region option with the region’s name from the list of regions. For example:
$ heroku spaces:create my-space-name --org my-org-name --region tokyo Creating space my-space-name in organization my-org-name... done === my-space-name Organization: my-org-name Region: tokyo State: allocating
Creating a new Private Space can take a few minutes. To track its status, use the
$ heroku spaces:wait my-space-name Waiting for space my-space to allocate... done
View information about a Private Space
All organization members can view information about all of the Private Spaces in an organization.
In Dashboard, click the Spaces tab inside your org. The Space info displays the organization to which the Space belongs, as well as the current state of the Space. The
allocating state indicates that the Space is being set up and is not yet operational. When it becomes operational, the state will change to
In the Heroku CLI, use the
$ heroku spaces:info --space my-space-name === my-space-name Organization: my-org-name Region: tokyo State: allocating
Trusted IP ranges
Only organization administrators can manage trusted IP ranges for a Private Space.
Each Private Space has a set of trusted IP ranges, with each range represented in CIDR block notation (for example, 192.0.2.0/24). Only clients originating from one of these trusted IP ranges can access web processes running in the Private Space. Use trusted IP ranges to restrict traffic to apps that come from your corporate network or from a CDN service that proxies traffic for your apps. The trusted IP ranges only restrict access to applications in the Private Space. They do not control from which source IP ranges you can execute CLI commands or connect to Dashboard.
Trusted IP ranges can be managed in Dashboard by opening the Settings tab for a Private Space.
Each Private Space is currently limited to 20 Trusted IP ranges.
List current trusted IP ranges for a Private Space using the CLI:
$ heroku trusted-ips --space acme-prod === Trusted IP Ranges 192.0.2.0/26 192.0.2.64/26
Add a new range using the CLI:
$ heroku trusted-ips:add 192.0.2.128/26 --space acme-prod Added 192.0.2.128/26 to trusted IP ranges on acme-prod ▸ WARNING: It may take a few moments for the changes to take effect.
Stable outbound IP addresses
All organization members can view the list of stable outbound IP addresses for a Private Space.
All outbound traffic from apps in a Private Space will originate from a small, stable list of IP addresses that are dedicated to the space. This allows you to use IP whitelisting to secure services being accessed by apps in the space. For example, you can configure a web services gateway in your corporate data center to only allow access from the IP addresses assigned to the Private Space. By using this in combination with TLS and application level authentication tokens, you get an extra level of security for protecting resources in your corporate data center.
You can find the stable outbound IP addresses for a Space on the Settings tab for the Space in Dashboard. You can also use the CLI:
$ heroku spaces:info --space acme-prod === acme-prod ID: 12345678-ed4a-4e96-b998-3fcb499439e0 Organization: acme Region: virginia State: allocated Outbound IPs: 192.0.2.2, 192.0.2.3, 192.0.2.4, 192.0.2.5 Created at: 2015-08-07T16:16:56Z
Destroy a Private Space
Only organization administrators can destroy a Private Space. Private Spaces that contain applications or other resources cannot be destroyed. Apps must be explicitly deleted before destroying a Private Space.
In the Heroku dashboard, click “Space Settings” and choose “Delete Space”.
In the Heroku CLI, use the
$ heroku spaces:destroy --space my-space-name Destroying space my-space-name... done === my-space-name Organization: my-org-name State: deleting
Managing apps in Private Spaces
A Private Space represents a trust boundary within which your organization can deploy and manage apps that handle sensitive data. Therefore, the ability to create apps in a Private Space is constrained to organization administrators and those who have been granted the “app creation” permission for a particular Space. Once an app has been created, the administrator can give other members additional access to the app using fine-grained access controls.
Create an app in a Private Space
The only users who can create apps in a Private Space are:
- organization administrators
- organization members to whom an administrator has granted the “app creation” permission for the Space. (Which can be done in the Heroku Dashboard by clicking on the Space and then clicking Access.)
In the Heroku Dashboard, click on a Space and choose “Create New App”.
In the Heroku CLI use the
$ heroku create my-space-app --space my-space-name Creating my-space-app in space my-space-name... done, stack is cedar-14 https://my-space-app.herokuapp.com/ | https://git.heroku.com/my-space-app.git
After the app is created, you can grant other organization members access using one of several app permissions. Only members who are trusted to access any sensitive data protected by the space should be granted more than view permissions. All other members, who may develop on the app but who do not need production access, should only be granted access to staging and development environments.
Deploy an app in a Private Space
Code can be deployed (pushed) to Private Space apps in the same ways as with Common Runtime apps such as by using
git push heroku master or GitHub.
About delays and downtime during new Private Space app releases
The first time an app is deployed (pushed) to a Private Space, it can take several minutes for the app to become available because of the time needed to set up the underlying dedicated infrastructure (e.g., routing, DNS, and the dynos).
For subsequent releases (code deployments or config var changes) there is a much shorter delay, and users may experience little to no downtime. There may be brief downtime if there is only one dyno for the app. If there are multiple dynos, zero downtime is possible. This is because of a Private Spaces feature called rolling deploys.
Rolling deploys is analogous to Preboot on the Common Runtime. Both enable zero downtime during new releases. Preboot does this by ensuring that new web dynos are started (and receiving traffic) before the existing ones are terminated. Rolling deploys does this by stopping and changing only 25% (rounded up) at a time of the existing dynos in a formation, while the remaining dynos handle requests. The effect is that all requests are handled (no user downtime) while the new release is pushed gradually to the entire formation.
To be more precise, because of rolling deploys, there will be zero downtime during a new release for Private Space app if:
- the app has been deployed at least once and is running AND
- the app has at least two dynos and is not at capacity; that is, if it has enough dynos that it can still service requests with 25% (rounded up) of its dynos missing AND
- any databases attached to the app are not incurring schema changes and are compatible with both the old and new app release (forwards and backwards compatible)
Scaling an existing app in a Private Space does not incur downtime (as long as there is enough capacity to handle the existing load). Changing the dyno type does incur a short downtime, under some circumstances, while the new dyno types are created and traffic is switched over.
Maintenance Mode is not currently supported by Spaces.
List apps in a Private Space
All organization members can view all apps in the Private Space.
$ heroku apps --space my-space-name === Apps in space my-space-name my-space-app-1 my-space-app-2
View info about an app in a Private Space
All organization admins can view all apps in the Private Space.
$ heroku info --app my-space-app === my-space-app Collaborators: email@example.com Git URL: https://git.heroku.com/my-space-app.git Owner: my-org-name Region: tokyo Space: my-space-name Stack: cedar-14 Web URL: https://my-space-app.herokuapp.com/
Destroy an app in a Private Space
Organization admins and members who have manage permission on an app can destroy it.
$ heroku apps:destroy -a my-space-app Destroying my-space-app (including all add-ons)... done
Adding custom domains and SSL
Only organization administrators and members who have manage permission on an app can add custom domains and manage SSL.
SSL and custom domains for apps in Spaces are handled similarly to apps in the Common Runtime with a few important exceptions:
- Apps in Private Spaces must use a custom domain and SSL Certificate to enable HTTPS. The default app domain (e.g. http://example.herokuapp.com) will work with HTTP, but will not work with HTTPS. If your app automatically redirects HTTP requests to your HTTPS URL, you will not be able to access your app using the default app domain. In order to use the default app domain, you will need to disable the redirection for hosts like
- Apps in Private Spaces currently require TLS connections to use the SNI extension. Older clients that do not send the SNI extension will not be able to connect to a Private Space App using https.
- Once you have purchased and configured a custom domain, and purchased an SSL certificate, you can skip the step of running
heroku addons:create ssl:endpoint. (The Heroku SSL endpoint comes for free on apps in Private Spaces.)
Scaling and One-Off Dynos
Scaling your formation follows the same pattern within Spaces as with the Common Runtime. For example:
$ heroku ps:scale web=2 worker=1
“One-off” dynos are also possible via
$ heroku run bash Running bash... ▸ WARNING: Warning: Dynos can take up to a few minutes to be provisioned in Private Spaces.
Scaling and one-off dynos require that a new dyno is provisioned and launched within your Space. This process takes a few minutes to complete.
Add-ons and Private Spaces
All add-on providers offer plans which are compatible with apps running on the Common Runtime and are available in US, EU, or both. Some add-on providers have chosen to offer plans that are compatible with the Heroku Private Spaces Runtime. These Private Spaces regions are: Virginia, Oregon, Frankfurt, and Tokyo.
If you attempt to provision an add-on to an app in a Heroku Private Space via the Dashboard and that add-on is not available to that app’s Private Spaces region, you will see a message saying so.
Some add-ons offer plans that are compatible with Private Space regions, even though they operate outside the Private Space. This means that network traffic between your private dyno and the add-on resource travels across the public Internet. You can add these add-ons to apps running in a Private Space as you would normally for our Common Runtime:
$ heroku addons:create newrelic:wayne -a appname Creating newrelic-cubic-72448... done, (free) Adding newrelic-cubic-72448 to appname... done Setting NEW_RELIC_LICENSE_KEY, NEW_RELIC_LOG and restarting appname... done, v80 Use `heroku addons:docs newrelic` to view documentation.
Some add-ons of type “datastore” are compatible with Private Spaces regions. They can be provisioned through the CLI with the
addons:create command, or they can be provisioned in the Dashboard. Either way, you will have to confirm that you understand that this use of a data store not contained within the Private Space network boundary is explicitly intended; that using this add-on plan will send data over the public Internet.
To provision from the CLI you must follow the confirmation prompt:
$ heroku addons:create <addon name> -a appname ! This add-on is not automatically networked with this Private Space. ! To proceed, type "appname" or re-run this command with --confirm appname
For information on Heroku add-on credits and overage payments mechanisms, see the Heroku Enterprise documentation
Add-ons Within Private Spaces
Some add-ons are available in Private Spaces. This means that all network traffic between dynos and the add-on resource stays within the private network of the space, and the add-on resource does not have to be exposed on the public Internet.
Heroku Postgres and Heroku Redis are the only add-ons that are created inside Heroku Private Spaces. When you select a Heroku Postgres or Heroku Redis private plan for an app in a Private Space, the resource will be automatically created in the same region as the Heroku Private Space and peered to the Heroku Private Space.
To create a Heroku Postgres instance inside your Heroku Private Space, you must select a
private-4 plan or above. Since this Add-On will be automatically created inside your Space, confirmation is not required.
$ heroku addons:create heroku-postgresql:private-4 -a your-private-app-name
It is possible to provision Heroku Postgres and Heroku Redis plans outside of your Space. Provision by specifying app, plan, and region using the
$ heroku addons:create heroku-postgresql:standard-4 --region=us -a your-private-app-name
You will be asked to confirm the addition of the plan via the CLI.
! This add-on is not automatically networked with this Private Space. ! To proceed, type "appname" or re-run this command with --confirm appname
Migrate apps and data to or from a Private Space
There is no automated feature, at this time, to migrate apps and data to or from a Private Space, but it can be done manually. You should first back up and migrate the database(s), if any. App code should then be re-pushed to the destination. You should also consider differences in the way Private Spaces operate and whether any add-ons the app uses will work or need to be configured differently in the the destination. For instance, SSL for apps in Private Spaces works slightly differently.