> ## Documentation Index
> Fetch the complete documentation index at: https://docs.routr.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Scale the Location Service with Redis

> For operators growing past one Location Service instance: switch the registration cache from memory to Redis on Docker or Kubernetes.

Store registrations in Redis instead of process memory, so several Location Service instances share one view of where every endpoint is.

## When you need Redis

The Location Service supports two cache providers: `memory` and `redis`. Memory is fine for a single instance. Switch to Redis when any of these apply:

* **You run more than one Location Service instance.** With `memory`, each instance only knows the registrations it received, so lookups on another instance miss them.
* **You balance Peers with `least-sessions`.** The algorithm picks the Peer contact with the fewest active sessions, and that count must be shared across instances. See [Load balancing](/concepts/load-balancing).
* **You want registrations to survive a Location Service restart.** With `memory`, a restart clears the location table until clients register again.

## Prerequisites

* A Redis server reachable from the Location Service, or permission to run one next to it.
* A deployment where the Location Service runs as its own service. The all-in-one `fonoster/routr-one` image always uses the memory provider, so use the split images on Docker or the Helm chart on Kubernetes.

## Switch the cache provider

**Docker Compose**

**1. Add Redis to your Compose file**

Add a Redis service next to the `location` service. The following snippet shows only the services that change.

```yaml compose.yaml theme={null}
services:
  location:
    image: fonoster/routr-location
    expose:
      - 51902
    volumes:
      - ./config/location.yaml:/etc/routr/location.yaml

  redis:
    image: redis:7.0.8-alpine
    expose:
      - 6379
```

**2. Point the Location Service at Redis**

Set `cache.provider` to `redis` and pass the connection in `cache.parameters` as comma-separated `key=value` pairs.

```yaml config/location.yaml theme={null}
kind: Location
apiVersion: v2beta1
metadata:
  region: default
spec:
  bindAddr: 0.0.0.0:51902
  cache:
    provider: redis
    parameters: host=redis,port=6379
```

The accepted keys are `host`, `port`, `username`, `password`, and `secure` (set `secure=true` to connect over TLS). Always set `host` and `port`. Any other key makes the service fail to start.

**3. Restart the services**

Recreate the Location Service so it loads the new configuration.

```bash theme={null}
docker compose up -d redis location
```

**Kubernetes (Helm)**

The `routr-connect` chart uses Redis by default: `location.cache.provider` is `redis` and `redis.enabled` installs a standalone Redis next to the release. If you changed either value, restore them in `values.yaml`.

```yaml values.yaml theme={null}
location:
  cache:
    provider: redis

redis:
  enabled: true
```

To use your own Redis server instead, turn off the bundled one and pass the connection parameters.

```yaml values.yaml theme={null}
location:
  cache:
    provider: redis
    parameters: host=redis.example.internal,port=6379,password=secret

redis:
  enabled: false
```

Apply the change to your release.

```bash theme={null}
helm upgrade sipnet routr/routr-connect --namespace sipnet -f values.yaml
```

The Registry service has its own `registry.cache.provider` and `registry.cache.parameters` values, which also default to Redis. See [Helm values](/reference/helm-values).

## Verify

Check the Location Service logs for the provider it loaded.

```bash theme={null}
docker compose logs location
```

> [!TIP]
>
> The logs include `using redis as cache provider`. On Kubernetes, run `kubectl logs` on a Location pod instead.

Register a softphone, then list the keys in Redis. Each key starts with the endpoint's address of record.

```bash theme={null}
docker compose exec redis redis-cli --scan
```

## Pitfalls

* **Redis connection errors at startup.** The service logs `redis client error` and lookups fail. Check that `host` and `port` resolve from inside the Location Service container.
* **Registrations disappear.** Each entry expires with the registration's `expires` value. Clients must refresh their registration before it expires.
* **Old registrations after switching.** Registrations held in memory are not migrated. Clients appear in Redis after their next REGISTER.

## Related

> **[Location Service reference](/reference/components/location)**
>
> Configuration spec and gRPC API.

> **[Load balancing](/concepts/load-balancing)**
>
> Round-robin, least-sessions, and session affinity.

> **[Load balancing Asterisk](/tutorials/load-balancing-asterisk)**
>
> Put several Asterisk servers behind one Peer.

> **[Deploy on Kubernetes](/guides/deploy-on-kubernetes)**
>
> Install the chart with Redis included.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.