---
title: Read, Write, Worker Roles
description: Roles provide an easy way to scale out your Livingdocs Server instances when accessing only one Postgres instance.

---
Roles provide an easy way to scale out your Livingdocs Server instances when accessing only one Postgres instance.
This configuration allows developers to deploy new Server instances with read only permission.

At the moment, there are 3 valid roles available: `write`, `worker` and an implicit read-only role.

- `write` enables the mutating api endpoints when set.
- `worker` sets the enableConsumers of internal Server features.
- read-only: If roles config is set empty `roles: []` then this is a ready-only instance (usually for deliveries)

We recommend one of the following configurations:

- one instance with `roles: ['write', 'worker']` (default)
- for reliability sensitive setups deploy two instances, one with `roles: 'write'` and another instance with `roles: 'worker'`
- one instance with `roles: ['write', 'worker']` and multiple instances with `roles: []` to scale out deliveries

All possible combinations per use case, can be seen below:

![Possible `roles` configuration per use case](/customising/server/images/roles-configurations.png)


## Roles: 'write'

This role should be used in all instances that require the ability to mutate the database.
If a Server instance without `write` role receives a request to a mutating public-api endpoint,
the Server will respond with a Error `405` stating the instance is `read-only`.

## Roles: 'worker'

This role should be used to deploy replica instances to increase reliability over single-instance deployments, i.e. a worker intance that handles ElasticSearch indexing without affecting main instance.

When a Server instance with `worker` role is deployed, internal API features will be enabled by default (i.e. documents, import, indexing, notifications, document-migrations).

## Roles: read-only

This role should be used when having a delivery/frontend doing read-only requests via the public API.