Configure Loki to store logs in S3

For Loki 3.x, select object_store: s3 in the schema and configure the S3 client under storage_config.aws. TSDB ships index files to object storage alongside log chunks. Do not copy the old shipper shared_store setting: it was removed in Loki 3.0.

S3 does not make the process stateless. Active indexes, the write-ahead log (WAL), and caches still have local storage requirements.

Single-process configuration example

This is a single-process example with one replica and an in-memory ring, not a highly available production topology. Create a bucket, set its real region, grant the Loki workload the necessary bucket permissions, and make /loki writable with persistent storage for the WAL.

auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  instance_addr: 127.0.0.1
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

ingester:
  chunk_idle_period: 5m
  max_chunk_age: 1h
  wal:
    enabled: true
    dir: /loki/wal

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: s3
      schema: v13
      index:
        prefix: index_
        period: 24h

storage_config:
  tsdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/cache
  aws:
    bucketnames: my-loki-logs
    region: us-east-1

The AWS example omits static credentials so the supported AWS credential chain can obtain workload credentials. On EKS, configure a supported role mechanism such as IRSA rather than embedding long-lived keys.

auth_enabled: false selects single-tenant operation; it does not provide HTTP authentication. Keep this endpoint behind appropriate access controls. Verify the configuration with the exact Loki release you deploy, for example using its -verify-config option. This example has not been exercised against a live bucket.

For a new installation, the schema's from date must precede the data being written. For an existing installation, follow the schema migration process and retain historical schema entries needed to read older data.

Adapt the S3 client for MinIO

Replace the aws block with settings for your endpoint. An HTTP-only development example is:

storage_config:
  aws:
    bucketnames: my-loki-logs
    endpoint: minio:9000
    region: us-east-1
    access_key_id: ${AWS_ACCESS_KEY_ID}
    secret_access_key: ${AWS_SECRET_ACCESS_KEY}
    insecure: true
    s3forcepathstyle: true

Merge this block with the preceding tsdb_shipper configuration; it is not a complete standalone config. Start Loki with -config.expand-env=true to expand ${...} variables. Use TLS for a production endpoint and set insecure: false accordingly. Path-style addressing is often useful with MinIO, but whether it is required depends on the endpoint's virtual-host/DNS configuration.

Understand what the WAL protects

A persistent WAL supports replay after a process crash. It does not guarantee zero loss after every failure: disk loss, corruption, exhausted storage, replication, and recovery procedures still matter. A cache is replaceable; a WAL containing data not yet uploaded is not equivalent to a cache.

Frequently asked questions

What causes SignatureDoesNotMatch?

Check the credentials, signing region, endpoint, system clock, and any proxy rewriting the request. For an S3-compatible endpoint, verify its supported addressing mode too. A generic 403 can also be an authorization problem; read the specific error before changing settings.

Can an existing deployment keep boltdb-shipper?

Historical data may still use it. TSDB is the recommended direction for new deployments, with the appropriate current schema. Do not rewrite old schema entries merely to make them resemble a new example; follow the documented migration path.

References

• Loki configuration examples
• Loki upgrade notes and removed settings
• Loki write-ahead log