Heroku Data for Redis and Private Spaces
Last updated April 04, 2023
Table of Contents
Heroku Data for Redis in Private Spaces is only available in Heroku Enterprise.
This article explains the differences between Heroku Data for Redis provisioning, plans, and connections when used in Private Spaces or Shield Private Spaces as compared with using Heroku Data for 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 Data for 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 work for private Heroku Data for Redis instance.
Private Heroku Data for Redis plans aren’t 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 Data for 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 fails.
Create a New Instance
Many buildpacks 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 is used when creating the instance. For a list of the currently available plans, see the plans section.
Private Heroku Data for Redis instances can be provisioned via the CLI:
$ heroku addons:create heroku-redis:private-7 -a private-sushi
You can only create plans in the private tier of Heroku Data for Redis 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 Data for 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 |
---|---|---|---|---|
Private-7 | heroku-redis:private-7 |
7 GB | 10000 | $900 |
Private-9 | heroku-redis:private-9 |
10 GB | 25000 | $1750 |
Private-10 | heroku-redis:private-10 |
25 GB | 40000 | $4000 |
Private-12 | heroku-redis:private-12 |
50 GB | 65000 | $7500 |
Private-14 | heroku-redis:private-14 |
100 GB | 65000 | $14000 |
Shield Private Space Plans
Shield Private Spaces allow the use of additional Heroku Shield for Redis plans. These databases have strict connection requirements, prevent external connections, and require encrypted clients.
You must use a shield tier plan of Heroku Data for Redis in a Shield Private Space.
The shield tier is designed for production applications and includes:
- Region support
- Metrics published to application log stream
- High availability
Plan Name | Provisioning Name | Memory Limit | Connection Limit | Monthly Price |
---|---|---|---|---|
Shield-7 | heroku-redis:shield-7 |
7 GB | 10000 | $1100 |
Shield-9 | heroku-redis:shield-9 |
10 GB | 25000 | $2100 |
Shield-10 | heroku-redis:shield-10 |
25 GB | 40000 | $4800 |
Shield-12 | heroku-redis:shield-12 |
50 GB | 65000 | $9000 |
Shield-14 | heroku-redis:shield-14 |
100 GB | 65000 | $19600 |
External Connections
Unlike the Heroku Data for Redis instances in our premium tier, private instances can’t be accessed via a local computer. For access to the private Redis instance, you must use the available Heroku Data for 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 Data for Redis, see Managing Heroku Data for Redis Using the CLI.
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 Data for Redis instance to a private Heroku Data for Redis instance inside a Private Space.
It’s not possible to fork to a shield Redis plan.
1. Get the credentials of the Common Runtime instance
To begin the process, we need the credentials from the Heroku Data for Redis instance running on the Common Runtime.
$ heroku redis:credentials REDIS_URL -a sushi
redis://h:pdx11111111@ec2-184-255-255-255.compute-1.amazonaws.com:7929
2. Prevent new instance updates
It’s important that no new data is written to your application on the source system during the migration process or it won’t be transferred to the new database. To accomplish this, place your source app into maintenance mode. If you have scheduler jobs running as well, disable them.
Your application is unavailable starting at this point in the upgrade process.
$ heroku maintenance:on
Enabling maintenance mode for sushi... done
Maintenance mode doesn’t automatically scale down any dynos. Web and any non-web dynos must be scaled down to make sure that no connections are writing data to the database.
$ heroku ps:scale worker=0
Scaling worker processes... done, now running 0
3. Provision the Private plan using fork
Assuming that the application has been created inside the private space, the new private Heroku Data for Redis plan can be provisioned using the --fork
flag in conjunction with the Heroku Data for Redis URI from step 1 of this process.
$ heroku addons:create heroku-redis:private-7 --fork=redis://h:pdx11111111@ec2-184-255-255-255.compute-1.amazonaws.com:7929 -a private-sushi
Creating redis-rugged-22859... done
Adding redis-rugged-22859 to private-sushi... done
Setting HEROKU_REDIS_CHARCOAL_BASTIONS, HEROKU_REDIS_CHARCOAL_BASTION_KEY, HEROKU_REDIS_CHARCOAL_BASTION_REKEYS_AFTER, HEROKU_REDIS_CHARCOAL_URL and restarting private-sushi... done, v55
Instance has been created and will be available shortly
Use `heroku addons:docs heroku-redis` to view documentation.
4. Promote the forked instance
If you forked the Redis instance from an add-on that wasn’t the primary (it wasn’t the one with REDIS_URL
config var), then skip this step. You can use the config var of the new add-on in your app.
For a fork of the primary Redis add-on, promote the forked instance to be the primary so that REDIS_URL
points to this instance:
$ heroku redis:promote HEROKU_REDIS_CHARCOAL_URL
Promoting redis-rugged-22859 to HEROKU_REDIS_CHARCOAL_URL on example-app
5. Make target application active
To resume normal application operation, scale any non-web dynos back to their original levels. (If the application wasn’t previously using non-web dynos, skip this step in order to avoid scaling any dynos that you don’t 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, deprovision the old instance so that you aren’t paying for an unused instance.
$ heroku addons:destroy HEROKU_REDIS_BLUE