Caching is no longer an optional optimization in modern e-commerce architectures; it is the backbone of performance, scalability, and high availability. Shopware 6.7 has significantly evolved its caching strategy, moving away from filesystem-bound caches toward distributed, memory-backed solutions. At the heart of this transition lies Redis. Whether you are running a single-node deployment or scaling across multiple servers, correctly configuring Redis will dramatically reduce database load, accelerate page render times, and stabilize session handling under heavy traffic.

This guide walks you through the practical steps, architectural context, and production-ready practices required to configure Redis for Shopware 6.7 and beyond.

Why Redis is Essential in Shopware 6.7+

Shopware 6.7 decouples cache layers more explicitly than previous versions. The platform now relies on Symfony’s cache component under the hood, which means your cache infrastructure must support PSR-6 standards, high-throughput read/write operations, and atomic operations for distributed locking. Redis excels here because it operates entirely in RAM, supports sub-millisecond response times, and provides built-in structures like sorted sets, pub/sub, and clustering that align perfectly with Shopware’s internal caching requirements.

In practice, Redis handles three critical workloads in Shopware:

  1. Distributed Cache Layer: Stores metadata, data cache, and configuration snapshots shared across nodes.
  2. Session Storage: Replaces filesystem sessions with persistent, lock-free session handling.
  3. Internal State & Queue Backing: Powers cron execution tracking, message bus state, and admin dashboard aggregation.

Without Redis configured properly, Shopware gracefully falls back to Symfony’s file-based cache provider. While functional, this introduces I/O bottlenecks, limits horizontal scaling, and can cause session loss on cluster deployments.

Prerequisites & Environment Readiness

Before touching configuration files, ensure your infrastructure meets the following baseline:

  • Redis 7.0+ is recommended for improved memory management and security defaults.
  • Your Redis instance must be reachable from all Shopware application nodes via TCP/TLS.
  • Allocate a dedicated Redis server or container; avoid co-hosting with production databases or heavy workloads.
  • Ensure your Shopware 6.7 environment runs PHP 8.2+ with ext-redis or symfony/redis-messenger installed.

Verify connectivity from your application server:

redis-cli -h <REDIS_HOST> -p 6379 ping
# Expected: PONG

Core Configuration Steps

Shopware 6.7 uses environment variables as the primary configuration mechanism. You will configure Redis through your .env file or server-level environment provider. The platform expects specific prefixes to wire cache pools, sessions, and distributed state correctly.

Add or update the following variables in your .env.local (or equivalent runtime provider):

# Distributed Cache Layer
SHOPWARE_CACHE_DISTRIBUTED_HOST=redis://<REDIS_USER>:<REDIS_PASSWORD>@<REDIS_HOST>:6379/0

# Session Storage
SHOPWARE_SESSION_DRIVER=redis
SHOPWARE_SESSION_HOST=redis://<REDIS_USER>:<REDIS_PASSWORD>@<REDIS_HOST>:6379/1
SHOPWARE_SESSION_LIFETIME=86400

# Optional: Force Redis for all cache layers (fallback to distributed)
APP_CACHE_REDIS_URL=${SHOPWARE_CACHE_DISTRIBUTED_HOST}

The HOST parameter accepts standard Redis URL format. The /0 and /1 suffixes denote Redis databases; Shopware keeps data cache in 0 and session data in 1 to avoid key collisions. If you prefer Sentinel or Cluster mode, replace the URL scheme accordingly:

  • Sentinel: redis-sentinel://<HOST>:26379/<MASTER_NAME>
  • Cluster: rediss://<HOST1>:6379,<HOST2>:6379/<DB_INDEX> (TLS enforced for cluster)

After updating environment variables, clear Shopware’s cache to force Symfony to rewire the cache pools:

bin/console cache:pool:clear doctrine.system_cache
bin/console cache:clear

Deep Dive: How Shopware Uses Redis Under the Hood

Shopware 6.7 does not treat caching as a single monolithic layer. It partitions workloads intelligently:

  • Metadata Cache: Stores routing rules, plugin registration, and configuration schema. This pool is read-heavy and benefits from Redis’s fast string/hash structures.
  • Data Cache: Caches product, customer, and checkout calculations. High write frequency requires careful eviction policies.
  • HTTP Cache Backend: While Varnish or Nginx handles frontend HTTP caching, Shopware uses Redis for backend lookups, TTL management, and cache invalidation hooks.
  • Session & State Store: Replaces PHP’s native session handler. Sessions are stored as serialized arrays with automatic expiry, enabling sticky-session-free load balancing.

When you set SHOPWARE_CACHE_DISTRIBUTED_HOST, Shopware registers it as the default PSR-6 pool provider. Any cache tagged with shopware.cache or shopware.metadata automatically routes through Redis. If you omit this variable, Symfony silently falls back to the filesystem adapter, which is why explicit configuration is non-negotiable in production.

Security, Persistence & Production Best Practices

A raw Redis installation is a security and reliability risk if left unhardened. Apply these practices to your Shopware deployment:

  1. Network Isolation: Never expose Redis publicly. Use VPC peering, firewall rules, or Kubernetes NetworkPolicies to restrict access to application nodes only.
  2. Authentication: Always set REDIS_PASSWORD. Disable CONFIG SET requirepass on the fly; enforce it via redis.conf.
  3. Memory Limits & Eviction: Set maxmemory to 70-80% of available RAM. Use eviction-policy allkeys-lru to prevent OOM crashes during traffic spikes.
  4. Persistence Configuration:
    • AOF (appendonly yes) for durability across restarts.
    • Disable RDB snapshots in high-write environments; use Redis 7’s hybrid persistence or offload backups via replica sync.
  5. Monitoring: Deploy Redis Exporter + Prometheus/Grafana to track hit rates, memory fragmentation, and replication lag. Aim for >90% cache hit ratio on data pools.

Verification & Troubleshooting

After deployment, validate the configuration:

# Check connected clients (should show your app server IPs)
redis-cli -h <HOST> INFO clients | grep connected_clients

# Verify key distribution across databases
redis-cli -n 0 dbsize
redis-cli -n 1 dbsize

# Test cache writes from Shopware context
bin/console app:cache-stats

Common pitfalls include:

  • Timeout errors: Increase SHOPWARE_CACHE_DISTRIBUTED_TIMEOUT_MS if network latency exceeds 5ms.
  • Key collisions: Ensure /0 and /1 databases are isolated; avoid shared prefixes.
  • Authentication failures: Verify that redis-cli and Shopware use identical credentials; URL-encoded passwords must match exactly.

If cache stats remain at zero after warmup, check Symfony’s debug bar or inspect var/cache/prod/Container*/cache.php to confirm the Redis adapter is registered. You can also run php bin/console cache:pool:clear app.cache.data to force a cold start and monitor real-time writes via redis-cli monitor.

Conclusion

Configuring Redis for Shopware 6.7 is straightforward, but getting it right requires understanding how the platform partitions caching workloads and how Symfony’s infrastructure layer maps to distributed systems. By explicitly defining distributed cache hosts, isolating session storage, hardening network access, and monitoring hit rates, you transform Redis from a simple key-value store into the performance engine of your Shopware deployment. Regularly review memory fragmentation, eviction trends, and connection pools as traffic grows. With Redis properly wired, your Shopware 6.7 instance will scale predictably, respond faster under load, and provide a stable foundation for multi-node high-availability architectures.