---
title: "Rolling the Heroku Redis Fleet"
description: "Heroku proactively rolled its Redis fleet to a version not vulnerable to CVE-2018-11218 during an embargo, aiming to protect customers while limiting disruption and downtime. The operation relied on immutable infrastructure: engineers built, tested, reviewed, and released a new server image, then replaced High Availability standbys before scheduling customer maintenance. During each update, the team verified replication, broke the link so the standby could accept writes, redirected application config vars to the new primary, de-provisioned the old primary, and created a replacement standby. Automation controlled concurrency and limited replacement work to the on-call operator’s business hours, while customers received advance and completion emails. The fleet roll covered all Heroku Redis customers within five weeks of notification and finished one week before the public announcement; the process also applies to Heroku Postgres and Apache Kafka on Heroku."
---

# Rolling the Heroku Redis Fleet

[Heroku](https://yomu.fyi/company/heroku) · Camille Baldock · Jun 27, 2018

**Type:** Explainer

## Summary

Heroku proactively rolled its Redis fleet to a version not vulnerable to CVE-2018-11218 during an embargo, aiming to protect customers while limiting disruption and downtime. The operation relied on immutable infrastructure: engineers built, tested, reviewed, and released a new server image, then replaced High Availability standbys before scheduling customer maintenance. During each update, the team verified replication, broke the link so the standby could accept writes, redirected application config vars to the new primary, de-provisioned the old primary, and created a replacement standby. Automation controlled concurrency and limited replacement work to the on-call operator’s business hours, while customers received advance and completion emails. The fleet roll covered all Heroku Redis customers within five weeks of notification and finished one week before the public announcement; the process also applies to Heroku Postgres and Apache Kafka on Heroku.

## Context

Heroku needed to update its entire Redis fleet for an embargoed vulnerability while keeping customers safe and minimizing disruption, downtime, operational errors, and on-call fatigue.

## Approach / What changed

Heroku used immutable server images, a staged High Availability replacement process, scheduled maintenance windows, replication checks, controlled concurrency, and business-hours scheduling to roll out the update across the fleet.

## Takeaways

- Paid Heroku Redis plans use High Availability, with a standby that automatically replaces a failed primary and updates asynchronously.
- The fleet patch process replaces standbys first, verifies replication, promotes a patched standby by breaking the replication link, updates application config vars, and creates a new standby.
- The Redis fleet roll reached all customers within five weeks of vulnerability notification and beat the public announcement by one week.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [High Availability](https://yomu.fyi/topic/high-availability), [Redis](https://yomu.fyi/topic/redis), [Security](https://yomu.fyi/topic/security)

- Source: [Heroku](https://www.heroku.com/blog/rolling-redis-fleet)
- Source URL: https://www.heroku.com/blog/rolling-redis-fleet
- Ingested by Yomu: 2026-09-09T14:26:42.925Z

[Read original post](https://www.heroku.com/blog/rolling-redis-fleet)