Last updated July 06, 2026

Heroku Key-Value Store (KVS) is an in-memory key-value data store, run by Heroku, that is provisioned and managed as an add-on. Heroku Key-Value Store is accessible from any language with a Redis or Valkey compatible driver, including all languages and frameworks supported by Heroku.

Provisioning the Add-on

To provision a new Heroku Key-Value Store add-on, use the addons:create CLI command:

$ heroku addons:create heroku-redis:mini -a example-app
Creating heroku-redis:mini on ⬢ example-app... ~$0.004/hour (max $3/month)
Your add-on should be available in a few minutes.
! WARNING: Data stored in essential plans on Heroku Redis are not persisted.
redis-infinite-64494 is being created in the background. The app will restart when complete...
Run heroku addons:info redis-infinite-64494 to check creation progress.
Run heroku addons:docs heroku-redis to view documentation.

To learn more about Heroku Key-Value Store plans, see Heroku Key-Value Store Plans and Pricing.

 

Depending on the plan, your instance can take several minutes to become available. You can track its status with the heroku redis:wait command, which blocks until your instance is ready to use.

The heroku addons:info command shows creation progress. A state of creating means that provisioning is still in progress.

$ heroku addons:info redis-infinite-64494 -a example-app
=== redis-infinite-64494

Plan:         heroku-redis:mini
Price:        ~$0.004/hour
Max Price:    $3/month
Attachments:  ⬢ example-app::REDIS
Owning app:   ⬢ example-app
Installed at: Thu Jun 25 2026 10:35:17 GMT+0000 (Coordinated Universal Time)
State:        creating

You can also use heroku addons:wait to show the provisioning status.

Specify the Valkey version

You can specify the version of Valkey you want to provision by including the --version flag in your provisioning command:

$ heroku addons:create heroku-redis:mini -a example-app -- --version=7

Learn more about Valkey version support.

App Config Vars

As part of the provisioning process, Heroku Key-Value Store adds a new config var to your app’s configuration that includes the connection string to access the instance. This process creates a new release and the app restarts. The config var name matches the attachment name for your add-on.

You can specify an attachment name when provisioning your instance with addons:create and the --as flag:

$ heroku addons:create heroku-redis:mini --as CACHE -a example-app

Heroku Key-Value Store uses the REDIS attachment name and the REDIS_URL config var by default. If your app already has a Heroku Key-Value Store instance attached as REDIS and you provision another one, the new instance attaches as HEROKU_REDIS_<COLOR>, for example HEROKU_REDIS_GOLD.

Use the heroku redis:info command to see the instances attached to your app and their attachment names:

$ heroku redis:info -a example-app
=== redis-infinite-64494 (REDIS_URL)

Plan:                   Mini
Status:                 available
Created:                2026-06-25 10:35
Version:                8.1.7
Timeout:                300
Maxmemory:              25 MB
Maxmemory Policy:       noeviction
Maintenance:            not required
Maintenance Window:     Wednesdays 17:30 to 21:30 UTC
Persistence:            None
HA Status:              Unavailable
Requires TLS:           Yes
Keyspace Notifications: Disabled
Plan Connection Limit:  20

=== redis-flat-78805 (CACHE_URL)

Plan:                   Mini
Status:                 available
Created:                2026-06-25 10:40
Version:                8.1.7
Timeout:                300
Maxmemory:              25 MB
Maxmemory Policy:       noeviction
Maintenance:            not required
Maintenance Window:     Mondays 20:00 to Tuesdays 00:00 UTC
Persistence:            None
HA Status:              Unavailable
Requires TLS:           Yes
Keyspace Notifications: Disabled
Plan Connection Limit:  20

You can confirm the names and values of your app’s config vars with the heroku config command:

$ heroku config -a example-app | grep REDIS
REDIS_URL: rediss://@ec2-111-1-1-1.compute-1.amazonaws.com:7330

Designating a Primary Instance

Heroku uses the default REDIS attachment and the REDIS_URL config var to identify the primary KVS instance on your app. See App Config Vars for details.

Promoting an Instance

For apps that have multiple KVS instances, set the primary instance using the redis:promote command. This command attaches the instance you specify as REDIS and updates the REDIS_URL config var with its connection string:

$ heroku redis:promote redis-flat-78805 -a example-app
Promoting redis-flat-78805 to REDIS_URL on example-app

Sharing Heroku Key-Value Store Between Apps

You can share a single Heroku Key-Value Store instance between multiple apps with the heroku addons:attach command. You can also specify the attachment name as an alias for your add-on using the --as flag:

$ heroku addons:attach my-originating-app::REDIS --as CACHE -a example-app
Attaching ⛁ redis-flat-78805 to ⬢ example-app... done
Setting CACHE config vars and restarting ⬢ example-app... done, v10

If you don’t specify an attachment name when you share an instance with an app with an existing KVS add-on, the instance attaches with a color attachment name by default. If the app doesn’t have other KVS instances attached, it’s attached as REDIS with the config var REDIS_URL by default.

A shared instance isn’t necessarily the default instance on any apps that it’s shared with. To designate the shared instance as the primary instance on the app you shared it with, promote it with the heroku redis:promote command.

To stop sharing your Heroku Key-Value Store instance with another app, use the heroku addons:detach command:

$ heroku addons:detach redis-flat-78805 -a example-app
Detaching CACHE to redis-flat-78805 from  ⬢ example-app... done
Unsetting CACHE config vars and restarting  ⬢ example-app... done, v11

Version Support and Legacy Infrastructure

Heroku KVS runs on Valkey infrastructure. KVS offers Valkey 8 as the default version and provides updates and support for Valkey 7 and 8.

Heroku releases minor versions shortly after they’re available on Valkey. If a new minor version is available and the database is on an older minor version, Heroku automatically updates the minor version after each maintenance on Premium-tier higher plans.

Heroku Key-Value Store defaults to the latest stable version of Valkey allowlisted for the platform. Heroku follows the release schedule of the Valkey project and supports the latest 2 major versions with at least one minor version per major release on the platform. Currently supported versions include:

Major Version	Minor Version	Status	End-Of-Life Date
7	7.2	Available	Q4 2026
8	8.1	Available (default)	Q4 2027

See Upgrading a Heroku Key-Value Store Version for details on upgrading the version of your instance.

Deprecation and Migration of Deprecated Instances

Heroku deprecates old major versions of our infrastructure. Deprecations can happen if:

• The operating system running beneath the database no longer receives security updates.
• Support for the operating system is no longer practical due to age.
• Necessary packages and patches are no longer available or difficult to support.
• The server instances are significantly different from our current infrastructure and are impractical to support.

When we release a new major version, we deprecate the earliest major version. For example, when we release version 9, we deprecate version 7 and support versions 9 and 8.

• On the deprecation date, Heroku notifies customers via email about the deprecation process for their affected databases.
• Two months after the deprecation date, Heroku prevents provisioning new instances on the deprecated version.
• Three months after the deprecation date, Heroku schedules forced upgrades for instances that still run a deprecated version.
• Four months after the deprecation date, the deprecated version is end-of-life.

Heroku highly recommends that you perform the version upgrade before support ends so that you can test compatibility, plan for unforeseen issues, and migrate your database on your own schedule.

End-of-Life

The end-of-life date of each version occurs four months after its deprecation date. We start restricting access and deleting instances for non-compliance after this date.

Upgrading a Heroku Key-Value Store Plan

Upgrade or downgrade the plan of your Heroku Key-Value Store instance with the heroku addons:upgrade CLI command. To change your plan, first find the resource name of the Heroku Key-Value Store instance you’re upgrading. The resource name is a globally unique name of the instance across all of your apps and add-ons:

$ heroku redis:info -a example-app
=== redis-sinuous-74593 (REDIS_URL)

Plan:                   Premium 0
Status:                 available
Created:                2026-06-25 12:22
Version:                7
Timeout:                300
Maxmemory:              50 MB
Maxmemory Policy:       noeviction
Maintenance:            not required
Maintenance Window:     Mondays 17:30 to 21:30 UTC
Persistence:            AOF
HA Status:              Available
Requires TLS:           Yes
Keyspace Notifications: Disabled
Plan Connection Limit:  40

This example upgrades redis-sinuous-74593 from a premium-0 plan to a premium-1 plan:

Changing redis-sinuous-74593 on ⬢ example-app from heroku-redis:premium-0 to heroku-redis:premium-1... done, ~$0.042/hour (max $30/month)
The Heroku Redis instance is in the process of being upgraded.
The time it takes to upgrade is dependent on how much data exists in the instance.
You can use `heroku redis:wait` to monitor the status of your upgrade.

Follow the plan upgrade process with the heroku redis:wait CLI command that blocks until the upgrade is complete:

$ heroku redis:wait -a example-app
Waiting for database ⛁ redis-sinuous-74593... ⢿ upgrading plan

Alternatively, you can also use heroku redis:info to check the status of your add-on:

$ heroku redis:info redis-sinuous-74593 -a example-app
=== redis-sinuous-74593 (REDIS_URL)

Plan:                   Premium 0
Status:                 preparing (plan upgrade in progress)
Created:                2026-06-25 12:22
Version:                7.2.13
Timeout:                300
Maxmemory:              50 MB
Maxmemory Policy:       noeviction
Maintenance:            not required
Maintenance Window:     Mondays 17:30 to 21:30 UTC
Persistence:            AOF
HA Status:              Available
Requires TLS:           Yes
Keyspace Notifications: Disabled
Plan Connection Limit:  40

Migrating to Heroku Key-Value Store

You can create a new Heroku Key-Value Store instance with the data from another instance or an external Redis or Valkey service. Use the heroku addons:create CLI command and provide the connection string of the Redis or Valkey-compatible instance to copy with the --fork option:

$ heroku addons:create heroku-redis:premium-0 -a example-app -- --fork rediss://<username>:<password>@<hostname>:<port>
Creating heroku-redis:premium-0 on ⬢ example-appi... ~$0.021/hour (max $15/month)
Your add-on should be available in a few minutes.
redis-graceful-62306 is being created in the background. The app will restart when complete...
Run heroku addons:info redis-graceful-62306 to check creation progress.
Run heroku addons:docs heroku-redis to view documentation.

Follow this fork process with the heroku redis:info CLI command:

=== redis-graceful-62306 (HEROKU_REDIS_YELLOW_URL)

Plan:                   Premium 0
Status:                 preparing (fork in progress)
Created:                2026-06-25 12:43
Version:                8
Timeout:                300
Maxmemory:              50 MB
Maxmemory Policy:       noeviction
Maintenance:            not required
Maintenance Window:     Tuesdays 19:30 to 23:30 UTC
Persistence:            AOF
HA Status:              Temporarily Unavailable
Requires TLS:           Yes
Keyspace Notifications: Disabled
Plan Connection Limit:  40

You can also use heroku addons:wait to show the provisioning status.

 

 

Upgrading a Heroku Key-Value Store Version

See Upgrading a Heroku Key-Value Store Version for instructions.

High Availability

All premium Heroku Key-Value Store plans include High Availability (HA). When the primary KVS instance fails, it’s automatically replaced with another replica, called a standby.

Failover Conditions

To prevent service interruptions commonly seen with hair-trigger failover systems, we run a suite of checks to make sure that failover is the appropriate response when a KVS instance is unresponsive. These checks run every few seconds and consist of establishing connections to the underlying host using the SSH protocol. However, when only the Valkey process becomes unavailable or unresponsive for any reason, a failover is unnecessary and the process restarts instead, ensuring an even shorter downtime period whenever possible.

After our systems initially detect a problem, we confirm that the instance is truly unavailable by running several checks for two minutes across multiple network locations. This process prevents transient problems from triggering a failover.

Heroku keeps standbys up to date asynchronously. It’s possible for data to be committed on the primary instance but not yet on the standby. Typically, data loss is minimal because Valkey isn’t committing the data to disk.

After Failover

After a successful failover, the connection string of your Heroku KVS instance can change and point to a different host. We create a new release on your app to update the value of your add-on’s config var. If you’re on a single tenant plan (including premium-7 and later), the failover is transparent. The underlying server hosting your instance changes but the hostname to connect to it doesn’t. Finally, regardless of plan, the failover automatically creates a new standby, and Heroku can’t perform HA procedures until the standby becomes available and meets our failover conditions.

Monitor Your Heroku Key-Value Store Instance

Logging

If your app or framework emits logs related to instance access, usage, or errors, you can retrieve these messages through your app’s logs. To see a real-time tail of your app logs, use the heroku logs command with the -t option:

$ heroku logs -t -a example-app

To see logs from the KVS instance itself in Cedar-generation apps, use the process type -p flag and the add-on name. This command indicates that you only want to see the logs from a specific Heroku Key-Value Store add-on.

$ heroku logs -p redis-triangular-12345 -t -a example-app

To view logs in Fir-generation apps, use the source type -s flag with the heroku-redis value.

$ heroku logs -s heroku-redis -a example-app

The format of the output includes the following pieces of information:

• Timestamp
• Service
• Resource Name
• Message

2026-06-25T12:54:34.000000+00:00 app[redis-sinuous-74593]:: Error accepting a client connection

Metrics logs

For more information about Heroku Key-Value Store metrics logs, see Heroku Key-Value Store Metrics Logs.

Utilization and Command Metrics

The Overview page of your Heroku Key-Value Store add-on in the Heroku dashboard helps you monitor and understand your KVS utilization in terms of client connections and memory usage over time. The dashboard also provides usage and timing statistics for common Valkey commands.

Configuring Your Instance

Heroku Key-Value Store allows you to change your instance timeout and maxmemory-policy settings. These settings persist across upgrades and High Availability (HA) failovers.

timeout

The timeout setting sets the number of seconds Valkey waits before closing idle connections. A value of zero means that idle connections don’t close. The default value is 300 seconds (5 minutes). You can change this value using the heroku redis:timeout CLI command:

$ heroku redis:timeout redis-sinuous-74593 --seconds 60 -a example-app
Timeout for redis-sinuous-74593 (REDIS_URL) set to 60 seconds.
Connections to the Redis instance will be stopped after idling for 60 seconds.

maxmemory-policy

The maxmemory-policy setting sets the key eviction policy used when an instance reaches its storage limit. Available policies for key eviction include:

• noeviction returns errors when reaching the memory limit.
• allkeys-lru removes less recently used keys first.
• volatile-lru removes less recently used keys first that have an expiry set.
• allkeys-random evicts random keys.
• volatile-random evicts random keys that have an expiry set.
• volatile-ttl evicts keys with an expiry set and a short TTL.
• volatile-lfu evicts using approximated LFU among the keys with an expired set.
• allkeys-lfu evicts any key using approximated LFU.

By default, Heroku sets this setting to noeviction. You can change this value using the CLI:

$ heroku redis:maxmemory redis-sinuous-74593 --policy volatile-lru -a example-app
Maxmemory policy for redis-sinuous-74593 (REDIS_URL) set to volatile-lru.
volatile-lru evict keys trying to remove the less recently used keys first, but only those that have an expiry set.

Valkey Modules

Valkey modules add extra features on your Key-Value Store instance. To use modules, you must use version 8.1 and later. Heroku automatically enables the modules in KVS instances on supported versions.

Module	Description
Valkey Bloom	Use Bloom filters, a probabilistic data structure for quickly and memory-efficiently determining if an element is in a set or not.
ValkeyJSON	Work with JSON in a KVS instance more efficiently with native support for storing, retrieving, and manipulating JSON documents.

Security and Compliance

Connections on Heroku Key-Value Store have native TLS support to encrypt traffic. All Key-Value Store plans require TLS connections.

Heroku Key-Value Store uses self-signed certificates, which can require you to configure the verify_mode SSL setting of your Redis or Valkey client. See Connecting to Heroku Key-Value Store for examples on setting up TLS connections.

Using the CLI

For more information about managing Heroku Key-Value Store using the CLI, see Managing Heroku Key-Value Store Using the CLI.

Connecting to Heroku Key-Value Store

For more information about connecting to Heroku Key-Value Store, see Connecting to Heroku Key-Value Store.

Persistence

The Mini plan for Heroku Key-Value Store doesn’t persist data. If the instance reboots or a failure occurs, the data on the instance is lost.

The production plans of Heroku Key-Value Store (Premium, Private, and Shield) use Append Only File (AOF) persistence to write to the disk every second. These plans have a high-availability (HA) standby for failover.

To back up your data, use the CLI fork functionality or use external replication. For more information about the fork functionality, see Migrating to Heroku Key-Value Store.

Destroying the Add-on

You can destroy the add-on using the Heroku dashboard or using the CLI.

Destroy Using the Dashboard

To delete a KVS instance from the Heroku Dashboard:

1. From the Heroku Dashboard, navigate to your app and then select the Resources tab.
2. On the Resources tab, on the Heroku Key-Value Store resource, click the selector on the right, and then select Delete Add-on.
3. On the Remove Add-on page, enter the app’s name as confirmation, and then select Remove add-on.

Delete Using the CLI

To destroy the add-on from the CLI, use the addons:destroy command and specify the add-on name, config var, or attachment name of the instance:

$ heroku addons:destroy redis-flat-78805 -a example-app
 ›   Warning: Destructive Action
 ›   This command will affect the app ⬢ example-app

✔ To proceed, type example-app or re-run this command with --confirm example-app example-app
Destroying redis-flat-78805 on ⬢ example-app... done

You can specify the add-on to destroy with one of the following:

• the attachment name of the Heroku Key-Value Store add-on (for example, REDIS, HEROKU_REDIS_BLUE)
• the name of the Heroku Key-Value Store add-on (for example, redis-flat-78805)

Support

Submit all Heroku Key-Value Store support and runtime issues via one of the Heroku Support channels.