Open-source alternative to Heroku Data for Redis: the short answer
If your app uses a Heroku Redis add-on for caching, queues or sessions, you can self-host the same workload on Dokku or Coolify with Valkey, which is licensed under BSD-3-Clause and is the license-clear choice for this move. Redis Open Source 8.0 and later is also self-hostable under a license you select from RSALv2, SSPLv1 or AGPLv3, but Redis 7.4.x through 7.8.x carry a dual RSALv2 or SSPLv1 license that is not OSI-approved, so check the exact Redis version you run before you standardize on it. Valkey is compatible with Redis OSS 7.2 and earlier, and existing Redis client libraries connect without code changes, so the application side of the move is usually small. The license and residency question is only part of the decision. Heroku announced on February 6, 2026 that it is moving to a sustaining engineering model focused on stability, security, reliability and support, so existing customers keep a supported platform, but you should plan around that roadmap rather than assume new features will arrive. Once Redis runs on your server, you take on what the add-on handled for you: persistence settings for RDB snapshots and AOF, backup storage and restore tests, high availability through Valkey Sentinel with at least three Sentinel instances, failover behavior, memory capacity and eviction policy, and upgrades across Valkey release lines. Before you cut over, confirm three things with your own team: the data format your current Heroku instance produces, how much memory your cache and queues need at peak, and whether a single node with tested backups is enough or whether replication and Sentinel are required for your recovery target. Those answers decide the migration method and the operating cost.
Which Heroku Redis capabilities map to Valkey, Redis and self-hosted tooling
This table maps each Heroku Data for Redis capability to Valkey standalone or Sentinel, Redis Open Source, Dokku's Redis plugin, Coolify's one-click Redis and tooling you supply yourself. Read each row as a question to answer for your workload, and treat any cell that says to confirm as a item to verify in your own environment before you commit.
| Capability | Self-hosted approach | What you own or must confirm |
|---|---|---|
| Managed instance provisioning | Dokku Redis plugin or Coolify one-click Redis creates a container on your server | Server sizing, instance naming and version pinning are your decisions; confirm the plugin's default version |
| Client connection | Existing Redis clients connect to Valkey without code changes, per the Valkey migration guide | Confirm TLS and password settings in your app, since the default setup may not enforce them |
| Persistence | RDB snapshots and AOF are available in Valkey and Redis Open Source; plugin defaults vary | Choose snapshot frequency and AOF fsync policy yourself and test recovery |
| Backups and retention | No managed retention schedule; you supply backup tooling and storage | Heroku-style point-in-time retention is a gap to plan for; set off-host copies and retention rules yourself |
| High availability | Valkey Sentinel for failover without Valkey Cluster, with at least three Sentinel instances recommended | Automatic failover must be configured and tested; a single Dokku or Coolify host gives no failover |
| Eviction and sizing | Memory limits and eviction policy are set in the server configuration | Size memory for cache, queue or session data, and confirm the eviction policy suits each use |
| Monitoring and alerts | Use your own metrics and alerting stack; Redis and Valkey expose server statistics | Heroku's built-in metrics do not carry over; set memory, latency and replication alerts yourself |
| License position | Valkey is BSD-3-Clause; Redis 7.2 and earlier are BSD-3-Clause, while Redis 8.0 and later offer AGPLv3 among other options | Check the license of the exact Redis version you pick, since Redis 7.4 to 7.8 use non-OSI licenses |
Comparing Valkey, Redis Open Source and the Dokku and Coolify deployment paths
Heroku Data for Redis gives you a managed cache, but a self-hosted replacement splits the decision into two parts: which engine and license you run, and which deployment path hosts it. The cards below cover both, so you can match the license terms and operational work to your cache, queue and session needs.
Valkey under BSD-3-Clause
Valkey is forked from the open-source Redis project and licensed under BSD-3-Clause, with the Linux Foundation backing the project and holding its trademarks through LF Projects. Existing Redis client libraries connect without code changes, and its migration guide documents four move methods. Fit: teams that want a permissive license and a neutral governance home for caches, queues and sessions. Check: whether your Redis source is 7.2 or earlier, since Redis 7.4 and later files need a different method that the guide does not cover.
Redis Open Source 8.0 and later
From Redis 8.0, Redis Open Source can be used under your choice of RSALv2, SSPLv1 or AGPLv3. It bundles JSON, time series, probabilistic structures and the Redis Query Engine, which may matter if your application uses them. Trade-off: the Intel SVS-VAMANA vector optimizations (LeanVec and LVQ) are closed source and only usable under RSALv2. Check with counsel whether AGPLv3 network-service terms or the RSALv2 option fit your product before you pick a license.
Redis 7.4 to 7.8 licensing
Redis 7.4.x to 7.8.x, then called Redis Community Edition, stayed under the dual RSALv2 or SSPLv1 license, and neither license is OSI-approved. Redis 7.2.x and earlier remained under BSD-3-Clause, so a version pin matters for licensing as well as features. Fit: teams already on these versions that want a short upgrade plan. Check: which exact release your fleet runs, and whether your legal team accepts source-available terms for an internal cache.
Dokku official Redis plugin
Dokku ships no datastores by default and adds Redis through an official plugin, then links it to an app so the connection settings reach the process. This fits a single-server PaaS with Git-push deploys and a small number of caches or session stores. Persistence, backups and failover are your responsibility on that host. The plugin's behavior, default settings and backup options should be confirmed in its README before you size the server.
Coolify one-click Redis
Coolify offers a one-click Redis service from its dashboard, which suits teams that prefer a web interface over the command line for provisioning and wiring apps to a cache. Coolify manages the servers over SSH, so you still own the host's capacity, patching and backup storage. Confirm the image and Redis version it deploys, how persistence volumes are configured and whether backups of the cache are offered before you rely on it for queues.
How to size Redis for caches, queues and sessions
A cache holds copies of data that can be rebuilt from a primary source such as PostgreSQL, so losing it costs latency rather than correctness. Sizing starts with the working set, meaning the keys that are read often enough to be worth keeping in memory, plus headroom for overhead per key. The eviction policy decides what happens when memory fills, and for a pure cache an LRU or LFU policy is usually the expected choice. Persistence is often optional here, and many teams run without RDB or AOF because a restart simply warms the cache again.
- Memory driver: the size of the working set and the per-key overhead, not the total size of the source database.
- Eviction policy: confirm that the configured
maxmemory-policymatches the intent, because a policy that refuses writes can break the application. - Persistence: RDB snapshots at intervals are usually enough, or none at all, if a cold start is acceptable.
- Failover: a replica improves availability during a restart, but a cache rarely needs Sentinel unless the application stalls without it.
- Cold start load: a flushed cache sends traffic back to PostgreSQL, so size the database for that surge.
Check the peak memory and hit rate in your Heroku Redis metrics before choosing a server size.
Queues such as those used by Sidekiq, Celery or Bull store jobs that must eventually run, so the data is the work itself. Memory grows with the backlog, which means a slow worker or a burst of enqueued jobs can exhaust memory quickly. Eviction is a problem here: an eviction policy that drops keys can silently delete jobs, so queue instances should not evict keys at all and should instead alert on memory pressure. Durability matters more than in a cache, and AOF with a sensible fsync setting is commonly chosen for queue data.
- Memory driver: the maximum backlog you expect during a worker outage, multiplied by the average job payload size.
- Eviction policy: avoid evicting queue keys, and confirm the library's documentation for its expectations.
- Persistence: AOF is generally the better fit, because RDB snapshots can lose the jobs written since the last snapshot.
- Failover: a replica or Sentinel setup reduces the chance that a failover loses queued jobs, and the application should tolerate duplicate execution.
- Separation: running the queue on its own instance keeps a cache flush from affecting jobs.
Confirm how your job library handles a lost or duplicated job before you pick the persistence mode.
A session store holds login state for each user, so its size grows with concurrent users and the amount of data kept per session. Losing sessions forces users to sign in again, which is an availability problem for the business but not a data loss problem for the company. Session data is usually small per key, but it must be consistently available, so the choice of eviction and failover matters more than raw throughput. Teams should decide whether an eviction policy could log users out unexpectedly and whether session expiry is set on every key.
- Memory driver: concurrent sessions multiplied by the stored data per session and the session lifetime.
- Eviction policy: an eviction policy that removes sessions under pressure can sign users out, so size memory to avoid it.
- Persistence: RDB snapshots or AOF both reduce forced sign-outs after a restart, and the choice depends on how often sessions change.
- Failover: Sentinel with at least three Sentinel instances is a common pattern when the store must survive a node failure.
- Expiry: confirm that each session key carries a TTL that matches your login policy.
Review your session timeout settings and concurrent user peaks in your current metrics before setting memory limits.
Persistence and failover choices apply across all three workloads, and they are the part of the migration that changes most when you leave Heroku Redis. Heroku's managed add-on handles snapshots and replicas for you, whereas a self-hosted instance runs only the mechanisms you configure. RDB writes point-in-time snapshots that are compact and fast to load but can lose recent writes. AOF logs each write and is more durable, at the cost of larger files and more disk activity. Neither replaces a tested backup stored off the host.
- RDB versus AOF: RDB suits caches and sessions with tolerance for losing recent writes, while AOF suits queues.
- Snapshot schedule: set
saveintervals to match the loss you can accept, and test restores. - Sentinel: Valkey Sentinel and Redis Sentinel both need at least three Sentinel instances for a robust deployment, and they apply only when you do not use Cluster.
- Backups: copy RDB or AOF files off the host, because a Dokku or Coolify Redis service does not back itself up by default.
- Memory limits: set
maxmemorybelow host RAM so the operating system and forks have room during snapshots.
Confirm your failover and restore procedure with a test restore before cutover.
What persistence, backups and failover look like once Heroku no longer runs them
On Heroku, the managed Redis instance handles the operational work: the provider runs the instance, and the team's job is mostly to pick a plan and watch the app. On Dokku or Coolify, that work moves to your team. You decide whether Redis persists to disk with RDB snapshots, an append-only file (AOF), or both, and you set the save points and fsync policy that match how much cache or queue data you can afford to lose. Then you copy those files off the host on a schedule, keep at least one copy outside the server, and test a restore into a scratch instance before you need it. Confirm the persistence settings in the Valkey or Redis configuration you deploy, and confirm the backup path with whichever plugin or one-click template you use, since neither gives you the off-host copy or the restore test by default. Monitoring, memory alerts and eviction policy also become your responsibility.
Failover is the largest difference. Valkey Sentinel provides high availability when you are not using Valkey Cluster, and it promotes a replica when the primary fails. The Valkey Sentinel documentation recommends at least three Sentinel instances, so a quorum can still agree when one node is down. Sentinel needs at least one replica, its own network reachability and client configuration that follows the failover, so plan those steps before you rely on it. A single-server Dokku host is a single point of failure for the Redis container, the app containers and the proxy together, so a host outage stops the cache and the queue at once. Coolify runs on a host too, so the same question applies there. Decide whether a single-server design is acceptable for each workload, or whether sessions and queues need replicas on separate machines.
Rollbacks do not cover this data. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, and the same applies to Redis data. Redeploying an older image leaves the keys in place, and restoring keys requires a snapshot or AOF from before the problem. Write a runbook that names where the snapshots are kept, who can restore them, and how long a restore takes in your environment. Then run it once in a test environment before cutover.
Moving Redis data and clients from Heroku to Valkey
This sequence moves a Heroku Data for Redis instance to a Valkey server you run, with a verified dataset, repointed clients and a rollback path if the cutover goes wrong.
Inventory keys, clients and the source version
The application owner and the platform engineer list every Redis use: caches, queues, sessions, rate limits and any pub/sub channels. They record which app processes connect, which client libraries they use, and the exact Redis version reported by the Heroku instance. The version check matters most. Valkey's migration guide says Redis Community Edition 7.4 and later write data files that Valkey cannot read, so those instances need a different method that the guide does not cover. Confirm the version with Heroku support or the instance's own reporting before choosing a method. Done means you have a written list of keys by purpose, the client libraries in use, and a confirmed Redis version of 7.2 or earlier, or a plan for the newer case.
Choose the data transfer method
The platform engineer selects one of the four methods in Valkey's migration guide. An RDB snapshot copy suits a cache that can be rebuilt or a short maintenance window. REPLICAOF replication followed by promotion keeps the target in sync until cutover, which fits sessions and queues that must not lose recent writes. MIGRATE moves selected keys only, useful when a single queue or namespace needs to move first. For clustered sources, adding Valkey nodes as replicas and promoting them with CLUSTER FAILOVER is the documented path. Record the choice and the reason, because it sets the cutover steps. Done means a short decision note that names the method, the data it covers and the accepted data loss window, if any.
Stand up Valkey and load the data
The platform engineer installs Valkey on a server or container in the same network as the Dokku or Coolify application, using a release line that matches or exceeds the source version. Valkey 9.1 is the current stable line according to the release page, and Valkey reads and writes RDB and AOF files compatible with Redis OSS 7.2. Load data with the chosen method: for a snapshot, copy the RDB file and start Valkey from it; for replication, point the new instance at the Heroku Redis endpoint with REPLICAOF and wait for the sync to finish. Set a password, restrict network access to the application hosts and enable persistence settings that match your recovery goals. Done means the replication link is up or the snapshot has loaded, and DBSIZE on the target matches the source within the expected write activity.
Repoint client configuration without code changes
The application owner updates the connection URL in the environment, typically the Redis URL variable that the app reads, so it targets the Valkey host. Valkey's migration guide states that existing Redis client libraries connect without code changes, so the work is configuration: host, port, TLS settings if used, and the password. Apply the change in a staging environment first and confirm that sessions are created, cache reads hit and queue workers pick up jobs. If the app uses Redis modules, confirm they use the RedisModule_ API, which the guide says works in Valkey. Done means a staging deploy logs in, writes a session, reads a cached value and processes one queued job, with no errors in the application logs.
Validate data and behavior before cutover
The platform engineer compares sample keys, key counts by pattern and TTL distribution between Heroku and Valkey, and runs the application's critical paths against the new endpoint under realistic load. For queues, the team checks that job counts and dead-letter handling match. For sessions, they confirm that a user logged in on the old host can be recognized after cutover if that is a requirement. Record the results in a checklist. Done means the checklist is signed off by the application owner, with any mismatch explained or fixed, and the expected write rate on the source has been confirmed for the cutover window.
Cut over and keep the rollback path open
During the agreed window, the team stops or pauses writes where the application allows, promotes the Valkey replica or confirms the final snapshot, and switches the configuration to the new endpoint. The Heroku Redis instance stays running and unchanged until the new host has served traffic for an agreed period. The rollback plan names the trigger, such as error rates or failed job processing, and the exact configuration change that returns traffic to Heroku. Be aware that writes made to Valkey during the rollback window will not appear in Heroku unless you copy them back. Done means traffic is confirmed on Valkey, error rates are within the baseline, and the rollback steps were rehearsed in staging.
Close out persistence, backups and monitoring
Heroku handled backups, failover and patching for the managed instance, so the platform team now owns those duties. Dokku's Redis plugin and Coolify's one-click Redis set up the service, but backup and high availability are not the same as Heroku's managed features. Decide whether Valkey needs Sentinel for failover, which Valkey documents for setups not using Valkey Cluster and recommends with at least three Sentinel instances. Schedule snapshot or AOF backups to storage you control, test a restore on a separate host, and add memory and eviction alerts. Once monitoring and restore tests pass, decommission the Heroku Redis add-on after the rollback window closes. Done means a documented restore test, an alert on memory use, and a dated decommission record.
What teams ask before replacing Heroku Redis
What does it cost to replace Heroku Redis with a self-hosted Valkey or Redis instance?
The cost is mostly the servers and the people who run them, not a license fee for Valkey, which is BSD-3-Clause, or for Redis versions under AGPLv3. Line items to ask for in a quote are the cache server or servers, a replica and at least three Sentinel instances if you want automatic failover, backup storage for snapshots, monitoring and alerting, patching and upgrade time, and on-call coverage. Server and storage costs recur monthly, while the initial build, runbooks and migration are one-time. Costs rise with memory size, replication depth and how many environments you run. Ask for each line item separately so you can compare it with your current Heroku Data for Redis bill, which is metered per plan.
How long does a Redis migration from Heroku take, and what makes it longer?
No fixed duration is supplied for this migration, so treat any number from a vendor or partner as a claim to verify. The main drivers are the dataset size, whether you can tolerate a short write freeze, the number of applications that connect to the cache, and whether any client uses features that need testing. Valkey's migration guide documents four methods, including copying an RDB snapshot, replication with REPLICAOF followed by promotion, key-level MIGRATE for selected keys, and cluster node promotion, and the method you choose sets the cutover window. Plan extra time for staging tests against the same client library versions your applications use.
What does my team need to provide before a Redis migration starts?
You need someone who understands your cache usage, including which keys act as caches, which hold queue or session state, and what eviction behavior the application expects. Engineers should be able to operate Redis or Valkey on Linux, read RDB and AOF persistence settings, and manage Sentinel or cluster topology. Provide access to the Heroku app and its config vars, a staging environment, DNS and secret management, and a place to store runbooks. Confirm with your own security team who may connect to the cache and how credentials rotate, since these are your decisions to make.
Can our own engineers migrate Heroku Redis to self-hosted Dokku or Coolify without outside help?
Yes, a team with Linux and Redis experience can do it, and the Dokku and Coolify docs describe the install steps for their own platforms. The harder parts are not the install but the operations afterward: backups, restore testing, failover, security patches and capacity planning. Dokku's official plugins cover Postgres and Redis, but its default setup runs on a single server, so failover needs a deliberate design. Decide who will carry pager duty before you start. Outside help is most useful for fixed-scope work such as a written migration plan, hardening, and runbook and restore tests, which DeployOpen plans and documents within the client's own infrastructure.
Is Valkey safe to use as a drop-in replacement for existing Redis clients?
Valkey is designed as a drop-in replacement for Redis OSS 7.2 and earlier. Valkey's migration guide says existing Redis client libraries connect without code changes, and that it reads and writes RDB and AOF files compatible with Redis OSS 7.2. Modules written for the RedisModule_ API also work. The guide warns that Redis Community Edition 7.4 and later write data files that Valkey cannot read, so those sources need a different migration method that the guide does not cover. Test your exact client library and version against Valkey in staging before cutover.
Which Redis version and license apply if I want Redis 8 instead of Valkey?
Redis Open Source 8.0 and later can be used under your choice of RSALv2, SSPLv1 or AGPLv3, effective from the Redis 8 general availability release. Redis 7.4.x through 7.8.x remain under the dual RSALv2 or SSPLv1 license, which is not OSI-approved, while Redis 7.2.x and earlier remain under BSD-3-Clause. Redis Ltd. has said it plans to keep Redis Open Source under AGPLv3. Note that the Intel SVS-VAMANA vector optimizations are closed source and can only be used under RSALv2. Have your legal team confirm which license option fits your use case before you choose a version.
How is high availability handled for a self-hosted Redis or Valkey cache?
High availability is not automatic on a single Dokku or Coolify server. Both Redis Sentinel and Valkey Sentinel provide automatic failover that promotes a replica to master when you do not use cluster mode, and both docs recommend at least three Sentinel instances for a robust deployment. Sentinel needs separate hosts or failure domains to be useful, so it adds servers to your bill and to your runbooks. Valkey Cluster is the alternative when you need sharding. Confirm the failover behavior with your client library, because applications must reconnect to the new master and handle brief errors during the switch.
How Redis keeps working with Postgres, the app and the rest of the stack
The Redis service sits beside your database on the same Dokku host or Coolify server, not on a separate managed endpoint. The app reaches it over the private network that the platform creates for its containers, so the Redis port should never be published to the public internet. Confirm this in your own environment by checking which ports the Redis container exposes and that your firewall blocks them from outside. The same pattern applies to PostgreSQL: the dokku-postgres plugin or a Coolify-managed database runs on that host, and each app receives its connection details as environment variables. Each app gets its own connection string config var, such as one pointing at the Redis service that the plugin or Coolify creates, so an app's cache and queue traffic is wired explicitly rather than inherited from a shared default.
Heroku config vars do not move automatically. Heroku's REDIS_URL and DATABASE_URL values point at add-on endpoints that will stop resolving once you cut over, so you must re-create every connection setting in Dokku's config or Coolify's environment variable screen and confirm that the application reads the same key names. Check the library defaults too, because some Redis clients fall back to localhost when a variable is missing, which can look like a working deploy until the first cache miss. Other Heroku add-ons, such as logging, scheduling, or email, remain separate decisions with their own owners, costs and data paths. Plan each one on its own, so that a Redis cutover does not quietly depend on a service you have not yet replaced.
How DeployOpen scopes and delivers a Redis replacement
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Redis replacement is scoped against your cache, queue and session workloads before any server is touched. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Heroku Data for Redis plans and workloads are in use, separating caches, queues and session stores
- Record persistence needs, eviction expectations and whether failover must be automatic or can be manual
- Agree in writing whether the target is Valkey or Redis Open Source, and which license and version line that implies
- Confirm the hosting target, backup destination and who receives alerts before a quote is issued
How we build
- Deploy Redis or Valkey on the chosen host with Dokku's Redis plugin or Coolify's Redis resource, as the scope specifies
- Configure persistence settings, memory limits and Sentinel or replication only where the agreed availability target requires them
- Test client reconnection, key migration with the agreed method and rollback steps in a non-production environment
- Document configuration keys, file locations and backup procedures so the platform can be operated after handover
How we hand over
- Provide a written runbook covering restores, version upgrades, failover checks and capacity thresholds
- Walk your operations team through monitoring, alerting and the cutover checklist before production traffic moves
- Deliver evidence of backup restores and documented controls for your own compliance assessors to review
- Confirm ownership of credentials, server access and the rollback path in the handover record
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainer scope can cover Valkey or Redis patch releases, backup verification and periodic restore tests
- Ask for the support scope, response expectations and upgrade approach to be written into the quote
- Compliance readiness work is prepared for your independent auditors, which issue any audit report or certification
