Table of Contents [expand]
Last updated July 06, 2026
Heroku Key-Value Store in Private Spaces is only available for verified Heroku Teams and in Heroku Enterprise.
Heroku Private Spaces are dedicated environments for running applications in an isolated network. A dedicated environment means that every part of an app’s stack, including the dynos, data stores, and third-party add-ons, are contained in the isolated environment. Heroku Key-Value Store (KVS) can run in a Private Space or Shield Space with a developer experience similar to the Common Runtime. Many of the same CLI commands and web interfaces work identically.
This article explains considerations for Heroku Key-Value Store provisioning, plans, and connections that are specific to Private Spaces. If you have an existing Premium Heroku Key-Store Value instance on the Common Runtime and you want to migrate it into a Private Space, see Migrating from a Premium KVS Plan to a Private KVS Plan.
Private and Shield Heroku Data add-ons aren’t accessible to apps at build time. It’s recommended that you eliminate the dependency on your private data store, use a public Heroku Data plan, or contact support for guidance.
All Heroku Key-Value Store plans require TLS connections. You must configure your client to support TLS. This process can require updating and deploying your app before returning the app to normal operation.
Provisioning
Private and Shield Spaces each have their own Private-tier and Shield-tier Heroku Key-Value Store plans that are unique to that type of space. You can only provision private-tier plans inside the isolated network environment. If you attempt to create an instance from the premium tier, that request fails.
Create an Instance
For a list of the currently available plans, see the plans section.
Use the heroku addons:create CLI command to provision private or shield Heroku Key-Value Store instances:
$ heroku addons:create heroku-redis:private-7 -a example-app
You can only create private-tier plans of Heroku Key-Value Store inside a Private Space.
Depending on the region and the type of instance you’re creating, the provisioning process can take up to 10 minutes before the instance is available.
Plans
Heroku Key-Value Store offers a set of plans for Private Spaces and Shield Private Spaces.
Private-Tier Plans
The private tier is designed for production apps and includes:
| Plan Name | Provisioning Name | Memory Limit | Connection Limit | Monthly Price |
|---|---|---|---|---|
| Private-3 | heroku-redis:private-3 |
500 MB | 400 | $150 |
| Private-5 | heroku-redis:private-5 |
750 MB | 700 | $250 |
| Private-7 | heroku-redis:private-7 |
7 GB | 10000 | $900 |
| Private-9 | heroku-redis:private-9 |
10 GB | 25000 | $1,750 |
| Private-10 | heroku-redis:private-10 |
25 GB | 40000 | $4,000 |
| Private-12 | heroku-redis:private-12 |
50 GB | 65000 | $7,500 |
| Private-14 | heroku-redis:private-14 |
100 GB | 65000 | $14,000 |
Shield-Tier Plans
In Shield Private Spaces, you can use the additional Shield Heroku Key-Value Store plans. These instances have strict connection requirements, prevent external connections, and require encrypted clients.
You must use a shield-tier plan of Heroku Key-Value Store in a Shield Private Space.
The shield tier is designed for production apps and includes:
- Region support
- Metrics published to the app’s log stream
- High availability
| Plan Name | Provisioning Name | Memory Limit | Connection Limit | Monthly Price |
|---|---|---|---|---|
| Shield-3 | heroku-redis:shield-3 |
500 MB | 400 | $210 |
| Shield-5 | heroku-redis:shield-5 |
750 MB | 700 | $350 |
| Shield-7 | heroku-redis:shield-7 |
7 GB | 10000 | $1,100 |
| Shield-9 | heroku-redis:shield-9 |
10 GB | 25000 | $2,100 |
| Shield-10 | heroku-redis:shield-10 |
25 GB | 40000 | $4,800 |
| Shield-12 | heroku-redis:shield-12 |
50 GB | 65000 | $9,000 |
| Shield-14 | heroku-redis:shield-14 |
100 GB | 65000 | $19,600 |
External Connections
Private and Shield Spaces are isolated network environments, so there are strict security requirements and limitations when connecting to Heroku Key-Value Store instances in these tiers.
Unlike the Heroku Key-Value Store instances in our premium tier, you can’t connect to private or shield-tier instances from outside their Private or Shield space.
For access to a private KVS instance, you must use the available Heroku Key-Value Store CLI commands. Using the CLI makes sure that you have the correct authorization to connect to the instance across the isolated network boundary.
Using the CLI
Use the Heroku CLI to connect to private instances. The commands available for the premium tier are also available for private instances.
For more information on the available CLI commands for Heroku Key-Value Store, see Managing Heroku Key-Value Store Using the CLI.
Shield instances don’t allow connections via heroku redis:cli from outside the space
See Connecting to Heroku Key-Value Store in a Private or Shield Space via PrivateLink for details on connecting to private or shield KVS instances from your AWS VPC via PrivateLink.
Migrating from a Premium KVS Plan to a Private KVS Plan
If you migrate an app from the Common Runtime into a Heroku Private Space, you can also migrate the data from a premium KVS instance to a private KVS instance. This migration method uses the fork functionality of Heroku Key-Value Store.
This migration guide covers moving data from a premium Heroku Key-Value Store instance to a private Heroku Key-Value Store instance in a Private Space. It’s not possible to create a shield KVS instance as a fork of another instance because of the shield space network restrictions.
1. Get the Credentials of the Common Runtime Instance
To begin the process, get the connection string of your Heroku Key-Value Store instance running on the Common Runtime. Use the heroku redis:credentials command to get your instance connection string:
$ heroku redis:credentials REDIS_URL -a common-runtime-example-app
rediss://:pas3248745…1@ec2-184-255-255-255.compute-1.amazonaws.com:7929
Alternatively, you can also get your KVS’ instance connection string from the Heroku Dashboard navigating to your add-on’s page, under the Settings > Datastore Credentials section.
2. Enter Maintenance Mode to Prevent Instance Writes
It’s important that new data isn’t written to your current instance during the migration process or it doesn’t transfer to the new instance. To prevent instance writes, put your source app into maintenance mode. If you have scheduler jobs running as well, disable them.
Your app is unavailable starting at this point in the migration process.
$ heroku maintenance:on -a private-example-app
Enabling maintenance mode for private-example-app... done
Maintenance mode doesn’t automatically scale down any dynos. Scale down any web and non-web dynos to make sure that no connections are writing data to the instance.
$ heroku ps:scale worker=0 -a private-example-app
Scaling worker processes... done, now running 0
3. Provision a New Private Instance
Create a new private Heroku Key-Value Store instance on the Private Space you’re migrating to as a fork of your current instance. This process copies the existing data from your instance in the Common Runtime to a new one in your Private Space.
Use the heroku addons:create CLI command with the --fork flag and provide the connection string from your current instance from step 1 of this process.
$ heroku addons:create heroku-redis:private-7 -a private-example-app -- --fork=rediss://pas3248745…@ec2-184-255-255-255.compute-1.amazonaws.com:7929
Creating heroku-redis:private-7 on ⬢ private-example-app... $900/month
Your add-on should be available in a few minutes.
redis-rugged-22859 is being created in the background. The app will restart when complete...
Use heroku addons:info redis-rugged-22859 to check creation progress
Use heroku addons:docs heroku-redis to view documentation
4. Promote the Forked Instance
Make sure that your new private KVS instance uses the REDIS attachment if your app is connecting to it via the REDIS_URL config var by default. Promote a KVS instance to use the REDIS attachment with the heroku redis:promote CLI command:
$ heroku redis:promote redis-rugged-22859 -a private-example-app
Promoting redis-rugged-22859 to REDIS_URL on private-example-app
If your app expects the instance to use another specific attachment name, use the heroku addons:attach command with the --as flag and the attachment name to define a new attachment alias:
$ heroku addons:attach redis-rugged-22859 --as CACHE -a private-example-app
Attaching ⛁ redis-rugged-22859 as CACHE to ⬢ private-example-app... done
Setting CACHE config vars and restarting ⬢ private-example-app... done, v5
5. Exit Maintenance Mode
To resume normal app operation, scale any non-web dynos back to their original levels. If the app wasn’t previously using non-web dynos, skip this step to avoid scaling any dynos that you don’t need.
$ heroku ps:scale worker=1 -a private-example-app
Finally, turn off maintenance mode.
$ heroku maintenance:off -a private-example-app
Your app is now receiving requests to your migrated KVS instance. Confirm your app is receiving requests by running heroku redis:info. The instance denoted by REDIS_URL is the primary instance.
Steps to Take After the Migration
The migration fork method involves creating a new add-on in your Private Space. It doesn’t automatically deprovision your old instance in the Common Runtime.
After migrating your instance, make sure to deprovision your old instance.
$ heroku addons:destroy REDIS -a common-runtime-example-app