Table of Contents [expand]
Last updated July 07, 2026
Heroku Key-Value Store (KVS) defaults to the latest stable version of Valkey supported for the platform. Valkey is fully compatible with existing KVS add-ons and implementations. Newly created Heroku Key-Value Store instances always use the latest major version, currently 8. See Version Support and Legacy Infrastructure for more version info. This article describes how to upgrade the major Valkey version of a Heroku Key-Value Store instance.
Heroku supports two methods for upgrading an existing KVS add-on major version:
- Upgrade in-place with the
heroku redis:upgradecommand. - Creating and promoting a new Heroku Key-Value Store add-on with
--fork.
Performing an in-place upgrade is suitable for most cases.
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.
For instructions on upgrading your Heroku Key-Value Store plan instead of its version, see Heroku Key-Value Store.
Upgrade Using redis:upgrade
If your add-on is on a premium, private or shield plan, upgrading its version with the heroku redis:upgrade command creates a maintenance event. You can run the maintenance event to perform an in-place upgrade of your KVS major version. Internally, this process prepares a follower on the target upgrade version and creates a maintenance event. When the maintenance runs, either as scheduled or if you trigger it manually, it promotes the upgraded follower and makes the version upgrade effective.
If your add-on is on a mini plan, the heroku redis:upgrade command upgrades your instance immediately without a maintenance event, as mini plans don’t support maintenance windows.
When promoting the new instance as part of the upgrade, there’s a chance of data loss if your apps continue writing to KVS as the failover itself happens. To minimize this impact, put your app on maintenance mode and pause any jobs or external tasks that write to your KVS add-on.
Step 1: Prepare the Upgrade
The redis:upgrade command prepares your add-on for upgrade and creates a maintenance event for you to run:
$ heroku redis:upgrade redis-convex-62372 --version 8 -a example-app
▸ WARNING: Irreversible action.
▸ Redis database will be upgraded to 8. This cannot be undone.
▸ To proceed, type example-app or re-run this command with --confirm example-app
>example-app
Requesting upgrade of redis-convex-62372 to 8... Your Redis version is being upgraded to 8. The system is preparing a maintenance. Once the maintenance is ready you can run it with heroku data:maintenances:run. See: https://devcenter.heroku.com/articles/data-maintenance-cli-commands#heroku-data-maintenances-run.
If your add-on is on a mini plan, heroku redis:upgrade triggers the upgrade immediately. For mini plans, put your app in maintenance mode before this step to minimize data loss.
Step 2: Wait for the Maintenance to Be Created
Use the heroku data:maintenances:info command to confirm that you created the maintenance event and it’s ready. It can take ~15 minutes for the system to prepare the maintenance.
When the preparation completes, you see a maintenance with the status ready.
$ heroku data:maintenances:info redis-convex-62372 -a example-app
Fetching maintenance... done
addon_attachments: REDIS_ADDON_URL
addon_description: premium HA
addon_kind: heroku-redis
addon_name: redis-addon-name
addon_plan: premium-0
addon_window: Tuesdays 18:30 to 22:30 UTC
app_name: example-app
method: failover
reason: customer_request
required_by: 2023-03-29T17:26:56.220+00:00
scheduled_for: 2023-03-14T18:30:00.000+00:00
server_created_at: 2023-03-01T16:51:27.021+00:00
status: ready
window: Tuesdays 18:30 to 22:30 UTC
The heroku redis:info command also shows the state of your pending upgrade:
$ heroku redis:info -a example-app
=== redis-convex-62372 (REDIS_URL)
Plan: Premium 0
Status: preparing (creating maintenance event for version upgrade)
Created: 2026-06-25 14:53
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: Temporarily Unavailable
Requires TLS: Yes
Keyspace Notifications: Disabled
Plan Connection Limit: 40
Step 3: Prevent New Updates (Recommended)
When you’re ready to run the maintenance, minimize data loss by placing your app in maintenance mode to prevent writing new data to KVS during the upgrade. If you have scheduler jobs running, disable them.
$ heroku maintenance:on -a example-app
Maintenance mode doesn’t automatically scale down any dynos. Scale down any non-web dynos, such as worker dynos for queueing jobs, to make sure that no connections are writing data to KVS.
$ heroku ps:scale worker=0 -a example-app
Scaling worker processes... done, now running 0
Step 4: Run the Upgrade Maintenance
You can perform an in-place upgrade of KVS by running the prepared maintenance with the heroku data:maintenances:run CLI command:
$ heroku data:maintenances:run redis-addon-name -a example-app
Triggering maintenance... maintenance triggered
The maintenance takes a few seconds to complete. The maintenance is complete when the info command shows the maintenance status as completed.
$ heroku data:maintenances:info redis-addon-name -a example-app
Fetching maintenance... done
addon_attachments: REDIS_ADDON_URL
addon_description: premium HA
addon_kind: heroku-redis
addon_name: redis-addon-name
addon_plan: premium-0
addon_window: Tuesdays 18:30 to 22:30 UTC
app_name: example-app
completed_at: 2023-03-03T17:06:16.358+00:00
duration_approximate: ~ less than a minute
duration_seconds: 8
method: failover
reason: customer_request
required_by: 2023-03-31T17:02:32.773+00:00
scheduled_for: 2023-03-03T17:06:06.701+00:00
server_created_at: 2023-03-01T17:35:52.572+00:00
started_at: 2023-03-03T17:06:08.341+00:00
status: completed
window: Tuesdays 18:30 to 22:30 UTC
Step 5: Resume Normal Operation
If you turned on maintenance mode and downscaled your dynos in step 3, resume your app’s operations.
To resume normal app operation, scale any non-web dynos back to their original levels. Then, turn off maintenance mode:
$ heroku maintenance:off -a example-app
Upgrade Using a Fork
Step 1: Prevent New Updates
You must prevent new data from writing to your app during the upgrade process to ensure a complete data transfer to the new KVS instance. Place your app into maintenance mode. If you have scheduler jobs running, disable them.
Your app is unavailable starting at this point in the upgrade process.
$ heroku maintenance:on -a example-app
Enabling maintenance mode for example-app... done
Maintenance mode doesn’t automatically scale down any dynos. Scale down any non-web dynos, such as worker dynos for queueing jobs, to make sure that no connections are writing data to the instance.
$ heroku ps:scale worker=0 -a example-app
Scaling worker processes... done, now running 0
Step 2: Create the Fork
After preventing new updates, create a fork of your KVS instance. You can obtain the connection string (rediss://:<password>@<hostname>:<port>) of your current KVS instance by using heroku config:get REDIS_URL. The following command creates a Heroku Key-Value Store add-on instance, forking the data from the URL of the old one:
$ 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-spherical-37410 is being created in the background. The app will restart when complete...
Run heroku addons:info redis-spherical-37410 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-spherical-37410 (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.
Heroku recommends using TLS connections with a rediss:// URL instead of redis:// when creating a fork. All Heroku Key-Value Store instances require TLS connections and use rediss:// in their connection strings.
The fork process doesn’t copy any customized settings, including eviction policies, from the source instance. For example, if you’re forking an instance that has a customized idle connection timeout, the fork doesn’t copy the timeout settings to the target fork instance. Adjust the settings of the new instance when it becomes available.
Step 3: Promote the Fork
After the data transfers to the forked instance, you must promote it to use the primary REDIS attachment. Confirm that the forked KVS instance is available with heroku redis:info.
Use the heroku redis:promote command providing the name of the forked instance to promote:
$ heroku redis:promote redis-spherical-37410 -a example-app
Promoting redis-spherical-37410 to REDIS_URL on example-app
Promoting a forked KVS instance updates the REDIS_URL config var, and restarts the app.
Step 4: Resume Normal Operation
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 example-app
Then, turn off maintenance mode.
$ heroku maintenance:off -a example-app
Your app is now connecting to your upgraded KVS instance.
The version upgrade doesn’t automatically remove the old KVS add-on from your app. If it’s no longer needed, remove it with heroku addons:destroy.