Redis

Part of the Sidecar Services catalog.

What it does

Redis is an in-memory data store. As a sidecar it backs a persistent object cache or session store for WordPress locally, standing in for the managed Redis a hosting platform provides in production. Add it when a project uses a Redis-backed object cache (for example the Redis Object Cache plugin) and you want the same caching layer on your machine.

How it works

The preset pins redis:7-alpine and listens on container port 6379. Redis is headless: it gets no browser UI and no host port. WordPress connects to it only over the Docker network. Data is not persisted to a volume, so the cache is cleared when the container is recreated, which matches how a volatile cache behaves.

wdg my-site service add redis

There is no UI to open. Confirm it is attached with wdg my-site service list, where it shows as internal only.

How it integrates with the local WordPress container

Adding the sidecar injects these env vars into the WordPress container:

Variable	Value
REDIS_HOST	wdg-my-site-redis (the @HOST token resolved at add-time)
REDIS_PORT	6379

WordPress reaches Redis over wdg-network at wdg-my-site-redis:6379. There is no host port; the connection is container-to-container only.

These env vars are connectivity hints. The project supplies the object-cache drop-in or plugin that consumes them. With the Redis Object Cache plugin, define the connection in wp-config.php from the injected env:

define( 'WP_REDIS_HOST', getenv( 'REDIS_HOST' ) ); // wdg-my-site-redis
define( 'WP_REDIS_PORT', getenv( 'REDIS_PORT' ) ); // 6379
define( 'WP_CACHE', true );

The plugin still has to be installed and its object-cache.php drop-in enabled. Adding the sidecar wires reachability only; it does not turn on caching.

Add and remove

wdg my-site service add redis
wdg my-site service remove redis  # no data volume to keep; --purge is a no-op here