Self-Host Grafana Loki: Log Management on UK VPS 2026

If you want to self-host Grafana Loki, you can turn a single UK VPS into a proper centralised logging platform without paying per-gigabyte SaaS bills. Loki is a lightweight, cost-effective log aggregation system from Grafana Labs, and it pairs perfectly with the metrics stack we covered in our guide to Prometheus and Grafana monitoring on a UK VPS. Think of this as the logs companion to that metrics article: same dashboard, same VPS, all your log management in one place.

What Is Grafana Loki?

Grafana Loki is an open-source, horizontally scalable log aggregation system built by Grafana Labs. It is frequently described as “Prometheus, but for logs” because it borrows the same label-based data model. Rather than indexing the full text of every log line the way Elasticsearch does, Loki indexes only a small set of metadata labels (such as job, host or app) and stores the raw log content as compressed chunks.

That single design decision is what makes Loki so cheap to run. Full-text indexing engines like the ELK stack (Elasticsearch, Logstash, Kibana) are powerful but hungry: they consume large amounts of RAM and disk to keep every token searchable. Loki keeps the index tiny and pushes the heavy lifting to query time, so it happily runs alongside your other services on a modest VPS. The trade-off is honest: if your primary need is deep full-text search across huge volumes, an engine such as OpenSearch or ELK may suit you better. For most teams who simply want reliable, affordable centralised logging, Loki hits the sweet spot.

Why Self-Host Log Management

Hosted log platforms such as Datadog Logs are excellent, but they bill per gigabyte ingested. Logs are noisy and grow relentlessly, so those bills climb fast and unpredictably. Running your own Loki instance turns a variable, volume-based cost into a flat, known cost: the price of the VPS it lives on. If you already run monitoring or self-hosted uptime monitoring on a UK VPS, adding Loki to the same box is a small step.

There is also a compliance angle that matters for British businesses. Logs routinely contain personal data such as client IP addresses, usernames and request paths. Shipping all of that to a third-party platform, often outside the UK, raises real GDPR and data-residency questions. Self-hosting keeps your log data on infrastructure you control, in the UK, on a UK VPS such as those from UK Speed. The trade-off is that you own the operations: you run it, patch it, and back it up yourself.

What You Need to Self-Host Grafana Loki

The good news is that the requirements are modest. To self-host Grafana Loki comfortably you need:

• A UK VPS running a modern Linux distribution (Ubuntu 24.04 or Debian 12 are ideal).
• 2 vCPUs and 2–4 GB RAM for a small to medium workload; more if you ingest heavily.
• Docker and Docker Compose installed for a clean, reproducible deployment.
• Enough disk for your log retention window (start with 20–40 GB and monitor it).
• A domain or subdomain plus a reverse proxy if you want secure external access.

How Loki, Promtail and Grafana Fit Together

Self-hosted Loki is really a small stack of three cooperating parts. An agent collects logs and ships them, Loki stores and indexes them, and Grafana lets you query and visualise them. Understanding these roles makes the configuration much clearer.

Promtail is the classic agent and is still very widely deployed, though Grafana Labs now positions Grafana Alloy as its successor. Both do the same core job: tail logs, add labels, and forward them to Loki’s push endpoint. Because Grafana speaks to both Loki and Prometheus, you can view metrics and logs side by side on one dashboard, which is the real payoff of running the whole observability stack together.

How to Install Loki with Docker Compose

The cleanest way to deploy the stack is with Docker Compose, which keeps all three services and their configs version-controlled in one folder. If Docker is new to you, our Docker Compose on a UK VPS guide covers the basics. Always cross-check versions and options against the official Grafana Loki documentation, as flags evolve between releases.

Create a project directory and a docker-compose.yml like the one below:

services:
  loki:
    image: grafana/loki:3.1.1
    command: -config.file=/etc/loki/loki-config.yaml
    volumes:
      - ./loki-config.yaml:/etc/loki/loki-config.yaml
      - loki-data:/loki
    ports:
      - "127.0.0.1:3100:3100"

  promtail:
    image: grafana/promtail:3.1.1
    command: -config.file=/etc/promtail/promtail-config.yaml
    volumes:
      - ./promtail-config.yaml:/etc/promtail/promtail-config.yaml
      - /var/log:/var/log:ro
    depends_on:
      - loki

  grafana:
    image: grafana/grafana:11.2.0
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=change-me-now
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "127.0.0.1:3000:3000"

volumes:
  loki-data:
  grafana-data:

Notice that Loki and Grafana are bound to 127.0.0.1, not 0.0.0.0 — this keeps them off the public internet, which matters because Loki ships with no authentication by default. Next, a minimal loki-config.yaml that stores chunks on the local filesystem:

auth_enabled: false
server:
  http_listen_port: 3100
common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory
schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

Run docker compose up -d, then open Grafana on http://127.0.0.1:3000 (via an SSH tunnel or reverse proxy), log in, and add a new Loki data source pointing at http://loki:3100. Within the Compose network the services reach each other by service name, so loki resolves correctly.

How to Ship Logs with Promtail

Promtail is the piece that actually reads your logs and forwards them. Its config defines a clients block (where to push) and one or more scrape_configs (what to read and how to label it). Here is a practical promtail-config.yaml that ships everything under /var/log:

server:
  http_listen_port: 9080
positions:
  filename: /tmp/positions.yaml
clients:
  - url: http://loki:3100/loki/api/v1/push
scrape_configs:
  - job_name: varlogs
    static_configs:
      - targets: [localhost]
        labels:
          job: varlogs
          host: web01
          __path__: /var/log/*log
  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          host: web01
          __path__: /var/log/nginx/*.log

The labels you set here are exactly how you will later filter logs, so choose them thoughtfully. Promtail can also read the systemd journal directly with a journal scrape config — handy if you have followed our guide on reading server logs with journalctl and want that same data centralised. Restart the stack and, within seconds, log lines start flowing into Loki.

Query Logs with LogQL in Grafana

LogQL is Loki’s query language, and it feels immediately familiar if you know PromQL. Every query starts with a label selector in curly braces, which narrows down the log streams, followed by optional line filters that match text within those streams. Open Grafana’s Explore view, pick the Loki data source, and try:

# All lines from the varlogs job
{job="varlogs"}

# Only nginx lines containing the word error
{job="nginx"} |= "error"

# A metric query: rate of nginx errors over 5 minutes
rate({job="nginx"} |= "error" [5m])

The first query returns raw lines. The second adds the |= line filter to keep only matching entries (use != to exclude, or |~ for a regex). The third is where LogQL shines: it converts matching log lines into a numeric time series you can graph and even alert on, giving you metrics derived straight from logs. This is what lets you build a single Grafana dashboard that blends Prometheus metrics with Loki-derived signals.

Configure Retention and Storage

Logs never stop arriving, so retention is not optional — without it your disk will eventually fill. Loki handles deletion through its compactor, driven by a retention_period limit. A minimal addition to your loki-config.yaml looks like this:

limits_config:
  retention_period: 720h   # 30 days
compactor:
  working_directory: /loki/compactor
  retention_enabled: true
  delete_request_store: filesystem

For small and medium setups the local filesystem is perfectly fine. As volumes grow, Loki can store its chunks in S3-compatible object storage instead — and you can run that yourself with MinIO, keeping the data on your own UK infrastructure rather than a public cloud bucket. Whichever you choose, keep an eye on disk usage and set your retention to match both your compliance needs and the space you have.

Best Practices for Production Loki

A few habits separate a hobby install from a dependable production log management system:

• Never expose port 3100 publicly. Loki has no built-in authentication, so keep it on 127.0.0.1 or a private network and place it behind a reverse proxy with HTTPS and auth if it must be reached remotely.
• Secure Grafana. Change the default admin password immediately, enable HTTPS, and restrict access.
• Label wisely. Avoid high-cardinality labels such as user IDs or request IDs — they explode the number of streams and hurt performance. Keep labels few and stable, and search detail with line filters instead.
• Always set retention. Enable the compactor from day one so disks do not silently fill.
• Back up configs and data. Version your compose and YAML files in Git and back up the chunk store.
• Harden the host. Keep the VPS patched, lock down SSH, and consider running the agent as a systemd service on hosts where you are not using Docker.

Conclusion

Self-hosting Grafana Loki gives you cost-effective, GDPR-friendly centralised logging that lives right next to your metrics, all on a single UK VPS you control. It is not a full-text search monster like ELK, and it does not pretend to be — but for the everyday reality of tailing, filtering and alerting on logs, it is hard to beat on price and simplicity.

Pair it with Prometheus and Grafana for a complete observability picture, and you have a professional monitoring platform for a fraction of SaaS costs. Here is what to do next:

• Spin up the Docker Compose stack on a test UK VPS and add Loki as a Grafana data source.
• Point Promtail at /var/log and confirm lines appear in Grafana’s Explore view.
• Enable the compactor and set a retention period that matches your policy.
• Lock everything down behind a reverse proxy before going to production.