# Cerbos deployment patterns

|     |     |
| --- | --- |
|  | This documentation is for<br>a previous<br>version of Cerbos. Choose 0.53.0 from the version picker at the top right or navigate to [https://docs.cerbos.dev](https://docs.cerbos.dev/) for the latest version. |

Cerbos can be deployed as a service or as a sidecar. Which mode to choose depends on your requirements.

## Service model

- Central policy decision point shared by a group of applications.

- Cerbos can be upgraded independently from the applications — reducing maintenance overhead.

- In a busy environment, careful capacity planning would be required to ensure that the central Cerbos endpoint does not become a bottleneck.

## Sidecar model

- Each application instance gets its own Cerbos instance — ensuring high performance and availability.

- Upgrades to Cerbos would require a rolling update to all the application instances.

- Policy updates could take slightly longer to propagate to all the individual application instances — resulting in a period where both the old and new policies are in effect at the same time.

## DaemonSet model

- Each cluster node gets its own Cerbos instance — ensuring high performance and efficient resource usage.

- Policy updates must roll out to nodes individually — resulting in a period where both the old and new policies are in effect at the same time.

- When deployed as a daemonset the service `internalTrafficPolicy` defaults to `Local`. This causes all requests to the service to be forced to the local node for minimum latency. Upgrades to Cerbos could result in application seeing a short outage to the cerbos instance on their own node, client retries may be necessary. If this is unacceptable you can set `service.internalTrafficPolicy` to `Cluster`. You may be able to improve availability via the `service.kubernetes.io/topology-mode: Auto` annotation.