Table of Contents

This article explains the differences between Heroku Redis provisioning, plans, and connections when used in Private Spaces as compared with using Heroku Redis in the Common Runtime.

Heroku Private Spaces are dedicated environments for running applications
within an isolated network. This means that every part of the application stack,
including the dyno, data stores, and third party add-ons are contained within this
environment.

Heroku Redis can run within a Private Space, with the same developer experience as on the Common Runtime. Many of the same CLI commands and web interfaces will work for private Heroku Redis instance.

Private Heroku Redis plans are not accessible to applications at build-time. We advise you to eliminate the build time dependency on your private data store, use a public Heroku Data plan, or contact support for guidance.

Provisioning

Heroku Redis has a series of plans that are only meant for Private Spaces. The private
tier plans are the only plans that can be provisioned inside the isolated
network environment. If an attempt is made to create an instance from the premium tier, that request will fail.

Create a new instance

Many buildpacks will create a Redis instance as part of the build process. If
the application that’s being created is within a Private Space, unless a Redis instance already exists for that application, the lowest available private plan
will be used when creating the instance. For a list of the currently available
plans, see the plans section.

Private Heroku Redis instances can be provisioned via the CLI:

$ heroku addons:create heroku-redis:private-7 -a private-sushi

Only plans in the private tier of Heroku Redis can be created inside a
Private Space.

Depending on the region and the type of database being created, the provisioning
process can take up to 10 minutes before the instance is available for use.

Plans

Heroku Redis offers a set of plans for Private Spaces. The private tier
is designed for production applications and includes:

Region support

Fork support

Metrics published to application log stream

High availability

Plan Name

Provisioning Name

Memory Limit

Connection Limit

Monthly Price

Private7

heroku-redis:private-7

7 GB

5000

$900

Private9

heroku-redis:private-9

10 GB

5000

$1750

External connections

Unlike the Heroku Redis instances in our premium tier, private instances cannot be accessed via a local computer. For access to the private Redis instance, you must use the available Heroku Redis CLI commands. This ensures that you have the correct authorization to connect to the instance across the isolated network boundary.

Using the CLI

The ability to connect to private instances is integrated directly in to the
Heroku CLI and all of the commands available for the premium tier are available for private instances.

For more information on the available CLI commands for Heroku Redis, see the main Heroku Redis article.

Migrating from a premium Redis plan to a private Redis plan

In the event that an application is being migrated from the Common Runtime into a Heroku Private Space, the data from a premium Redis instance can also be migrated to a private Redis instance. This migration guide only applies to moving data from a premium Heroku Redis instance to a private Heroku Redis instance inside a Private Space.

1. Get the credentials of the Common Runtime instance

To begin the process, we’ll need the credentials from the Heroku Redis instance running on the Common Runtime.

2. Prevent new instance updates

It is important that no new data is written to your application on the source system during the migration process or it will not be transferred to the new database. To accomplish this, place your source app into maintenance mode. If you have scheduler jobs running as well, you should disable them.

Your application will be unavailable starting at this point in the upgrade process.

$ heroku maintenance:on
Enabling maintenance mode for sushi... done

Maintenance mode does not automatically scale down any dynos. Web and any non-web dynos should be scaled down to make sure that no connections are writing data to the database.

3. Provision the Private plan using fork

Assuming that the application has been created inside the private space, the new private Heroku Redis plan can be provisioned using the --fork flag in conjunction with the Heroku Redis URI from step 1 of this process.

4. Make target application active

To resume normal application operation, scale any non-web dynos back to their original levels. (If the application was not previously using non-web dynos, skip this step in order to avoid scaling any dynos that you may not need).

$ heroku ps:scale worker=1

Finally, turn off maintenance mode.

$ heroku maintenance:off

Your application is now receiving requests to your migrated Redis instance. This can be confirmed by running heroku redis:info. The instance denoted by REDIS_URL is considered the primary instance.

Steps to take after the migration

After upgrading your instance, you should deprovision the old instance so that you aren’t paying for an unused instance.