Implementing Failover for Plex and Docker Containers with Keepalived
Introduction
Ensuring the uninterrupted availability of media services is becoming increasingly important for home labs, small businesses, and enterprise environments alike. Plex, one of the most popular media server platforms, runs exceptionally well inside Docker containers. However, like any self-hosted service, Plex is vulnerable to outages if the underlying server or container fails. This is where Keepalived enters the picture, providing a reliable and battle-tested method for achieving high availability through virtual IP failover.
This long-form guide explains how to implement failover for Plex and Docker containers using Keepalived. Whether you run a multi-node Docker environment, a simple two-server setup, or a more advanced Kubernetes deployment, Keepalived can help you maintain continuity with minimal downtime. You will also find best practices, example configurations, diagrams, and optimization tips for ensuring that your Plex media server and supporting containers remain available even if one node goes offline.
Understanding the Role of Keepalived in Docker and Plex Failover
Keepalived is a lightweight high-availability solution built on VRRP (Virtual Router Redundancy Protocol). With VRRP, multiple servers share a single virtual IP (VIP), and only one server at a time is considered the MASTER. If the MASTER node fails or becomes unreachable, one of the BACKUP nodes automatically takes over the VIP. This seamless transition ensures that clients connected to Plex or any other service continue operating without noticing an outage.
How Keepalived Enables Failover
Keepalived operates on a heartbeat mechanism. Every node sends periodic VRRP advertisements. If the MASTER node stops responding—because of a hardware failure, system crash, network issue, or Docker container failure—the BACKUP node recognizes the problem and takes control of the VIP. You can even integrate health checks that respond to conditions like:
- Plex container not responding on port 32400
- Docker service stopped on the MASTER node
- Filesystem errors
- Resource exhaustion
- Custom scripts evaluating system health
Because the VIP remains constant, clients always connect to the same address. Failover is instant and does not require DNS propagation or manual intervention.
System Requirements for Plex Failover with Keepalived
Before getting started, ensure you have the following minimum system components ready:
- Two Linux servers running Ubuntu, Debian, Rocky Linux, or similar
- Docker and Docker Compose installed on both nodes
- Plex container configured identically on each server
- A synchronized library structure, either through shared storage or scheduled replication
- A floating virtual IP address configured for failover
- Keepalived installed on each node
- Administrative SSH access
If you need help setting up Docker or Plex, refer to your home lab documentation or visit {{INTERNAL_LINK}} for additional setup steps.
Configuring Plex and Docker Containers for Redundancy
Before integrating Keepalived, ensure your Plex container is running properly on both servers. Each instance must be configured identically so that switching between servers does not disrupt ongoing Plex sessions. It is ideal to store Plex metadata and media files on shared storage, such as NFS, SMB, GlusterFS, or a replicated dataset.
Example Docker Compose Configuration
The following snippet provides an example Plex Docker Compose deployment to run on both nodes:
<pre>
version: “3”
services:
plex:
image: linuxserver/plex
container_name: plex
restart: always
network_mode: host
environment:
– PUID=1000
– PGID=1000
– VERSION=docker
volumes:
– /mnt/media:/media
– /mnt/plex-config:/config
</pre>
This configuration ensures minimal downtime if the VIP switches nodes. Because Plex runs in host mode, the service becomes reachable on the same port regardless of which server is active.
Installing and Configuring Keepalived
Once your Docker environment is prepared, the next step is installing Keepalived on both servers.
Installation
On Ubuntu or Debian-based distributions, run:
<pre>
sudo apt update
sudo apt install keepalived -y
</pre>
On RHEL or Rocky Linux systems:
<pre>
sudo dnf install keepalived -y
</pre>
Keepalived Configuration Files
Keepalived uses a configuration file typically located at /etc/keepalived/keepalived.conf. You will configure unique priorities for each node. The server with the higher priority becomes the MASTER.
Example MASTER Node Configuration
<pre>
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass plexFailover
}
virtual_ipaddress {
192.168.1.200
}
track_script {
check_p
}
}
vrrp_script check_p {
script “/usr/local/bin/check_plex.sh”
interval 5
weight -20
}
</pre>
Example BACKUP Node Configuration
<pre>
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass plexFailover
}
virtual_ipaddress {
192.168.1.200
}
track_script {
check_p
}
}
vrrp_script check_p {
script “/usr/local/bin/check_plex.sh”
interval 5
weight -20
}
</pre>
Creating a Health Check Script for Plex
Health checks are essential for ensuring the VIP only stays on the node where Plex is functioning correctly. Below is a simple script example.
<pre>
#!/bin/bash
curl -s http://localhost:32400/web/index.html >/dev/null 2>&1
if [ $? -ne 0 ]; then
exit 1
fi
exit 0
</pre>
Save this script as /usr/local/bin/check_plex.sh, and make it executable:
<pre>
sudo chmod +x /usr/local/bin/check_plex.sh
</pre>
If Plex stops responding on the MASTER node, the script will fail and Keepalived will reduce the priority, causing a failover to occur.
Comparison of Failover Approaches
| Failover Method | Pros | Cons |
| Keepalived with VIP | Fast failover, no DNS propagation, simple setup | Requires duplicate infrastructure |
| Load Balancer | Distributes traffic, scalable | Not ideal for Plex because stateful sessions |
| DNS Failover | Easy to configure | Slow propagation, not seamless |
Testing Failover
Simulate a failure by shutting down Dockerd or stopping the Plex container on the MASTER node:
<pre>
sudo systemctl stop docker
</pre>
Within seconds, Keepalived should transition the VIP to the BACKUP node. Test connectivity by opening Plex in your browser using the VIP address:
Best Practices for Plex and Docker High Availability
- Synchronize Plex metadata using shared storage or rsync
- Use SSDs to reduce container startup time
- Monitor Keepalived logs using journalctl
- Maintain identical Docker and Plex versions across nodes
- Test failover monthly to verify reliability
- Use UPS devices to prevent power fluctuations
- Consider pairing Keepalived with a NAS for multi-path redundancy
Recommended Hardware and Tools
- High-performance NAS server
- SSD storage array
- Dual 10GbE network card
- Compact home lab server
- Managed switch with VLAN support
Conclusion
Implementing failover for Plex and Docker containers with Keepalived transforms your media server setup into a reliable and highly available platform. With the help of VRRP, virtual IP addresses, and smart health checks, you can ensure uninterrupted entertainment for family, guests, or customers. This guide provides all the essential knowledge, from Docker configuration to Keepalived scripting, helping you create an environment that survives node outages without service disruption.
FAQ
Does Keepalived work with any Docker container?
Yes, Keepalived can manage failover for any Docker container as long as it is accessible via a consistent IP and port.
Do I need shared storage for Plex failover?
Shared storage is strongly recommended to ensure metadata and media consistency between nodes, but replication strategies also work.
Can this configuration run on Raspberry Pi?
Yes. Keepalived and Docker both run on ARM platforms like Raspberry Pi, although performance may vary.
Is failover instant?
Failover usually takes 1–3 seconds depending on your advertisement interval.
Does Plex remember playback position after failover?
Yes, assuming metadata is stored on shared storage or replicated correctly.
