ValKey/Redis als Cache im Container

Ein In-Memory-Cache wie ValKey beschleunigt Shops und WordPress spürbar: Sessions, Objekt-Cache und Full-Page-Cache-Tags landen im RAM statt in der Datenbank. ValKey ist der offene Redis-Ersatz (protokollkompatibel, unter der Linux Foundation entstanden, nachdem Redis seine Lizenz geändert hat) — für deine Anwendung verhält er sich wie Redis, inklusive Port 6379. Besonders profitieren Magento, Shopware und Pimcore — die kompletten Anbindungs-Snippets stehen unten.

Voraussetzungen

• Rootless Docker + Compose — siehe Grundlagen und Compose.

Schritt für Schritt

1. Leg das Projekt an: mkdir -p ~/docker/valkey && cd ~/docker/valkey
2. Erstelle die compose.yaml:

   services:
     valkey:
       image: valkey/valkey:8
       restart: unless-stopped
       ports:
         - "127.0.0.1:6379:6379"

3. Starte den Dienst: docker compose up -d
4. Teste die Verbindung: docker exec -it valkey-valkey-1 valkey-cli ping — Antwort: PONG.
5. Binde deine Anwendung an 127.0.0.1, Port 6379 (siehe unten).

Anbindung an deine Anwendung

ValKey nutzt getrennte Datenbank-Nummern (0–15) als Namensräume — die Snippets unten verteilen Cache und Sessions bewusst auf verschiedene Nummern, damit ein gezieltes Leeren nicht alles wegräumt.

WordPress (LiteSpeed + LSCache)

Unser WordPress-Hosting läuft mit LiteSpeed und dem LSCache-Plugin — die Verkabelung passiert deshalb im Plugin, ein zusätzliches Redis-Plugin ist nicht nötig:

1. Öffne im WordPress-Admin LiteSpeed Cache → Cache → Objekt.
2. Setz Objekt-Cache auf An und trag ein:
   • Methode: Redis (spricht auch ValKey — das Protokoll ist identisch)
   • Host: 127.0.0.1
   • Port: 6379
   • Datenbank-ID: 0
3. Speichere — der Verbindungstest im Plugin muss Verbunden melden.

Magento

In der app/etc/env.php die Abschnitte cache und session ergänzen bzw. ersetzen, danach Cache leeren:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
            ],
        ],
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
            ],
        ],
    ],
],
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
    ],
],

Shopware 6

Eine Datei config/packages/cache.yaml anlegen, danach Cache leeren:

framework:
    cache:
        app: cache.adapter.redis
        system: cache.adapter.redis
        default_redis_provider: 'redis://127.0.0.1:6379/0'
    session:
        handler_id: 'redis://127.0.0.1:6379/1'

Pimcore

In der config/config.yaml den Cache-Pool auf Redis stellen (Struktur je nach Pimcore-Version — maßgeblich ist die Doku deiner Version):

pimcore:
    cache:
        pools:
            redis:
                enabled: true
                connection:
                    server: 127.0.0.1
                    port: 6379
                    database: 12

Redis statt ValKey?

Wenn eine Anwendung ausdrücklich das originale Redis verlangt, tauschst du nur die Image-Zeile: image: redis:7. Alles andere — Port, Anbindung, Befehle — bleibt identisch. Für neue Setups empfehlen wir ValKey.

Wenn etwas schiefläuft

Die Anwendung meldet Connection refused auf 6379

Der Container läuft nicht, oder er lauscht auf einem anderen Port.

Lösung: docker compose ps prüfen und docker exec -it valkey-valkey-1 valkey-cli ping direkt testen. Läuft ein zweiter Cache auf dem Port, den Host-Port ändern (127.0.0.1:6380:6379) und die App anpassen.

Nach einem Neustart sind Sessions weg

Normal: Der Cache lief ohne Persistenz — für Cache-Daten in Ordnung, Kunden müssen sich schlicht neu anmelden.

Lösung: Wenn Sessions Neustarts überleben sollen, ein Volume auf /data mappen (siehe Compose-Artikel) — ValKey sichert dann periodisch auf Platte.

Der RAM-Verbrauch wächst und wächst

Ohne Limit füllt ein Cache so viel Speicher, wie er bekommt.

Lösung: Obergrenze mitgeben — in der compose.yaml unter dem Service: command: valkey-server --maxmemory 512mb --maxmemory-policy allkeys-lru. Der Cache verdrängt dann die ältesten Einträge, statt zu wachsen. Verbrauch im Blick behalten: Ressourcennutzung.

Verwandte Artikel

• Docker Compose: Dienste dauerhaft betreiben — die Basis für dieses Setup.
• Magento-Cache leeren und neu indexieren — nach der Umstellung Pflicht.
• OpenSearch im Container — der zweite Baustein für schnelle Shops.

Du kommst nicht weiter?

Cache läuft, aber die Anwendung wird nicht schneller — oder die Verbindung klemmt? Ticket im Kundencenter öffnen — nenn Anwendung und Konfigurations-Auszug, wir schauen drauf.