Sidecar
A helper container deployed alongside the main application container in the same pod. Handles cross-cutting concerns like logging, monitoring, or TLS without modifying app code.
What is Sidecar?
In short
A sidecar is a helper process deployed right next to a main application, usually as a second container in the same Kubernetes pod, that handles supporting work like TLS encryption, traffic routing, logging, and metrics so the application code does not have to. The two share the same network and local storage, so the sidecar can intercept the app's traffic and read its files without any code changes to the app itself.
What a sidecar actually is
The name comes from the small passenger car bolted onto the side of a motorcycle. The motorcycle does the driving; the sidecar comes along and adds capacity. In software, the motorcycle is your application and the sidecar is a separate process that rides along to handle the boring but necessary jobs every service needs.
Concretely, on Kubernetes a sidecar is a second container in the same pod as your app container. Because containers in a pod share a network namespace and can share volumes, the sidecar reaches the app over localhost (127.0.0.1) and can mount the same directory the app writes logs to. The app keeps doing one thing; the sidecar does the cross-cutting thing.
The whole point is separation. Your team writes business logic. A platform team ships a sidecar image that does mTLS, retries, rate limiting, or log shipping. You get those features by adding a container to your pod spec, not by importing a library into every service in every language you run.
How it works under the hood
The most common job is networking. A proxy sidecar like Envoy uses an init container to rewrite the pod's iptables rules so that all inbound and outbound TCP traffic is redirected to the proxy first. The app thinks it is talking directly to another service, but every packet actually flows through the sidecar, which can add TLS, record latency, retry failed calls, or shed load. This is exactly how a service mesh data plane works.
Other sidecars are simpler. A logging sidecar tails a shared log file and forwards lines to Elasticsearch or Loki. A secrets sidecar fetches credentials from Vault and writes them to a shared in-memory volume the app reads. A config sidecar watches for changes and signals the app to reload. None of them require the app to know they exist.
Lifecycle matters. A plain extra container starts and stops in no guaranteed order, which breaks startup if the app needs the proxy ready first. Kubernetes 1.28 added native sidecar support: you mark the container as a restartable init container and it starts before app containers and shuts down after them, fixing the long-standing race conditions.
When to use it and the trade-offs
Reach for a sidecar when you need the same capability across many services written in different languages and you do not want to maintain a client library for each one. mTLS between every service, uniform request metrics, and centrally controlled traffic policy are textbook cases. It is also the cleanest way to add behavior to a third-party or legacy app you cannot recompile.
The cost is real. Every pod now runs an extra container, so you double your container count and pay for its CPU and memory. A mesh of Envoy sidecars across thousands of pods can add meaningful overhead and a few milliseconds of latency per hop. There is also operational weight: another image to patch, version, and roll out, plus the iptables magic makes debugging harder when something goes wrong.
The main alternatives are a shared library baked into the app (no extra process, but you must build and update it for every language) and, more recently, eBPF-based meshes like Cilium that move proxy work into the kernel to avoid the per-pod sidecar entirely. Pick a sidecar when uniformity across languages beats raw efficiency.
A concrete example
Take Istio, the most widely deployed service mesh. When you label a namespace for injection, Istio automatically adds an Envoy sidecar to every pod. Say your checkout service calls your payment service. The checkout app sends a plain HTTP request to the payment hostname. Its Envoy sidecar intercepts that request, opens a mutually authenticated TLS connection to the payment pod's Envoy, and that proxy hands the decrypted request to the payment app over localhost.
Neither application wrote a line of TLS code. The platform team set a policy saying all traffic must be encrypted, and Istio's control plane pushed that config to every sidecar. The same sidecars also export request counts and p99 latency to Prometheus, so you get a service dependency graph and golden metrics for free.
If the payment service starts failing, an operator can tell the sidecars to retry twice and trip a circuit breaker after five errors, again without touching application code or redeploying the apps. That decoupling of operational concerns from business logic is why the pattern spread across the industry.
Where it is used in production
Istio
Injects an Envoy sidecar into every pod to provide mTLS, traffic routing, retries, and metrics as a service mesh.
Linkerd
Runs a lightweight Rust micro-proxy sidecar per pod for transparent mTLS and latency-aware load balancing.
AWS App Mesh
Deploys an Envoy sidecar alongside ECS and EKS workloads to standardize service-to-service communication and observability.
HashiCorp Vault
Ships a Vault Agent sidecar that fetches and renews secrets, then writes them to a shared volume the app reads with no SDK.
Frequently asked questions
- What is the difference between a sidecar and a service mesh?
- A sidecar is the building block; a service mesh is the whole system. The mesh is the sidecar proxies on every pod (the data plane) plus a central control plane that configures them. You can run a single sidecar without a mesh, but a mesh is just many sidecars managed together.
- Does a sidecar run in its own pod?
- No. On Kubernetes a sidecar runs as an additional container inside the same pod as the application. That co-location is what lets it share localhost networking and mounted volumes with the app, which is the entire reason the pattern works.
- What is the downside of the sidecar pattern?
- You double the number of running containers, which costs extra CPU and memory and adds a few milliseconds of latency when a proxy sits in the request path. You also take on more operational work patching and upgrading the sidecar image across every pod.
- What are common examples of sidecar use cases?
- The big ones are a network proxy (Envoy for mTLS, retries, and routing), a logging agent that ships a shared log file to a backend, a secrets agent that pulls credentials from Vault, and a metrics or config-reload helper. Anything cross-cutting that every service needs is a candidate.
- How is a sidecar different from an init container?
- An init container runs to completion before the app starts and then exits, used for setup like running migrations. A sidecar runs for the entire life of the app alongside it. Kubernetes 1.28 blurred the line by letting you define a sidecar as a restartable init container so it starts first but keeps running.
Learn Sidecar hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Sidecar as part of a larger topic.
Sidecar Container Pattern
Attach a helper container to your application, handling logging, monitoring, proxying, or configuration without modifying the app
intermediate · microservices architecture
Ambassador Container Pattern
A specialized sidecar that handles outbound connectivity, connection pooling, retries, and protocol translation for external services
intermediate · microservices architecture
See also
Related glossary terms you might want to look up next.
Service Mesh
A dedicated infrastructure layer for handling service-to-service communication in microservices. Manages load balancing, encryption, and observability automatically.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.