ConfigGenerator

Loki Config Generator

Generate production-ready Grafana Loki configurations in YAML. Configure auth, storage backends, ingester, querier, compactor, ruler, and limits for scalable log aggregation.

Output:A ready-to-use configuration file for Loki Config with best practices applied.

Loki Configuration

loki-config.yaml
1auth_enabled: false
2

3common:
4  path_prefix: /loki
5  storage:
6    filesystem:
7      chunks_directory: /loki/chunks
8      rules_directory: /loki/rules
9  replication_factor: 1
10

11server:
12  http_listen_port: 3100
13  grpc_listen_port: 9096
14  log_level: info
15

16limits_config:
17  ingestion_rate_mb: 16
18  ingestion_burst_size_mb: 32
19  max_entries_limit_per_query: 10000
20  retention_period: 744h
21

22schema_config:
23  configs:
24    - from: "2024-01-01"
25      store: tsdb
26      object_store: filesystem
27      schema: v13
28      index:
29        prefix: index_
30        period: 24h
31

32storage_config:
33  filesystem:
34    directory: /loki/chunks
35

36  tsdb_shipper:
37    active_index_directory: /loki/index
38    cache_location: /loki/cache
39    shared_store: s3
40

41compactor:
42  working_directory: /loki/compactor
43  shared_store: s3
44

45distributor:
46  ring:
47    kvstore:
48      store: inmemory
49    replication_factor: 1
50

51ingester:
52  lifecycler:
53    ring:
54      kvstore:
55        store: inmemory
56      replication_factor: 1
57    max_transfer_retries: 10
58  chunk_idle_period: 5m
59  max_chunk_age: 2h
60  chunk_target_size: 1572864
61  chunk_retain_period: 30s
62

63querier:
64  max_concurrent: 10
65

66query_range:
67  split_queries_by_interval: 30m
68  cache_results: true
69

70results_cache:
71  cache:
72    embedded_cache:
73      enabled: true
74      max_size_mb: 100
Not generated yet

What is this tool?

The Loki Config Generator produces production-ready config.yaml files for Grafana Loki, a horizontally-scalable, highly-available log aggregation system. Unlike full-text search engines like Elasticsearch, Loki indexes only labels — making it cost-effective and operationally simple for massive log volumes.

Loki's architecture mirrors Prometheus for metrics: it uses label-based indexing, LogQL for queries, and supports multiple storage backends including filesystem, S3, Azure Blob Storage, and Google Cloud Storage. This generator covers every Loki component — distributor, ingester, querier, query-frontend, compactor, ruler, and storage — producing valid YAML ready for deployment.

How to Use This Tool

1. Auth & Server: Configure multi-tenancy with auth_enabled and set server ports for HTTP (3100) and gRPC (9096) communication between Loki components.

2. Distributor: Receives incoming log streams via HTTP/gRPC, validates them, and distributes chunks across ingesters using consistent hashing ring with configurable replication factor.

3. Ingester: Receives log streams from distributors, buffers them in memory, and flushes compressed chunks to long-term storage. Configure chunk lifecycle with chunk_idle_period, max_chunk_age, and chunk_target_size.

4. Storage: Select the chunk and index storage backend — filesystem for single-node, S3/Azure/GCS for cloud deployments. Index stores are configured separately via boltdb-shipper or TSDB.

5. Querier & Query Frontend: Execute LogQL queries against ingesters and storage. The query frontend splits queries by time interval and retries failed requests for resilience.

6. Compactor: Merges and deduplicates index and chunk files in object storage to reduce storage costs and improve query performance.

7. Ruler: Evaluates recording and alerting rules against Loki, enabling log-based alerting via Alertmanager integration.

Best Practices

  • Always configure a replication_factor of at least 3 for production ingester rings to ensure log durability.
  • Use TSDB as the index store for new deployments — it offers better performance and compaction than boltdb-shipper.
  • Set retention_period on limits_config to control storage costs and comply with data retention policies.
  • Configure chunk_target_size (1.5MB default) and chunk_idle_period to balance memory usage and flush frequency.
  • Deploy the compactor with a shared_store matching your storage backend to keep index files optimized.
  • Use split_queries_by_interval in query frontend to parallelize large time-range queries across multiple queriers.

Common Mistakes

  • Running auth_enabled: true without configuring X-Scope-OrgID headers on push endpoints, causing all writes to fail.
  • Setting replication_factor higher than the number of ingester instances, resulting in stuck flushes and data loss.
  • Using filesystem storage in multi-instance deployments — filesystem is single-node only, use S3/Azure/GCS for distributed setups.
  • Forgetting to configure the schema_config with a valid from date, which causes Loki to reject all incoming data.
  • Not setting max_transfer_retries on ingesters during rolling updates, leading to unflushed chunks being lost.

Security Notes

  • Enable auth_enabled in production and enforce X-Scope-OrgID headers to isolate tenants.
  • Store S3 access keys, Azure account keys, and GCS service accounts in environment variables or secret managers — never in config files.
  • Use TLS for gRPC communication between Loki components (distributor ↔ ingester, querier ↔ store-gateway).
  • Restrict the ruler's alertmanager_url to an internal network and use mutual TLS.
  • Apply network policies to limit which services can reach the Loki HTTP and gRPC ports.

Production Tips

  • Use the microservices deployment mode (separate distributor, ingester, querier, etc.) for clusters above 50GB/day log ingestion.
  • Configure ingester lifecycler with a ring kvstore using consul or etcd for production — avoid the in-memory ring.
  • Deploy a read-write path split: ingesters + distributors on the write path, queriers + store-gateways on the read path.
  • Monitor Loki with its own /metrics endpoint — track ingester flush rates, querier latency, and compactor run durations.
  • Use LogQL metric queries (rate, count_over_time) for alerting instead of grep-like filters to reduce query load.
  • Set max_entries_limit_per_query (default 10000) conservatively to prevent OOM on queriers with high-cardinality label sets.

Frequently Asked Questions

What is Grafana Loki and how does it differ from Elasticsearch?
Loki is a log aggregation system that indexes only labels (metadata), not full log content. This makes it significantly cheaper to operate than Elasticsearch, which indexes every field. Loki uses LogQL for queries and integrates natively with Grafana dashboards.
What storage backends does Loki support?
Loki supports filesystem (single-node only), Amazon S3, Google Cloud Storage (GCS), and Azure Blob Storage for chunks. For index storage, it supports boltdb-shipper and TSDB. S3 is the most common choice for production deployments.
What is the difference between boltdb-shipper and TSDB?
TSDB is the newer, recommended index store offering better write performance, faster compaction, and lower memory usage. boltdb-shipper is legacy but still supported. New deployments should use TSDB.
How does Loki handle multi-tenancy?
Loki supports multi-tenancy via auth_enabled. When enabled, every request must include an X-Scope-OrgID header identifying the tenant. Data is fully isolated between tenants — no tenant can see another tenant's logs.
What is LogQL?
LogQL is Loki's query language inspired by PromQL. It supports log stream selectors (label matching), line filter patterns (regex, JSON), and metric queries (rate, count_over_time, unwrap) for creating dashboards and alerts.
How do I deploy Loki in production?
Use the microservices deployment mode with separate distributor, ingester, querier, query-frontend, and compactor processes. Deploy on Kubernetes using the official Helm chart or use Docker Compose for smaller setups. Always use S3 or GCS for storage and TSDB for the index.
What is the Loki ruler and when should I use it?
The ruler evaluates LogQL recording and alerting rules at regular intervals. Use it to create log-based alerts (e.g., error rate exceeding threshold) that fire to Alertmanager, or recording rules to pre-compute expensive queries for dashboards.

How We Keep Your Configs Safe & Valid

Built-in Error Checking

Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.

100% Private & Local

All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.

Secure Settings by Default

Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.

Ready for CI/CD & Git

Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.

Infrastructure as Code

Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.

Monitoring & Tracing

Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.

Container & Docker Safety

Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.

Multiple Output Formats

Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.

Related Tools

Prometheus Config Generator

Generate Prometheus scrape and alerting configurations to pair with Loki.

Vector Config Generator

Configure Vector pipelines to ship logs to Loki.

Docker Compose Generator

Deploy Loki alongside Grafana in a Docker Compose stack.