What a Loki implementation involves
A Loki implementation in your own infrastructure is a set of connected decisions, not a single install. The core choices are sizing from daily log volume, the deployment mode, the object store that holds compressed chunks and the index, the index store itself, retention, the shippers that collect logs, how tenants are separated, and the authenticating proxy that must sit in front of Loki. Each one changes the others, so the plan should settle them together before any cluster is built.
Start with volume and deployment mode. Loki documents monolithic mode for up to about 20 GB of logs per day, simple scalable mode for larger volumes, and microservices for very large clusters. Simple scalable mode is being deprecated and removed with Loki 4.0, so a new build should confirm whether it targets microservices or a mode that will remain supported. On the storage side, use an object store recommended for production, such as Amazon S3, Google Cloud Storage or Azure Blob Storage, or confirm that your S3-compatible or on-premises store meets your durability and operations requirements. Use TSDB as the index store on Loki 2.8 and newer, since older stores are deprecated.
Retention and tenancy need explicit decisions before go-live. Retention is disabled by default, so logs are kept indefinitely until retention is enabled in the compactor. Decide whether retention is global, per tenant or per stream selector, and record the period each data class requires. Tenancy depends on auth_enabled and the X-Scope-OrgID header, so map teams or business units to tenants early. Shippers also matter: Grafana Alloy is the supported collector, Promtail reached end of life on March 2, 2026, and Fluent Bit, Fluentd and OpenTelemetry logs are also accepted.
Loki has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must be deployed and maintained in front of every endpoint. Plan it as a component with its own owner, certificates and upgrade cycle. Triggers for starting this work usually fall into three groups: replacing a hosted logging tool, centralizing logs to meet a compliance program's collection needs, or building a new platform. Teams with a platform group, Kubernetes skills and clear ownership of storage and access often build in-house. Teams without those skills, or with a deadline, often bring in a partner for the design and first deployment. DeployOpen prepares systems and evidence for compliance assessments, but auditors and certification bodies issue any audit outcome.
What the work includes
A Loki implementation is a set of connected work packages, from sizing the platform to handing over runbooks. The cards below show what each package covers and what to confirm before you agree on scope.
Sizing and architecture
This package sets the daily log volume, peak ingest rate, query patterns and retention targets that everything else depends on. It also selects the deployment mode, since Loki documents monolithic mode for up to about 20 GB per day and simple scalable mode for larger volumes. Ask the partner to show the sizing inputs and the assumptions behind them.
Deployment in your environment
Loki is installed into your cloud accounts, data centers or air-gapped network, using the deployment mode chosen during sizing. The work covers compute, networking, load balancing and high availability for the chosen mode. Confirm who owns the cluster, the Helm or container artifacts and the change process after handover.
Object storage and index configuration
Loki keeps compressed chunks and its index in object storage, and TSDB is the recommended index store for Loki 2.8 and newer. This package configures the bucket, access policy, index schema and encryption settings. Confirm which object store you will use, since the Loki docs list Amazon S3, Google Cloud Storage and Azure Blob Storage as recommended production options.
Retention per tenant or stream
Loki does not delete logs until the compactor's retention is enabled, so this package sets global, per-tenant or per-stream retention deliberately. Each stream rule must be at least 24 hours. Agree the retention periods with legal and security owners before the build, because they drive storage cost and deletion obligations.
Log shipper rollout
Grafana Alloy is the supported shipper for Loki, and Promtail reached end of life on March 2, 2026. This package deploys Alloy to hosts, containers or Kubernetes nodes, and labels streams consistently. Inventory any existing Fluent Bit, Fluentd or Docker logging driver pipelines, since they may remain in use.
Authenticating proxy
Loki has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front of it. This package maps identities to the X-Scope-OrgID tenant header and enforces access on every endpoint. Confirm which identity provider the proxy will use and who approves tenant mappings.
Grafana data source setup
This package connects Grafana to Loki through the authenticating proxy and configures the tenant header for each data source. It also checks that dashboards and alert rules query the right tenants. Confirm whether your users need separate Grafana access controls, since Loki alone does not provide label-based access control.
Backups and runbooks
Backups cover the object storage configuration, Loki configuration files, deployment definitions and any tenant or retention settings that are not stored in the bucket. Runbooks describe restore steps, scaling, compactor operation and common ingest failures. Ask for a restore test, not only a backup schedule.
Handover deliverables
At handover you should receive configuration as code, runbooks and a test report that records ingest, query, retention and access checks. Ask for the repository structure, a list of the tenants and retention rules in force, and named owners for each runbook. Confirm the format and location of every deliverable in the written scope.
What drives cost and duration
Each row names a driver of implementation effort or ongoing cost, explains why it moves that effort, and gives a way to keep it down.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Daily log volume | Sets the deployment mode and sizing. Higher volume raises ingest, query and storage load and extends load testing. | Measure volume per source over a representative period and drop noisy debug logs at the shipper. |
| Deployment mode | Monolithic mode covers up to about 20 GB per day. Simple scalable mode is deprecated and removed in Loki 4.0. | Size for current volume and growth, and avoid building new simple scalable clusters on the Loki 4.0 timeline. |
| Object storage choice | Chunks and index live in object storage, so the store sets durability, access controls and operating work. | Use a recommended production store already in your estate. Confirm the support position before using MinIO or a filesystem. |
| Retention periods and tenant rules | Retention is off by default, so logs persist until enabled. Per-tenant and per-stream rules add configuration and review work. | Set retention from a written data classification, and keep rules few. Each rule must cover at least 24 hours. |
| Number and type of log sources | Each source needs parsing, labels and tests. Poorly chosen labels raise query cost and troubleshooting time. | Standardize on Grafana Alloy, since Promtail reached end of life on March 2, 2026, and agree a fixed label set. |
| Number of tenants and access model | Tenants are set by the X-Scope-OrgID header, and Loki needs an authenticating proxy in front of it. | Start with few tenants mapped to clear teams, and document which proxy group grants which tenant. |
| Grafana access and SSO | Grafana permissions and proxy identity must agree on who sees which tenant, which adds integration and testing. | Map identity groups to tenants once, then test that a user cannot query another tenant's logs. |
| Environments and change control | Separate development, test and production stacks, plus approvals for configuration and version changes, add build and review time. | Keep configuration under version control and promote the same artifacts through each environment. |
Project phases and outputs
The sequence moves from agreed requirements to a sized design, a tested non-production build, a controlled pilot, production cutover and a handover the operations team can run without the builders.
Run discovery and agree scope
We interview the platform, security and application owners about log sources, teams that query logs, compliance drivers and existing tooling, then document the scope in writing. The phase closes when the written scope and a phase timeline are signed off, and you can confirm the list of log sources and who owns each one.
Size volume, retention and access
We agree daily log volume per source, peak rates, retention periods by stream or tenant, and the query patterns people will run. The output is a sizing note that sets the deployment mode and object storage capacity. Confirm these volume and retention assumptions with your team before design starts, because they drive most of the cost.
Design the target architecture
We select the deployment mode, object storage backend, index store, shipper choices, tenant model and the authenticating reverse proxy in front of Loki, then record each decision with its reason. The output is an architecture document and a set of configuration choices your reviewers can check against the sizing note.
Build and test in non-production
We deploy Loki, the shippers and Grafana access in a non-production environment inside your infrastructure, then test ingestion rates, query performance, retention deletion and tenant separation. The phase closes with a test report that records results against the sizing note and any open defects.
Pilot shipping with selected sources
We connect a limited set of log sources and a small group of users, then watch ingestion, label quality and query behavior over a period you agree in the scope. The pilot is complete when the agreed success checks are met and the issues list is closed or accepted by your team.
Cut over to production
We move the agreed sources to the production cluster, enable retention and access controls, and confirm that dashboards and alerts work for each team. The output is a cutover record listing sources moved, rollback steps tested and the date each source went live.
Hand over runbooks and train operators
We deliver runbooks for upgrades, backups, retention changes, tenant onboarding and incident response, and train the people who will run the stack. The phase closes when your operators complete a supervised exercise from the runbooks and the handover checklist is signed by both teams.
Which parts stay in-house and which go to a partner
This table maps each part of a self-hosted Loki stack to the team that usually carries it and the skills that work needs, so you can see which roles to staff internally and which to scope with a partner.
| Work area | Usually carried by | Skills it needs |
|---|---|---|
| Storage and network decisions | Platform owners | Kubernetes or Linux operations, object storage administration, bucket policy and encryption, network paths between shippers, Loki and Grafana |
| Deployment mode and sizing | Platform owners with partner input | Comparing monolithic, simple scalable and microservices modes, capacity planning, confirming the target mode given simple scalable's planned removal in Loki 4.0 |
| Label design and retention policy | Log owners | Knowing which applications emit which logs, label cardinality, LogQL, data classification, retention rules per tenant or stream selector |
| Access design and tenant mapping | Security, with log owners | Configuring an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium, identity provider integration, X-Scope-OrgID mapping to teams |
| Log shipper configuration | Platform owners with application teams | Grafana Alloy, Fluent Bit, Fluentd or the Docker logging driver, container log paths, migrating any Promtail agents before end of life |
| Grafana data sources and dashboards | Log owners | Grafana administration, LogQL query writing, dashboard and alert rule design, Grafana SSO for query users |
| Build, configuration and handover | Partner | Deployment automation, Loki and proxy configuration, runbooks and documentation, knowledge transfer to named staff, scope agreed in writing before work starts |
| Day-to-day operations and upgrades | Platform owners | Monitoring Loki components, patch and version upgrade testing, query and retention checks after changes, on-call response |
What usually goes wrong
Most Loki problems trace back to decisions made during design, before any log is shipped. Each risk below has a prevention step to complete in the design or the handover.
Volume sized below actual load
Teams often size Loki from a rough guess and choose a deployment mode that cannot carry the actual daily volume. Monolithic mode is documented for about 20 GB of logs per day, and simple scalable mode is being removed with Loki 4.0. Prevention: measure ingest from every source over several weeks and choose the mode in the design, with a planned path to microservices if volume grows.
Unbounded label cardinality
Labels that carry values such as user IDs, request IDs or pod-level identifiers create a very large number of streams, which slows queries and inflates the index. Loki's guidance is to keep labels to a small, bounded set and place high-variety values in the log content. Prevention: define an approved label list in the design, enforce it in shipper configuration, and review stream counts after the first load.
Retention left disabled
Loki's compactor applies retention, and retention is disabled by default, so chunks are kept indefinitely and object storage grows without limit. Retention can be set globally, per tenant or per stream selector, and each rule must cover at least 24 hours. Prevention: write the retention table from the data owner's requirements, set retention_enabled explicitly, and verify deletion on a test tenant before go-live.
Endpoint exposed without authentication
Loki has no built-in authentication layer, so an endpoint reachable on the network accepts requests from anyone who can reach it. Loki's documentation calls for an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Prevention: make the proxy part of the reference architecture, restrict direct access to Loki ports, and confirm that unauthenticated requests fail before any shipper points at the cluster.
Shippers still on Promtail
Promtail reached end of life on March 2, 2026, and receives no further updates or commercial support. Hosts deployed earlier often keep it because it still forwards logs, which leaves collection unpatched. Prevention: inventory every host and container running Promtail, plan the move to Grafana Alloy, and keep label mapping identical during cutover so existing dashboards and alerts still match.
Object storage sized and backed up poorly
Loki keeps compressed chunks and its index in object storage, so capacity, durability and recovery depend on the storage platform. Grafana's recommended production stores are Amazon S3, Google Cloud Storage and Azure Blob Storage, while MinIO and local filesystems are supported but not typically recommended for production. Prevention: size capacity from the retention table, confirm durability and backup options with the storage owner, and rehearse a restore.
How the work changes by starting point
Your current tool already reports daily ingest and retention, so sizing starts from measured numbers. The larger effort is moving shippers and rebuilding dashboards and alerts, not storage.
- Sizing: Use the current daily ingest to choose a deployment mode, and confirm it against the documented monolithic limit of about 20 GB per day.
- Storage: Plan the object store bucket and its retention before cutover. Loki indexes labels rather than full text, so query cost and retention behave differently from Elasticsearch.
- Access: Existing Kibana users will need Grafana access and tenant mapping, with an authenticating proxy in front of Loki from the start.
- Effort: Plan a dual-running period and rewrite dashboards and alerts. Promtail is end of life, so build new pipelines on Grafana Alloy.
The Loki migration page covers the cutover sequence in detail.
With a new cluster, you choose the deployment mode, object store and tenancy before any data exists. The decisions made now are the ones that are costly to change later.
- Sizing: Choose the mode from projected daily volume. Simple scalable mode is being deprecated and will be removed with Loki 4.0, so confirm the supported path for growth in Grafana's current documentation.
- Storage: Use a production object store such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and set TSDB as the index store.
- Access: Set auth_enabled and tenant headers on day one. Loki has no built-in authentication, so the proxy layer must be part of the initial Helm values.
- Effort: Network policies, the proxy and shipper configuration add work up front. With no legacy data to move, the build is usually shorter than a migration.
The Loki security hardening page covers the controls that apply to this build.
Grafana is already your query surface, so the work centers on adding Loki as a data source and deciding who sees which logs. Grafana itself adds little to sizing.
- Sizing: Sizing follows log volume and query load, not dashboard count. Heavy dashboards that scan wide time ranges are the main query cost to review.
- Storage: If the organization already runs object storage, give Loki its own bucket and credentials instead of sharing an existing one.
- Access: Grafana SSO covers the people who query logs, but Loki still needs an authenticating reverse proxy. Map Grafana teams to X-Scope-OrgID values through that proxy.
- Effort: Most work is data source setup, folder and permission design, and reviewing dashboards that assume label names from another backend. Confirm the Grafana version works with the Loki version you deploy.
The Loki SSO and identity integration page covers the proxy and mapping design.
When object storage is internal, the storage choice and the software supply chain shape the plan more than log volume does. Each component must be moved into the restricted zone deliberately.
- Storage: Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores. S3-compatible internal stores are supported, but the documentation notes they are not typically recommended for production, so confirm durability and support with the vendor first.
- Sizing: Object store throughput and network paths become the limit. Confirm them with the storage team before setting ingest targets.
- Access: The compactor needs credentials with delete permission for retention. Scope those credentials tightly and document who holds them.
- Effort: Mirror container images, Helm charts and Alloy packages into an internal registry, and plan each upgrade as an approved offline transfer. Approval steps add elapsed time that a connected build does not have.
The Loki security hardening page covers encryption, permissions and TLS for this setting.
Tenancy is set by the X-Scope-OrgID header, so the design question is how teams map to tenants and who may query across them. Each team adds volume, retention and access decisions.
- Sizing: Measure volume per team. A cluster sized for the largest team may not suit the others, and per-team numbers drive recurring object storage cost.
- Storage: Retention can be global, per tenant or per stream selector, with each rule at least 24 hours. Retention is disabled by default, so agree retention with each team before go-live.
- Access: The proxy must derive the tenant from the user's identity and set the header itself, so one team cannot choose another team's tenant. Cross-tenant queries and label-based access control are Grafana Enterprise Logs features, so confirm what the open-source build provides for your model.
- Effort: Onboarding each team, configuring its shippers and agreeing retention recur for as long as the teams use the platform. Write a runbook for onboarding and offboarding.
The Loki cost of ownership page covers how team count affects recurring cost.
What you need to provide
Start with a daily log volume estimate for each source, in gigabytes per day, along with the systems that produce it: Kubernetes nodes, application workloads, network devices, Windows hosts and any Fluent Bit, Fluentd or Docker logging driver pipelines already running. Volume chooses the deployment mode. Loki's documentation places monolithic mode at up to about 20 GB per day and simple scalable mode approaching 1 TB per day, but simple scalable is being deprecated and removed with Loki 4.0, so the design may need microservices or a later mode. Ask for peak rates, not only averages.
Name the target cloud account, data center or air-gapped network, and the network rules that apply. Specify which subnets may reach ingest and query endpoints, whether shippers cross a trust boundary, and what outbound traffic is allowed. Then choose the object store. Loki's documented production options are Amazon S3, Google Cloud Storage and Azure Blob Storage. S3-compatible stores and local filesystems are supported but not typically recommended for production, so an on-premises choice needs a deliberate, documented decision. State your encryption requirements, including whether keys must be customer-managed and who may read or delete bucket contents.
Retention obligations drive compactor configuration, and this is where teams most often slip. Retention is disabled by default, so logs persist until you turn it on. Provide a written requirement for each log class with its minimum and maximum period, and say whether deletions must be auditable. Retention rules apply per tenant or per stream selector, and each rule runs for at least 24 hours. Also name the identity provider that will sign users in to the authenticating reverse proxy and to Grafana. Loki has no built-in authentication layer, and tenants are selected by the X-Scope-OrgID header, so this choice shapes the proxy design.
Name an owner for each log source, each tenant and each retention rule. Owners approve tenant boundaries, answer access requests and sign off on retention changes, so decisions do not stall during build. Finally, provide a non-production environment that is close enough to production to test ingest rates, shipper changes, Loki upgrades and retention deletion before they reach live logs. Confirm your shipper choice early: Promtail reached end of life on March 2, 2026, and Grafana directs users to Grafana Alloy.
Frequently asked questions
What drives the cost of a self-hosted Loki implementation?
Daily log volume, the deployment mode it leads to, object storage, retention, log shippers and Grafana access set most of the cost. Volume comes first: Loki's documentation places monolithic mode at up to about 20 GB of logs per day and simple scalable mode approaching 1 TB per day, so higher volume means more components to build and operate. Retention is a recurring storage cost, because Loki keeps logs indefinitely until retention is enabled. Ask the quote to price each component separately and to state the volume and retention assumptions behind it.
How long does a Loki implementation take, and what sets the timeline?
The timeline depends on the scope that is agreed in writing before work starts, so no fixed duration applies to every stack. The main variables are the deployment mode, the object store and its permissions, the number of log sources to onboard, the authentication design in front of Loki, and how many teams need their own tenants. Most engagements are fixed-scope, so ask for phases, dependencies and the approvals your own staff must give, since internal reviews often set the pace.
Can our internal team deploy and run Loki without a partner?
Yes, many teams can, provided they have the skills and hours for every part of the stack. Loki is licensed under AGPLv3, so the software carries no license fee, but the work around it is staff time: object storage setup, the authenticating proxy, shipper configuration, retention policy, upgrades and on-call support. Teams with limited experience in Kubernetes, object storage or Grafana operations often find the first build and the first upgrade the hardest parts. A partner can take defined phases under a fixed scope and hand over documentation while your staff keep ownership.
What does the work require from our staff during the engagement?
Expect named owners for infrastructure, identity, security review and the teams that send logs. Infrastructure staff provide the cluster or servers, storage buckets, network paths, DNS and TLS certificates. Identity staff define how users reach Loki and how teams map to tenants, since Loki uses the X-Scope-OrgID header to identify tenants. Application teams confirm which logs to collect and how long to keep them. Security staff review access, encryption and retention for sensitive logs. Agree on these people and their time in writing before the build starts.
Which items should we request in a Loki implementation quote?
Ask for a quote built from a written scope, with each line tied to a phase and a deliverable. Request the deployment mode and the volume it assumes, the object storage design and who provisions it, the authenticating proxy and identity integration, the shipper migration (including Promtail to Grafana Alloy if you run Promtail), the retention settings per tenant or stream, and the Grafana access model. Also ask for handover documentation, a query and retention test plan, and any post-launch support kept separate from the build. DeployOpen does not publish a price list, so the quote follows from the written scope.
Why does Loki need an authenticating proxy in front of it?
Loki has no built-in authentication layer, so anything that can reach its endpoints can read or write logs. Loki's documentation says to run an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. The proxy checks the caller before the request reaches Loki. With auth_enabled set to true, Loki identifies tenants from the X-Scope-OrgID header, so the proxy must set or verify that header and must block users from requesting tenants they are not allowed to read. Design this before any shipper or Grafana connects.
How DeployOpen scopes and delivers Loki
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Loki, that means sizing the stack from your actual daily log volume, retention needs and access model before any build starts.
How we scope
- Measure daily log volume, peak ingest and the number of log sources before choosing a deployment mode.
- Agree the object storage target, retention periods per tenant or stream, and the Grafana access model in writing.
- Confirm which log shippers, such as Grafana Alloy or Fluent Bit, each team will use, with the scope and deliverables fixed before work starts.
How we build
- Deploy Loki in the chosen mode with TSDB as the index store, using the object storage your organization controls.
- Configure the compactor, retention rules and tenant headers, then test that queries and retention behave as the written scope says.
- Place an authenticating reverse proxy in front of Loki, because Loki has no built-in authentication, and validate access before go-live.
How we hand over
- Deliver architecture notes, configuration as code, sizing assumptions and a runbook covering ingestion, retention and recovery.
- Document shipper configuration, tenant mapping and the Grafana data source setup for your operations team.
- Walk your platform and security staff through the stack and the acceptance tests agreed in the scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the stack you run.
- Plan Loki version upgrades, including Promtail to Grafana Alloy and simple scalable mode changes, as part of a written upgrade path.
- Confirm with your team which support responsibilities sit with DeployOpen and which stay internal before the retainer starts.
