Sidecar process: definition and meaning

A sidecar is a helper that runs beside a main application and supports it. In Kubernetes it is a container in the same Pod. In local development the word is often used for a separate process, such as a queue worker, started next to the web server.

Updated

The general pattern

Microsoft’s architecture guidance describes the sidecar pattern as deploying components of an application into a separate process or container, to provide isolation and encapsulation. The page compares the sidecar to one on a motorcycle: it is attached to a parent application and shares that application’s lifecycle. Each instance of the application gets its own sidecar, created and retired with it. The examples include service mesh proxies, protocol adapters, and telemetry enrichment.

The Kubernetes meaning

In Kubernetes a sidecar container runs alongside the main application containers in the same Pod. Kubernetes implements it as a special case of an init container: you declare it under initContainers with restartPolicy: Always. It starts before the main containers and keeps running after the Pod has started. Unlike a plain init container, it can talk to the main containers directly, because containers in a Pod always share the same network and can optionally share volumes. When the Pod shuts down, the kubelet delays sending the TERM signal to sidecar containers until the last main container has terminated.

The local development meaning

This is a different thing, and the word is used loosely. On your own machine there is no Pod. A sidecar is another operating system process, with its own process ID, that you start beside the dev server. Typical ones are a queue worker, a scheduler, a WebSocket server, or an asset watcher.

In a Laravel project the helpers are Artisan commands, and a Procfile can start them together:

Code
web: php artisan serve
queue: php artisan queue:work
scheduler: php artisan schedule:work

Laravel’s documentation says queue:work keeps running until it is stopped manually or you close your terminal, and that schedule:work runs in the foreground and invokes the scheduler every minute until you terminate it. Nothing ties these processes to the web server except the person or tool that starts them. If the web server exits, the queue worker keeps running, unless the tool that started them is set up to stop the others.

The limitation that catches people

Laravel’s documentation describes queue workers as long-lived processes that keep the booted application in memory, so they do not notice code changes until they are restarted. On a server you run php artisan queue:restart, which tells workers to exit after their current job, and a process monitor such as Supervisor starts them again. On your own machine, the symptom of a stale worker is a job that still behaves like the old code. Stop the worker and start it again after you edit a job class.

In Rig

  • Rig detects Composer and Laravel Artisan sidecars: queue, horizon, schedule, and reverb.
  • The file must be named exactly Procfile and sit in the project root. Each process line becomes a selectable script, and extra scripts can run alongside the main one.

See Artisan sidecars and Procfile plus sidecars.

Related terms

Sources

  1. Azure Architecture Center: Sidecar patternOfficial documentation, checked 13 October 2026
  2. Kubernetes documentation: Sidecar containersOfficial documentation, checked 13 October 2026
  3. Laravel 13.x documentation: QueuesOfficial documentation, checked 13 October 2026
  4. Laravel 12.x documentation: Task schedulingOfficial documentation, checked 13 October 2026
  5. Laravel documentation: Artisan consoleOfficial documentation, checked 13 October 2026

Related reading

See how Rig fits in

Rig is a Mac app that starts, stops, and watches the processes in a project from one window. The knowledge base explains each part in plain language.

Read what Rig is

Related

https://userig.app/glossary/sidecar-process