What does auth_enabled actually do?

It toggles Loki's multi-tenancy header requirement: when true, every request must include an X-Scope-OrgID header identifying the tenant, and Loki isolates data per tenant. Single-tenant setups almost always run with auth_enabled: false and rely on a reverse proxy for access control instead.

Which storage backend should I pick?

Filesystem is the simplest option, storing chunks and the index on local disk, and is fine for a single-node or low-volume setup. S3 and GCS are the common choices for production, since they scale storage independently of the Loki process and survive node loss.

What do ingestion_rate_mb and retention_period control?

ingestion_rate_mb caps the sustained log volume (in MB/s) Loki accepts per tenant before rate-limiting kicks in, protecting the cluster from a runaway log source; retention_period sets how long log data (and its index) is kept before Loki's compactor deletes it.

Is this a complete production-ready Loki config?

No, it covers the fields most setups need to get a working single-binary Loki running: auth mode, storage backend, and core limits. Production deployments typically also configure schema_config, a compactor, and ring/memberlist settings for scale-out mode, which this tool doesn't attempt to model.

Loki Config Generator - Build a Loki Config YAML

Overview

Introduction

A Loki config file's storage_config section looks completely different depending on whether you're writing chunks to local disk, S3, or GCS, and getting the nested key names right from memory is easy to fumble.

This tool builds that config from a form: toggle auth on or off, pick a storage backend and fill in its fields, and set your ingestion and retention limits, all rendered as correctly nested YAML.

What Is Loki Config Generator?

A visual builder for a Loki configuration YAML, covering auth_enabled, a storage_config block for one of three backends (filesystem, S3 via the aws key, or GCS), and a limits_config block.

It mirrors Loki's own config structure so the output can be used as a starting config.yaml passed to the loki binary with -config.file.

How Loki Config Generator Works

auth_enabled is emitted as a top-level boolean exactly as typed. The storage_config block is built based on your selected backend: filesystem emits a directory path, S3 emits an aws block with bucketnames/region and optional access keys, and GCS emits a gcs block with a bucket_name.

limits_config is always emitted with your ingestion_rate_mb (validated as a positive number) and retention_period (validated as a duration like 744h or 30d), the two limits most setups tune first.

When To Use Loki Config Generator

Use it when standing up a new Loki instance, whether a quick local filesystem-backed setup for testing or a cloud-storage-backed instance you intend to run for real.

It's also useful for quickly sketching what an S3 or GCS storage_config block looks like when migrating an existing filesystem-backed Loki to object storage.

Often used alongside Prometheus Config Generator, Grafana Dashboard Generator and OpenTelemetry Collector Config Generator.

Features

Advantages

Covers the three most common storage backends with each one's exact nested key names, eliminating a common source of Loki startup failures (wrong key under storage_config).
Validates ingestion_rate_mb and retention_period formats before generating, catching typos before they reach a running Loki process.
Produces a runnable single-binary config quickly, useful as a starting point even for setups that will layer on more advanced settings later.

Limitations

Doesn't generate schema_config, which real Loki deployments need to define index/chunk store periods; add that manually to make this a fully complete config.
Doesn't cover Loki's scale-out (microservices) mode settings like ring configuration or memberlist, only single-binary style config.
Doesn't validate that S3/GCS credentials or bucket names are actually valid or reachable, only that the fields are non-empty.

Examples

A local, single-tenant Loki backed by S3

Input

auth_enabled: false, storage: S3 (bucket loki-logs-prod, region us-east-1), ingestion_rate_mb: 8, retention_period: 744h

Output

auth_enabled: false

storage_config:
  aws:
    bucketnames: loki-logs-prod
    region: us-east-1

limits_config:
  ingestion_rate_mb: 8
  retention_period: 744h

The aws storage block is emitted with the bucket and region, and limits_config carries the ingestion and retention settings.

Best Practices & Notes

Best Practices

Use object storage (S3/GCS) instead of filesystem for anything beyond local testing, since filesystem storage ties your log data to a single node's disk.
Set retention_period deliberately based on compliance or debugging needs; the default without configuration is effectively unlimited, which grows storage costs over time.
Raise ingestion_rate_mb only after confirming your Loki cluster's write path can actually sustain the higher throughput, rather than raising it reactively during an incident.

Developer Notes

The generator is a pure string-building function emitting fixed 2-space YAML with no dependency on a YAML library; ingestion_rate_mb is validated against a numeric pattern and retention_period against /^\d+[smhd]$/ to match Loki's Go duration string format. The S3 branch maps to Loki's storage_config.aws key (not a generic 's3' key), matching Loki's actual config schema.

Loki Config Generator Use Cases

Bootstrapping a single-binary Loki instance's config for local development or a small production deployment
Sketching an S3 or GCS storage_config block before migrating an existing filesystem-backed Loki
Documenting the ingestion/retention limits being applied to a given Loki tenant

Common Mistakes

Nesting S3 settings under a made-up 's3:' key instead of Loki's actual 'aws:' key under storage_config, which this tool avoids by hardcoding the correct key name.
Leaving auth_enabled: true without actually sending an X-Scope-OrgID header from log shippers, which causes every push and query request to be rejected.
Setting retention_period without also configuring a compactor, so Loki accepts the setting but the data is never actually deleted.

Tips

Use the Grafana Dashboard Generator afterward to build LogQL-querying panels once this Loki instance is receiving logs.
Pair this with the OpenTelemetry Collector Config Generator if you want the collector to forward logs to this Loki instance instead of shipping directly with Promtail or a Loki-aware agent.

Loki Config Generator