Sidecar Containers: Running Redis, Meilisearch, or a Custom Service Alongside Your App
sidecars: run their own image on the app's network — for services the app needs but that aren't shared across other apps.
Sidecars vs. workers vs. shared services
Three ways to run "something else" alongside your app, and they solve different problems:
| Image | Scope | Use for | |
|---|---|---|---|
workers: |
Same as the app | Per-app | A different process from the same codebase (queue worker) |
sidecars: |
Its own image | Per-app | A dependency this app alone needs (its own Redis, its own search index) |
| Shared services | Its own image | Server-wide | A database or cache multiple apps share, to save RAM |
Declaring a sidecar
sidecars:
redis:
image: redis:7-alpine
volumes:
data: /data
command: "redis-server --maxmemory 256mb"
Neo builds or pulls the sidecar's own image, starts it on the same Docker network as the app, and gives it its own environment — sidecar env vars are not inherited from the app, since a Redis container has nothing to do with your app's DATABASE_URL.
sidecars:
worker-api:
build: ./services/worker # build from a local Dockerfile instead of a pulled image
env:
REDIS_URL: redis://redis:6379
Reach it from the app by container name — redis://redis:6379, not localhost — since it's a separate container on the shared network, not a process inside the app's own container.
Health checks
sidecars:
redis:
image: redis:7-alpine
health:
cmd: "redis-cli ping"
interval: 10s
retries: 3
When to reach for a shared service instead
If two different apps on the same server both want a Redis, running two separate redis sidecars means two containers, two sets of RAM, doing the same job. A shared service runs it once and links both apps to it.
Try it yourself — Neo is free, with every feature unlocked.
Get started free