Self-Hosted Log Management: Papertrail & Datadog Alternatives in Europe (2026)

Logs are where the truth lives. When a request 500s at 2am, the log line is the difference between a five-minute fix and a two-hour guess. The problem is that logs are also the messiest, most personal-data-laden stream your application produces — IP addresses, email addresses, user IDs, session tokens, the occasional password someone accidentally logged. Which makes where your logs are stored a GDPR question, not just an operational one.

For years the default answer was a US SaaS: ship everything to Papertrail, Loggly or Datadog and search it in their UI. Convenient, and — for a European company handling EU personal data — increasingly awkward. Datadog and Papertrail (SolarWinds) are US-operated, which means your logs, PII and all, sit under US jurisdiction and the CLOUD Act.

This guide covers the European options in 2026: DanubeData Log Explorer for logs from your managed instances, and self-hosted Grafana Loki, OpenSearch and Graylog for centralizing logs from anywhere — all keeping your log data in the EU. We will compare cost and effort honestly, and finish with a Docker Compose Loki + Grafana stack you can stand up on a VPS in fifteen minutes.

Why teams move off Papertrail and Datadog

1. Logs are full of personal data

A single access-log line often contains an IP address (personal data under GDPR), and application logs routinely carry email addresses, user identifiers and request payloads. Shipping that stream to a US-operated log SaaS means exporting personal data to a US processor and adding CLOUD Act exposure to some of the most sensitive operational data you hold. For a DPIA on a system with special-category data, "our logs are in Datadog US" is a finding.

2. Log SaaS pricing punishes success

Datadog and similar per-GB-ingested models are famous for bills that scale faster than your traffic. A chatty service, a debug flag left on, or a traffic spike can turn a predictable invoice into a nasty surprise. Self-hosted and flat-rate options make cost a function of the disk you provision, not the volume you happen to emit this month.

3. Residency and retention rules you cannot satisfy on a shared US plan

If a customer contract or a regulator requires EU-only storage and a specific retention-and-deletion policy, a shared US SaaS plan often cannot give you a signable answer. Owning the store — or using an EU processor that names its datacenter — can.

Option 1: DanubeData Log Explorer (managed, zero setup)

If you run your databases, caches, queues, serverless containers or apps on DanubeData, Log Explorer gives you searchable logs for those instances directly in the console — no agent to install, no pipeline to build. It is backed by Grafana Loki running inside the DanubeData cluster in Germany, so your logs never leave the EU.

• Per-instance log streams for your managed services, searchable with keyword filters
• Query across up to 10 resources at once with time-series charts alongside the raw lines, so you can see a spike and drill into it
• Exporter sidecars are filtered out — you see your service's output, not our metrics exporters cluttering the stream
• Recent-window retention tuned for live debugging (roughly the last three days) — the window you actually reach for during an incident
• In the EU, under the DanubeData DPA — same jurisdiction as the instances producing the logs

Log Explorer is built for the "something is wrong right now, show me what this instance is doing" workflow. It is not a general-purpose ingest-anything-from-anywhere log lake — for that, or for long compliance retention, you either self-host (below) or ship logs to object storage for archival. The honest framing: if your workloads are on DanubeData, Log Explorer is the fastest path to searchable, EU-resident logs; if you need to centralize logs from many external sources or keep years of history, self-host.

Option 2: Self-hosted Grafana Loki (the pragmatic default)

Grafana Loki is the "Prometheus for logs" — it indexes labels, not full text, which keeps it cheap and fast to run. Paired with Grafana for querying and Promtail or Alloy for shipping, it is the most popular self-hosted stack in 2026 for a reason: modest resource footprint, S3-compatible object storage for the log chunks, and a query language (LogQL) that feels natural if you already use Prometheus.

Run it on a DanubeData VPS and point its chunk storage at DanubeData Object Storage, and you have a fully EU-resident log platform for the cost of a VPS plus cheap object storage — no per-GB ingest fees, ever.

A working Docker Compose stack

# docker-compose.yml — Loki + Grafana + Alloy on a single VPS
services:
  loki:
    image: grafana/loki:3.0.0
    command: -config.file=/etc/loki/config.yml
    volumes:
      - ./loki-config.yml:/etc/loki/config.yml
      - loki-data:/loki
    ports:
      - "3100:3100"
    restart: always

  grafana:
    image: grafana/grafana:11.0.0
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=change-me
      - GF_SERVER_ROOT_URL=https://logs.yourdomain.com
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3000:3000"
    restart: always

  alloy:
    image: grafana/alloy:latest
    command: run /etc/alloy/config.alloy
    volumes:
      - ./config.alloy:/etc/alloy/config.alloy
      - /var/log:/var/log:ro
    restart: always

volumes:
  loki-data:
  grafana-data:

Point Loki's storage at DanubeData Object Storage so the log chunks live in cheap, EU-resident S3 instead of filling your VPS disk:

# loki-config.yml (storage section)
storage_config:
  aws:
    s3: https://ACCESS_KEY:SECRET_KEY@s3.danubedata.ro/my-loki-bucket
    s3forcepathstyle: false
    region: eu-central-1
  boltdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/cache

schema_config:
  configs:
    - from: 2024-01-01
      store: boltdb-shipper
      object_store: aws
      schema: v13
      index:
        prefix: index_
        period: 24h

limits_config:
  retention_period: 2160h   # 90 days — set to your compliance requirement

Add Loki as a Grafana data source (http://loki:3100), and you can query with LogQL:

# All errors from the api service in the last hour
{service="api"} |= "ERROR"

# 5xx responses, parsed and rate-d
{service="nginx"} | json | status >= 500

# Count errors per service over time (for a dashboard panel)
sum by (service) (count_over_time({env="prod"} |= "ERROR" [5m]))

Best fit: most teams. Loki gives you the SaaS experience — search, dashboards, alerting — on infrastructure and in a jurisdiction you control, at flat cost.

Option 3: OpenSearch (when you need full-text power)

If your teams live in log search — complex full-text queries, aggregations, the Kibana-style experience — OpenSearch (the Apache-2.0 fork of Elasticsearch) with OpenSearch Dashboards is the heavyweight option. It indexes everything, which makes queries powerful and storage hungrier. Expect to give it real RAM (8 GB+ for a comfortable single node) and to manage index lifecycle policies to control disk growth.

Best fit: teams that need rich full-text search and aggregation across high log volume and are prepared to operate a heavier stack. This is what powers a lot of security (SIEM) and analytics use cases.

Option 4: Graylog (structured logging with built-in management)

Graylog sits between Loki and OpenSearch: an OpenSearch/Elasticsearch backend for storage, plus a purpose-built log-management UI with streams, pipelines, alerts and role-based access out of the box. If you want more log-management structure than raw Grafana but do not want to build it yourself, Graylog is a strong middle path.

Best fit: teams wanting turnkey stream routing, alerting and access control on top of a full-text backend.

Comparison table

Keeping PII out of your logs in the first place

Wherever your logs live, the cheapest compliance win is not logging personal data you do not need. A few habits:

• Redact at the source — mask emails, tokens and card numbers in your logging middleware before the line is written, not after
• Log identifiers, not identities — a user ID that maps back to a person in your database beats logging the email directly
• Set retention deliberately — 90 days covers most debugging and audit needs; keeping years of raw logs "just in case" is a liability, not an asset
• Treat IPs as personal data — because under GDPR they are; consider truncating the last octet if you only need coarse geolocation

FAQ

Can DanubeData Log Explorer ingest logs from my own servers?

Log Explorer shows logs from services you run on DanubeData — managed databases, caches, queues, serverless containers and apps. To centralize logs from external servers or many sources, self-host Loki, OpenSearch or Graylog on a DanubeData VPS (see the Docker Compose above) and ship to it from anywhere.

How long are logs kept?

Log Explorer keeps a recent window sized for live debugging (about three days). If you need long retention for compliance, self-host with a retention policy you control, or archive logs to DanubeData Object Storage — where 1 TB with 1 TB of egress is €3.99/month.

Loki or OpenSearch — which should I self-host?

Start with Loki. It is cheaper to run, indexes labels instead of full text, and its object-storage backend keeps VPS disk usage low. Reach for OpenSearch only when you genuinely need heavy full-text search and aggregation — a SIEM use case, say — and can give it the RAM it wants.

What does self-hosting actually cost?

A Loki + Grafana stack runs comfortably on a 4 GB DanubeData VPS at €8.99/month, with log chunks in Object Storage at €3.99/month for the first terabyte. That is a flat, predictable ~€13/month for a full EU-resident log platform — versus a per-GB SaaS bill that grows with every noisy deploy.

Get started

• Explore DanubeData Log Explorer — searchable logs for your managed instances, in the EU
• Launch a VPS to self-host Loki, OpenSearch or Graylog
• Add Object Storage for cheap, EU-resident log archival
• Sign up for €50 in credit and build your logging stack today

Your logs are some of the most revealing data you hold. In 2026, keeping them searchable, affordable and inside the EU is no longer a trade-off — it is a Docker Compose file away.