github.com/yankunsam/loki/v2@v2.6.3-0.20220817130409-389df5235c27/docs/sources/fundamentals/architecture/deployment-modes.md (about) 1 --- 2 title: Deployment modes 3 weight: 20 4 --- 5 # Deployment modes 6 7 As an application, 8 Loki is built out of many component microservices, 9 and is designed to run as a horizontally-scalable distributed system. 10 Loki's unique design compiles the code of the entire distributed system into 11 a single binary or Docker image. 12 The behavior of that single binary is controlled with 13 the `-target` command-line flag and defines one of three modes of operation. 14 15 Configuration for each deployed instance of the binary 16 further specifies which components it runs. 17 18 Loki is designed to easily redeploy a cluster under a different mode 19 as your needs change, 20 with no configuration changes or minimal configuration changes. 21 22 ## Monolithic mode 23 24 The simplest mode of operation sets `-target=all`. 25 This is the default target, 26 and it does not need to be specified. 27 This is monolithic mode; 28 it runs all of Loki’s microservice components inside a single process 29 as a single binary or Docker image. 30 31  32 33 Monolithic mode is useful for getting started quickly to experiment with Loki, 34 as well as for small read/write volumes of up to approximately 100GB per day. 35 36 Horizontally scale up a monolithic mode deployment to more instances 37 by using a shared object store, and by configuring the 38 [`memberlist_config` section](../../../configuration/#memberlist_config) 39 to share state between all instances. 40 41 High availability can be configured by running two Loki instances 42 using `memberlist_config` configuration and a shared object store. 43 44 Route traffic to all the Loki instances in a round robin fashion. 45 46 Query parallelization is limited to the quantity of instances 47 and the query parallelism defined. 48 49 ## Simple scalable deployment mode 50 51 If your volume of logs exceeds a few hundred GB a day, 52 or if you would like to separate read and write concerns, 53 Loki provides the simple scalable deployment mode. 54 This deployment mode can scale to several TBs of logs per day and more. 55 Consider the microservices mode approach for very large Loki installations. 56 57  58 59 In this mode the component microservices of Loki are bundled into two targets: 60 `-target=read` and `-target=write`. 61 The BoltDB [compactor](../../../operations/storage/boltdb-shipper/#compactor) 62 service will run as part of the read target. 63 64 There are advantages to separating the read and write paths: 65 66 * higher availability of write path by providing dedicated nodes 67 * separately scalable read path to add/remove query performance on demand 68 69 The simple scalable deployment mode requires a load balancer in front of Loki, 70 which directs `/loki/api/v1/push` traffic to the write nodes. 71 All other requests go to the read nodes. 72 Traffic should be sent in a round robin fashion. 73 74 The simple scalable deployment of Loki can scale to 75 several TBs of logs per day and more. 76 77 ## Microservices mode 78 79 The microservices deployment mode instantiates components of Loki 80 as distinct processes. 81 Each process is invoked specifying its `target`: 82 83 * ingester 84 * distributor 85 * query-frontend 86 * query-scheduler 87 * querier 88 * index-gateway 89 * ruler 90 * compactor 91 92  93 94 Running components as individual microservices allows scaling up 95 by increasing the quantity of microservices. 96 The customized cluster has better observability of the individual components. 97 Microservices mode deployments are the most efficient Loki installations. 98 However, they are also the most complex to set up and maintain. 99 100 Microservices mode is recommended for very large Loki clusters 101 or for clusters that require more control over scaling and cluster operations. 102 103 Microservices mode works best with Kubernetes deployments. 104 There are Jsonnet and distributed Helm chart installations.