Loki and Promtail on One VPS: When It Is Enough

You already have journalctl. Loki is for when you want the same logs in Grafana, with LogQL across units, without SSH. On one VPS that is a convenience, not a platform. Promtail tails the journal and pushes to Loki. Loki stores chunks on local disk. Grafana asks Loki the way it asks Prometheus. If that sentence is all you need, the stack is enough. If you are about to add object storage, three replicas, and a gateway, you have left the one-VPS story.

The honest limit is this: Loki on the same box it is watching will go dark with the box. Retention is bounded by High-Speed SSD free space. Cardinality from crazy labels will blow RAM. Treat it as a 7 to 14 day search index, not as an archive.

Filesystem store, not a pretend cluster

Use the single-process binary or the official container, BoltDB shipper or TSDB index, filesystem folder under /var/lib/loki, HTTP on 127.0.0.1:3100. Set retention. Disable auth only because it is localhost; do not publish 3100. Cap the working directory with the same discipline as the Prometheus TSDB.

auth_enabled: false
server:
  http_listen_address: 127.0.0.1
  http_listen_port: 3100
common:
  path_prefix: /var/lib/loki
  storage:
    filesystem:
      chunks_directory: /var/lib/loki/chunks
      rules_directory: /var/lib/loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory
schema_config:
  configs:
    - from: "2026-01-01"
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h
limits_config:
  retention_period: 168h
  max_query_lookback: 168h
  ingestion_rate_mb: 4
  volume_enabled: true
compactor:
  working_directory: /var/lib/loki/compactor
  retention_enabled: true
  delete_request_store: filesystem

Seven days is 168 hours. Start there. Raise only after du -sh /var/lib/loki and a week of real traffic. Nginx access logs will dominate if you send them. Often you should not: keep access logs in the journal with a short vacuum, and send only error priority plus the app unit to Loki.

Promtail reads the journal, not a pile of paths

A job that tails /var/log/*.log will miss units that never opened a file and will duplicate anything journald already has. The journal scrape is the one job.

server:
  http_listen_address: 127.0.0.1
  http_listen_port: 9080
positions:
  filename: /var/lib/promtail/positions.yaml
clients:
  - url: http://127.0.0.1:3100/loki/api/v1/push
scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
    relabel_configs:
      - source_labels: ['__journal__systemd_unit']
        target_label: unit
      - source_labels: ['__journal_priority_keyword']
        target_label: level

Keep labels tiny: unit and level. Do not promote arbitrary message fields into labels. Label values that are unique per line (request IDs, URLs) explode the index and are the usual way a "small" Loki eats the VPS. Filter in LogQL instead: {unit="myapp.service"} |= "error".

Drop noisy units in Promtail if needed: kernel debug, health checks that log every 5 seconds, Prometheus itself. The point of Loki on one node is searchable errors, not a second copy of every systemd line you can already journalctl -f.

When it is enough, and when it is not

Enough: one or two apps, a reverse proxy, 7 days of errors in Grafana next to CPU graphs, SSH still available for the long tail. Not enough: you need 90 days, you need the logs to survive the VPS, you ingest access logs at tens of MB/s, or you have more than one node and you are about to pretend this Loki is a central cluster. At that point, ship off-box or stop ingesting access logs.

RAM: give Loki a systemd MemoryMax. A 2 GB VPS that also runs the app, Prometheus, and Grafana cannot donate a gigabyte to log queries. If Grafana times out, the query is too wide, not "need more cores." Narrow the label matcher and the time range first.

Operate it as three units: loki, promtail, grafana-server. Back up the Loki config, not the chunks. Chunks are rebuildable from journald for as long as the journal exists, which is why journal retention and Loki retention should be in the same ballpark. If the journal is 14 days and Loki is 7, you still have SSH for the extra week. Add Loki as a Grafana data source on localhost:3100 only after Promtail has been pushing for an hour, then run one query scoped to a single unit so you know the pipeline works before you trust it in an incident.

Takeaway

Loki plus Promtail on one VPS is a 7-day search window over the journal, not a cluster. Keep labels tiny, cap retention, and stay on localhost. You can try the pair on a Netbay Ubuntu VPS in Lucknow in under 60 seconds — netbayhosts.in.