Which Loki deployment mode fits your log volume and team
Choose the Loki mode by your daily log volume and your appetite for operating distributed components, and decide before volume grows, because moving modes later means a migration. A team that starts a log platform in a small environment often picks the simplest option and then finds that ingestion has outgrown it. The Loki deployment modes documentation gives monolithic mode, which runs every component in one process as a single binary or Docker image, as the fit for small read and write volumes of up to approximately 20 GB per day. Above that range, or when you need the resilience of more than one instance, the decision changes. Confirm your current and projected daily volume from your existing sources before you commit, and include the peak days, not only the average.
For most teams that need resilience without a large platform team, HA monolithic mode on shared object storage is the practical choice. The Loki docs describe it as two or more instances that coordinate through memberlist, write to a shared object store such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and use a replication_factor of 3. Your effort goes into the object store, retention through the compactor (which is disabled by default, so set retention_enabled deliberately) and an authenticating reverse proxy in front, since Loki has no built-in authentication. Ask your storage team whether an S3-compatible store you already run meets your durability needs, because the docs say MinIO and the local filesystem are not typically recommended for production.
Simple scalable mode is being deprecated and will be removed with Loki 4.0, so do not choose it for a new deployment. Loki's documentation says it can scale close to a TB of logs per day with separate read, write and backend targets, but it cannot run once you upgrade to 4.0, so you would face a second migration. If you already run it, plan a move to HA monolithic or microservices now, and confirm the timing against the Loki release notes. Microservices mode runs each component as its own process, is designed for Kubernetes, is deployed with a community-supported Helm chart, and the docs call it the most complex to set up and maintain. Reserve it for very large clusters or teams that need fine-grained scaling control and have Kubernetes operators to run it. Loki deployment modes documentation sets out the sizing guidance in full.
Monolithic, simple scalable and microservices side by side
This table compares the three Grafana Loki deployment modes on documented volume guidance, component layout, high availability, deployment target, effort and future support. Read each row against your expected daily log volume and your Kubernetes experience, because the mode that fits depends on both. Confirm the current status of simple scalable mode in the Loki release notes before you commit to it.
| Factor | Monolithic mode | Simple scalable mode | Microservices mode |
|---|---|---|---|
| Documented daily volume | Suited to small read and write volumes, up to approximately 20 GB of logs per day | Can scale close to 1 TB of logs per day, according to the Loki deployment modes docs | Intended for very large Loki clusters |
| Component layout | All components run in a single process as one binary or Docker image | Separate read, write and backend targets | Each component runs as a distinct process with its own target |
| High availability approach | Two or more instances with memberlist, a shared object store and replication_factor 3 | Documented as a scaled-out layout, but being deprecated, so confirm current HA guidance | Scaled per component, managed through the cluster's own orchestration |
| Deployment target | Single binary, Docker image or a small set of instances | Separate read and write groups, with backend targets | Designed for Kubernetes, deployed with a community-supported Helm chart |
| Setup and maintenance effort | Lowest of the three modes, with the fewest moving parts | Moderate, with more targets to size and monitor than monolithic mode | Most complex to set up and maintain, per the Loki docs |
| Future support status | Recommended in the docs as an alternative to simple scalable mode | Being deprecated and removed with Loki 4.0, so confirm the timeline in the Loki release notes | Recommended path for very large clusters or fine-grained scaling control |
Which mode fits which situation
Monolithic mode fits a team whose daily log volume stays within the roughly 20 GB per day that the Loki deployment modes documentation gives for this mode. All components run in a single process, started from one binary or one Docker image, so there are fewer moving parts to patch, monitor and explain to an auditor. The main design question is storage: the documentation points to object storage for production, and a single instance on local disk is a different risk profile.
- Single process: read, write and backend functions run together, which keeps the operating surface small.
- Object storage: chunks and the index belong in a production object store such as Amazon S3, Google Cloud Storage or Azure Blob Storage, not only on the local filesystem.
- Retention is off by default: the compactor keeps logs indefinitely until
retention_enabledis set, so set a retention policy on day one. - Authentication is external: Loki has no built-in login, so an authenticating reverse proxy must sit in front of it.
- Volume creep: if your daily volume approaches the monolithic ceiling, plan the move to HA monolithic or another mode before ingestion slows.
Before you choose this tab, confirm your sustained daily ingest in your own environment, not a peak week.
HA monolithic mode is the option for teams that need more than one Loki instance but do not want to run Kubernetes or a set of separate microservice targets. The Loki documentation describes it as two or more instances that share an object store, coordinate through memberlist, and use a replication_factor of 3. Each instance is still a full Loki process, so the change from a single node is mainly configuration and shared storage rather than a new architecture.
- Two or more instances: a failed instance does not stop ingestion when the others are healthy.
- Shared object store: all instances must read and write the same bucket, so storage availability becomes a dependency you must monitor.
- Memberlist coordination: instances find each other through the ring, so network reachability between them is part of the design.
- Replication factor: the documented value of 3 means that replica settings and instance count need to be planned together.
- Load balancing: an external load balancer or proxy in front of the instances is needed to spread writes and queries.
The Loki documentation recommends HA monolithic mode as a migration target for teams leaving simple scalable mode, so check the Loki deployment modes page for the current guidance before you start.
Microservices mode runs each Loki component as a distinct process with its own target, so ingesters, queriers and other components can be scaled separately. The Loki documentation calls it the most complex mode to set up and maintain and recommends it only for very large Loki clusters or operators who need fine-grained scaling control. It is designed for Kubernetes and is deployed with a community-supported Helm chart, which means chart maintenance and Kubernetes skills become part of the cost.
- Per-component scaling: you can add capacity to the component that is saturated instead of the whole cluster.
- Kubernetes dependency: the platform expects a cluster, and that cluster needs its own upgrades, storage classes and network policies.
- Community Helm chart: the chart is community-supported, so confirm its release cadence and values schema against your Loki version.
- Upgrade coordination: more components mean more version and configuration surfaces to test together.
- Staffing: someone on the team must own dashboards for each component, not only the log results.
Simple scalable mode is not a fallback here, since the Loki documentation says it is being deprecated and will be removed with Loki 4.0, which cannot run in that mode. If you are already on simple scalable mode, plan the migration now and confirm the target with the Loki release notes.
How HA monolithic Loki works on shared object storage
Monolithic mode runs every Loki component in a single process, started from one binary or one Docker image. The Loki deployment modes docs describe high availability for this mode as two or more instances that find each other through memberlist, write to a shared object store, and use a replication_factor of 3. The design keeps the moving parts small: there is no separate read, write or backend tier to size, but the team still owns the object store, the proxy in front of it and the retention policy. Those three pieces decide whether the HA setup holds up in production.
The object store is the first decision. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores in the Loki storage docs. S3-compatible systems such as MinIO and the local filesystem are supported, but the docs note they are not typically recommended for production. If you plan to run an S3-compatible store on your own hardware, confirm its durability, replication and failure behavior with the vendor and test a node loss before go-live. Loki also needs an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, because Loki has no built-in authentication layer. Set auth_enabled and the X-Scope-OrgID tenant header deliberately, since the proxy and Loki must agree on tenant identity.
Retention is disabled by default, so logs accumulate until you enable it. The compactor applies retention, and you can set it globally, per tenant or per stream selector, with each stream rule at least 24 hours. Before you size storage, check your own daily volume. The docs give about 20 GB per day as the monolithic sizing guidance, and that figure is a guide rather than a guarantee for your sources. Measure real ingest for a representative week, model object storage growth with your retention period, and confirm the result against the compactor and object store limits in your environment. If your volume approaches or exceeds that guidance, revisit the mode choice before you scale this one.
What each mode asks your infrastructure to run
Each Loki deployment mode asks for a different set of running parts, and those parts decide who gets paged and what must be backed up. The cards below cover the shared dependencies first, then the layout each mode adds, so you can count the components your team would own before choosing a mode.
Monolithic process layout
Monolithic mode runs every Loki component in one process, started from a single binary or Docker image. Your operating surface is one service to deploy, upgrade and monitor, plus its configuration file. Check whether that single process can keep up with your ingest and query peaks, since scaling it means running more copies behind a shared store rather than splitting roles apart.
Object storage as the system of record
Loki keeps compressed chunks and its index in object storage, so every mode depends on a bucket and its credentials. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores, while S3-compatible and filesystem options are supported but not typically recommended for production. Confirm your bucket lifecycle, versioning and access policy, because losing the bucket loses the logs.
Memberlist for ring coordination
Monolithic HA expects two or more instances that find each other through memberlist and share one object store with replication_factor 3. This adds a gossip-based membership layer you must keep reachable between instances, including on any firewall or network policy you apply. Test what happens when an instance leaves the ring, because replicas and ring health determine whether reads and writes keep working.
Simple scalable read, write and backend targets
Simple scalable mode splits Loki into read, write and backend targets, so you run two or more groups of processes with their own scaling and failure behavior. The mode is being deprecated and will be removed with Loki 4.0, which cannot run in that mode. Any new build on it means planning a migration to microservices or HA monolithic before the upgrade path closes.
Microservices components on Kubernetes
Microservices mode runs each Loki component as its own process with a distinct target, which the docs describe as the most complex to set up and maintain. The supported deployment path is a community-supported Helm chart on Kubernetes, so your team also owns the cluster, storage classes and chart upgrades. Confirm you have the Kubernetes skills to run per-component scaling before choosing this layout.
Authenticating reverse proxy in front
Loki has no built-in authentication layer, so every mode needs an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. That proxy handles identity, TLS and tenant headers, and it becomes a component you must patch and monitor. Decide early who owns it, and confirm how it maps your identity provider groups to the X-Scope-OrgID tenant header when auth_enabled is true.
Upgrades, retention, monitoring and skills for each mode
This table compares what each Loki deployment mode asks of your team after go-live: upgrade path, compactor retention, monitoring and the Kubernetes and object storage skills needed. Read each row against your own Loki version and environment, since the items marked for confirmation depend on details the vendor docs leave to you. The main takeaway is that simple scalable mode has a shrinking future, so new deployments should plan around monolithic HA or microservices.
| Area | Monolithic (HA optional) | Simple scalable | Microservices |
|---|---|---|---|
| Upgrade path | One binary or image to upgrade, with HA running two or more instances behind shared object storage | Deprecated; the docs say it will be removed with Loki 4.0 and recommend migrating to microservices or HA monolithic | Upgrade each component target on Kubernetes, typically through the community Helm chart; confirm chart and version compatibility before each step |
| Retention by the compactor | Disabled by default, so logs persist until retention_enabled is set; apply global, per-tenant or per-stream rules | Same compactor model, but the compactor runs alongside separate read, write and backend targets | Same compactor model; confirm which compactor instance runs and that only one is active |
| Per-stream retention rules | Each stream rule must be at least 24 hours; confirm rule syntax against your Loki version | Same 24-hour minimum; plan rules before migrating so they carry over | Same 24-hour minimum; rules are managed centrally, so review them during every change |
| Monitoring responsibilities | Watch the single process, ingestion rate, storage backlog and compactor runs | Watch each target separately, including read and write paths and backend health | Watch every component, the ring membership and inter-component traffic; alerts must cover each target |
| Kubernetes skills | Optional; needed only if you run it on Kubernetes | Needed to manage separate targets as workloads | Required for daily work: manifests or Helm values, scheduling, resource limits and rollouts |
| Object storage skills | Required: configure S3, GCS or Azure Blob credentials, lifecycle and access policies | Required for chunks and index, with the same credential and access work | Required, and shared across many components, so access and throughput reviews matter more |
| Items to confirm | Your Loki version, the store type (TSDB for 2.8 and newer), HA ring settings and whether auth_enabled is on | Your Loki version and migration plan, since the mode is being removed with Loki 4.0 | Your Helm chart version, component sizing, ring configuration and the team's on-call coverage for each target |
Moving off simple scalable before Loki 4.0
This sequence takes a team running Loki in simple scalable mode to a target that will still be supported after Loki 4.0 removes that mode, with logs ingesting and querying correctly before any shipper is repointed. Each step ends with a check that tells the team whether it can move on.
Confirm current version and migration target
Record the Loki version you run today, the deployment mode, the object store and the index store. Read the Loki deployment modes documentation to confirm the current guidance on the target, which the docs recommend as microservices or HA monolithic. Decide with the platform owner which target fits your daily volume and how many people will operate it. Done when the target and the version path are written down and approved by the owner of the logging service.
Choose HA monolithic or microservices
HA monolithic runs two or more instances with memberlist, a shared object store and replication_factor 3, and the docs describe the monolithic mode as suited to volumes up to about 20 GB per day. Microservices runs each component as its own process, is the most complex to set up and maintain, and the docs recommend it for very large clusters or teams that need fine-grained scaling. Ask your engineers which mode they can operate. Done when the choice is recorded with the daily volume it was based on.
Plan object storage and retention
Confirm that the object store is one the Loki storage docs recommend for production, such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and check how the index is stored under TSDB. Retention is disabled by default, so set retention_enabled and the retention rules deliberately so that existing data is not kept indefinitely by accident. Done when the bucket, access policy, retention settings and backup approach are documented and reviewed.
Stand up the target in a non-production environment
Deploy the chosen mode with the same configuration pattern you intend to use in production, including the authenticating reverse proxy in front of Loki, since Loki has no built-in authentication layer. If you use multi-tenancy, confirm that auth_enabled is set and that clients send the X-Scope-OrgID header. Done when the target starts cleanly, passes health checks and the reverse proxy enforces access.
Test ingestion and queries against real workloads
Replay representative log volume into the new target and run the queries your on-call and security teams depend on. Compare results with the simple scalable cluster for the same time windows, and watch ingestion errors, query latency and compactor activity. Ask the owners of each dashboard and alert to confirm their results match. Done when both clusters return consistent results for the agreed query set over the agreed test period and the team has signed off on performance.
Run both clusters in parallel
Send each shipper to both the old and new clusters so that the new target builds its own history while the old one remains a fallback. Keep the duplicate routing in place until the team is confident in ingestion and retention behavior. Done when the new cluster has ingested the full set of streams and the on-call team has used it for live incidents without gaps.
Cut over shippers and retire simple scalable
Repoint shippers, such as Grafana Alloy, Fluent Bit, Fluentd or the Docker logging driver, one group at a time, and confirm each group's labels and streams arrive as before. Keep the old cluster read-only until the retention window you agreed has been reviewed and any data you must retain has been moved or exported. Done when every shipper writes to the new target, the old cluster is decommissioned under change control and the migration record is filed.
Document operations and support ownership
Write runbooks for scaling, upgrades, backup of the object store, retention changes and incident response, and record who owns each component. Confirm the upgrade path against the Loki releases on GitHub and the deployment modes documentation before the next version change. Done when the runbooks are reviewed by the people who will run them and the support model is agreed in writing with any partner you use.
Questions teams ask before choosing a Loki mode
How much operating effort does each Loki deployment mode take?
Monolithic mode takes the least effort because all components run in a single process as one binary or Docker image. Simple scalable mode splits the work into separate read, write and backend targets, which adds moving parts to tune and monitor. Microservices mode is the most complex to set up and maintain, because each component runs as a distinct process with its own target. The Loki docs describe monolithic mode as suited to volumes of up to approximately 20 GB per day, simple scalable as approaching 1 TB per day, and microservices for very large clusters. Effort rises with the number of components you operate, so match the mode to your volume and to the skills you have in-house.
Can our team run highly available monolithic Loki without outside help?
A team with Linux, object storage and reverse proxy experience can usually run it, provided it understands the required pieces. The Loki docs describe high availability for monolithic mode as two or more instances that use memberlist for coordination, a shared object store and a replication_factor of 3. Your team must also place an authenticating reverse proxy in front of Loki, because Loki has no built-in authentication layer. Check that your staff can handle upgrades, backup of configuration, retention tuning with the compactor, and alerting on ingestion failures. If any of these are new to the team, scope a partner engagement to cover them, or ask for a written handover plan.
Why does microservices mode need Kubernetes skills and a Helm chart?
Loki's microservices mode is designed for Kubernetes, and the Loki docs point to a community-supported Helm chart for deploying it. Each component runs as its own process, so you need people who can manage pods, scheduling, storage classes, service discovery, resource limits and rolling upgrades. A community chart is a starting point, not a managed product, so your team owns the values files, version pinning and the review of each chart release. Ask whether your platform team already runs stateful workloads on Kubernetes. If not, the skills gap is usually a bigger cost than the Loki licence, which is zero.
What drives the total cost of running Loki in each mode?
Three cost components dominate. Object storage is paid to your cloud provider or storage vendor and grows with the volume you keep and the retention period you set. Compute is paid for the instances or cluster nodes that run the Loki components, and it scales with ingest volume and query load. Engineering time is the largest and most variable item, covering build, upgrades, monitoring and incident response. Retention is disabled by default in Loki, so logs are kept indefinitely until you set retention_enabled, which keeps storage growing. Ask your team to estimate each component against your own daily volume before comparing modes, because the Loki licence itself is not a cost driver.
What should we ask a partner to include in a fixed-scope Loki quote?
Ask for the scope in writing before work starts, including the chosen deployment mode, the expected daily log volume, and the reasons for that choice. Request a list of the components to be deployed, the object store and its configuration, the authentication approach in front of Loki, and the high availability design. Confirm which log shippers are in scope, such as Grafana Alloy, Fluent Bit or Promtail, and whether Promtail is part of the plan. Ask for the deliverables covering documentation, backup and restore testing, upgrade procedure, and handover training. Also confirm who maintains the system after go-live and whether ongoing support is a separate retainer. DeployOpen does not publish a price list, so the quote follows from this written scope.
How should we plan for a future move to Loki 4.0?
Simple scalable mode is being deprecated and will be removed with the Loki 4.0 release, and Loki 4.0 cannot run in that mode. The Loki docs recommend migrating to microservices or HA monolithic. If you run simple scalable today, plan the move before you upgrade to Loki 4.0 and treat it as a planned migration with its own testing window. Check the Loki releases page and deployment modes documentation for the current release timing, because no date for Loki 4.0 is set in the supplied facts. Choose HA monolithic if your volume fits its range, since it avoids the Kubernetes overhead of microservices, and document the switch so the change is reversible.
Does the AGPL license affect how we run Loki internally?
Grafana Loki is licensed under AGPLv3, and Grafana Labs announced the change from Apache License 2.0 to AGPLv3 on April 20, 2021. For most internal operations, running Loki for your own staff does not change your obligations, but legal review is the right step if you modify Loki and offer it to users over a network. Confirm the terms with your legal team against the Grafana Labs licensing page rather than relying on this summary. Licence choice does not change the effort of running a mode, but it can shape whether you consider a commercial edition later.
How DeployOpen scopes and runs a Loki deployment
DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and a Loki deployment is scoped the same way. The first decision in scoping is the deployment mode itself, because it determines which components exist, how the object store is wired and what the on-call team must be able to operate. Most engagements are fixed-scope, so the mode, the expected daily log volume, the object store, the authentication layer and the shipper set are written down before any work starts, and changing the mode later is treated as a new scope rather than a quiet adjustment.
A typical written scope for a Loki deployment would name the components to be installed, such as the Loki binary or image for monolithic mode with memberlist and a shared object store, the replication_factor value, the compactor and its retention settings, and the authenticating reverse proxy that Loki requires because it has no built-in authentication layer. It would also name the Grafana Alloy or other shippers, the tenant model set through auth_enabled and the X-Scope-OrgID header, and the backup and restore procedure for the object store. Ask for the same list in any proposal you receive, from DeployOpen or anyone else, so that the deliverables can be compared line by line.
Hardening, backup, upgrades and documentation are delivered as work items, and ongoing support, upgrades and continuous testing can be covered by a retainer after the initial build. Because Loki releases move quickly, with v3.7.8 listed on the GitHub releases page as published September 17, 2026, confirm with the vendor and your own change process which upgrade path your team will follow. DeployOpen does not issue audit reports or certifications for the resulting environment; if you need evidence for an assessment, agree in writing which controls and records the engagement will prepare for an independent assessor.
