| MF_THINGS_ES_URL | Event store URL | localhost:6379 |
| MF_THINGS_ES_PASS | Event store password | |
| MF_THINGS_ES_DB | Event store instance name | 0 |
| MF_THINGS_HTTP_PORT | Things service HTTP port | 8182 |
| MF_THINGS_AUTH_HTTP_PORT | Things service Auth HTTP port | 8989 |
| MF_THINGS_AUTH_GRPC_PORT | Things service Auth gRPC port | 8181 |
| MF_THINGS_SERVER_CERT | Path to server certificate in pem format | |
| MF_THINGS_SERVER_KEY | Path to server key in pem format | |
| MF_THINGS_STANDALONE_EMAIL | User email for standalone mode (no gRPC communication with users) | |
| MF_THINGS_STANDALONE_TOKEN | User token for standalone mode that should be passed in auth header | |
| MF_JAEGER_URL | Jaeger server URL | localhost:6831 |
| MF_AUTH_GRPC_URL | Auth service gRPC URL | localhost:8181 |
| MF_AUTH_GRPC_TIMEOUT | Auth service gRPC request timeout in seconds | 1s |
**Note** that if you want `things` service to have only one user locally, you should use `MF_THINGS_STANDALONE` env vars. By specifying these, you don't need `auth` service in your deployment for users' authorization.
The service itself is distributed as Docker container. Check the [`things `](https://github.com/mainflux/mainflux/blob/master/docker/docker-compose.yml#L167-L194) service section in
Setting `MF_THINGS_CA_CERTS` expects a file in PEM format of trusted CAs. This will enable TLS against the Users gRPC endpoint trusting only those CAs that are provided.
In constrained environments, sometimes it makes sense to run Things service as a standalone to reduce network traffic and simplify deployment. This means that Things service
operates only using a single user and is able to authorize it without gRPC communication with Auth service.
To run service in a standalone mode, set `MF_THINGS_STANDALONE_EMAIL` and `MF_THINGS_STANDALONE_TOKEN`.