Sidecar Services
Sidecar services run extra Docker containers next to a project's WordPress container so you can recreate a hosting integration locally instead of mocking it. A sidecar is per-project, joins the shared wdg-network, and is reachable from WordPress by its container name wdg-<project>-<service> on the service's container port.
Each catalog preset pins a known-good image, allocates a host port for any browser UI, and injects the connection environment variables WordPress needs. Adding a sidecar wires up reachability only. Project code (theme, plugin, mu-plugin, or wp-config) is still what consumes the injected env.
For the command reference, the --image escape hatch, the state file, and lifecycle behavior, see Sidecar Services on the Project Commands page.
Catalog
| Service | What it stands in for | Browser UI |
|---|---|---|
| Typesense | Typo-tolerant search backing faceted site search | Yes |
| Elasticsearch | Search and aggregations backing faceted search | Yes |
| OpenSearch | Open-source Elasticsearch fork for search | Yes |
| Meilisearch | Lightweight instant-search engine | Yes |
| WP VIP Search | WP VIP Enterprise Search (ElasticPress on Elasticsearch 7.10.x) | Yes |
| Redis | Object cache and session store | No (headless) |
| Memcached | Object cache store | No (headless) |
| Mailpit | Outbound mail catcher with web inbox | Yes |
| MailHog | Outbound mail catcher with web inbox | Yes |
How a sidecar connects to WordPress
WordPress reaches a sidecar over wdg-network at the container DNS name wdg-<project>-<service> on the container port, never a host port. Browser-facing UIs get a host port auto-allocated from SIDECAR_PORT_RANGE_START..SIDECAR_PORT_RANGE_END (default 7000 to 7999), de-conflicted across all projects. The @HOST token in a preset's injected env expands to that container DNS name at add-time.
Run wdg my-site service list to see each sidecar's image, browser URL, and whether its data persists.