---
title: Distributed configuration with Redis/Dragonfly
description: Most use cases require a distributed configuration setup.
---
> ## Documentation Index
> Fetch the complete documentation index at: https://docs.page/luizfonseca/super/llms.txt
> Use this file to discover all available pages before exploring further.

Most use cases require a distributed configuration setup. This can be achieved by using Redis or Dragonfly as a distributed cache for storing certificates and distributing Super instances across multiple servers.

## Redis Configuration

To configure Super to use Redis as a distributed cache, you can set the following in your `config.hcl` file:

**config.hcl**
```hcl
store {
  store_type = "redis"
  redis_url = "redis://localhost:6379"
}
```

This will then use Redis as backend storage for certificates, challenges and routes, shared by every Super instance. [Rate limits](/plugins/rate-limit) are shared too.

## Routes

Routes can be stored in Redis, in addition to the configuration file and docker labels. Every instance syncs them in the background (they're never read from Redis while handling a request):

**config.hcl**
```hcl
store {
  store_type = "redis"
  redis_url = "redis://localhost:6379"

  # How often routes are synced from the store (default: 10)
  sync_interval_secs = 10

  # Versions kept for each host, to roll back to (default: 50)
  history_per_host = 50
}
```

- When a host is defined in several places, routes from the store win over docker labels, which win over the configuration file.
- Every change increments a revision. Each instance reports the revision it applied, so you can check that a change reached every instance.
- If Redis can't be reached, the routes from the last sync are kept.
- Hosts saved through the [admin API](/configuration/admin) keep their last versions (`history_per_host`) and changes, so a host can be rolled back, or restored after it was deleted.

See [the specification](/general/specifications#store-keys) for the keys and format.

## Certificates with several instances

Instances sharing a store order each certificate once: before ordering or renewing a domain's certificate, an instance takes a lease on it in the store, and the others skip that domain while it's held. This keeps a deployment with several replicas well under Let's Encrypt's rate limits.

A certificate written by one instance (for example, renewed) reaches the others within `sync_interval_secs`, without restarting them.

## Waiting rooms

Instances sharing a store share each [waiting room](/plugins/waiting-room): its slots, its line, and the key its visitors' cookies are encrypted with.