Loki vs OpenObserve vs SigNoz vs Graylog: Self-Hosted VPS Log Aggregation in 2026

Anyone running production workloads on a VPS in 2026 hits the same wall eventually: SSH-ing into the box, tailing /var/log/syslog, and grepping through scattered application logs stops scaling the moment you cross two or three sites. I hit that wall personally about eighteen months ago when our seven aggregator sites — running daily imports of 100–200 records each on Hostinger shared and a Hostinger VPS — started throwing intermittent failures that were impossible to triage without a unified log view.

This guide compares the four self-hosted log aggregation platforms I considered before settling on one for our stack: Grafana Loki, OpenObserve, SigNoz, and Graylog. Each takes a fundamentally different architectural approach, and the right pick depends on your VPS RAM budget, your existing observability stack, and how much operational complexity you are willing to absorb. I'll share what worked, what broke, and the numbers I measured along the way.

Why Centralize Logs On A VPS In The First Place

If you're running a single VPS with one application, you probably don't need this article. Tail the file. Move on.

But once you cross into multi-site or multi-service territory — which for me meant CloudHostReview, AICraftGuide, HoroAura, HireVane, QuickExam, SoftwarePeeks, and CyberShieldTips all running cron jobs, PHP-FPM, MySQL, Nginx, fail2ban, and CrowdSec — three things break at once:

• Correlation gets impossible. A 500 error on QuickExam at 03:17 UTC may correlate with a MySQL deadlock on a shared database two seconds earlier. You cannot see that across tail -f windows.
• Retention becomes inconsistent. Logrotate behavior varies by service. By the time you SSH in to investigate yesterday's incident, the relevant Nginx access logs may already be gzipped or purged.
• Search latency kills MTTR. Greping a 4 GB compressed Nginx log file for one request ID takes minutes. Indexed search returns it in milliseconds.

A centralized log aggregator solves all three. The question is which one — and that depends mostly on your VPS resources and your appetite for ops work.

I had a hard constraint: the aggregator had to run alongside our actual applications on the same VPS, not on a dedicated observability box. That ruled out anything requiring 8 GB of RAM just to idle. For context, our Hostinger KVM2 VPS has 8 GB total, so I needed something that could live in roughly 1.5–2 GB without OOM-killing the apps it was supposed to be observing.

1. Grafana Loki — The Minimalist Choice

Loki is what Grafana Labs built when they looked at Elasticsearch-backed log stacks and decided full-text indexing was the wrong default. Instead of indexing every line, Loki only indexes a small set of labels (host, service, level) and stores the actual log content as compressed chunks in object storage or local disk. The result: dramatically lower storage cost and RAM footprint, at the price of slower full-text queries.

What I Actually Saw On 8 GB

On a single-binary Loki deployment configured with filesystem storage and a 14-day retention window, the process settled at around 280–320 MB resident memory under our load (roughly 50 MB of logs per day across all seven sites). CPU sat under 2% on a 2-vCPU box except during compaction, which spiked one core briefly every six hours.

The catch is that Loki is not a UI. You need Grafana on top of it to actually query and visualize anything, which adds another 200–250 MB of RAM and a separate process to manage. If you already run Grafana for Prometheus metrics, this is free. If you don't, you're now operating two services where you wanted one.

The LogQL Tax

Loki's query language, LogQL, is intentionally similar to PromQL. If you've written PromQL before, you'll be productive in an hour. If you haven't, expect a real learning curve — particularly around understanding why {job="nginx"} |= "500" is a label filter plus a line filter and not a single full-text query. Once you internalize the model, it's fast. Until you do, you'll write queries that scan far more data than necessary.

Best For

Teams already invested in Prometheus and Grafana, with disciplined labeling, willing to live without ad-hoc full-text search across arbitrary log fields. Storage costs are the lowest in this comparison.

2. OpenObserve — The Rust Single-Binary Newcomer

OpenObserve is the most interesting recent entrant. Written in Rust, it ships as a single binary that bundles logs, metrics, traces, and real-user monitoring (RUM) into one process with columnar storage backed by either local disk or S3-compatible object storage. The pitch is straightforward: replace the four-service LGTM stack with a single download.

Resource Footprint

I tested OpenObserve v0.10 on a fresh Hetzner CX22 (2 vCPU, 4 GB RAM, $4.59/month at the time of writing) ingesting the same log stream I'd been feeding Loki. Idle memory hovered around 850 MB — noticeably higher than Loki, but you're getting metrics and traces in the same process. Under sustained 500 logs/second ingestion the process stayed under 1.3 GB. SQL queries against 30 days of data returned in 200–600 ms depending on filter selectivity.

The storage efficiency claim — up to 140× lower than Elasticsearch — is genuinely impressive in benchmarks, though the comparison is against a worst-case unoptimized Elasticsearch mapping. Against Loki with bloom filters enabled, the gap is much smaller. Against a properly tuned ClickHouse, OpenObserve's edge largely disappears, because both use columnar compression.

Why I'd Pause Before Going All-In

OpenObserve is genuinely early-stage. The 1.0 milestone shipped relatively recently and the project has not yet had the years of production bruising that Loki and Graylog have absorbed. I hit two minor bugs during my evaluation — both filed upstream, both fixed within a week, which speaks well of the maintainers but also tells you something about the maturity curve.

If you are running a small fleet and value the simplicity of one binary, OpenObserve is probably the most exciting option in this list. If you are running anything where a missed log entry costs real money or causes a compliance violation, give it another twelve months.

Best For

Solo operators and small teams who want logs, metrics, and traces from a single install, are comfortable using SQL for queries, and don't mind being on the leading rather than bleeding edge.

3. SigNoz — The OpenTelemetry-Native Option

SigNoz takes a different angle. It is purpose-built around OpenTelemetry as the ingestion protocol and uses ClickHouse as the storage engine. That gives you a single backend that handles logs, metrics, and traces with shared correlation — click a slow trace, jump to the related log lines, drill into the metric series. It is the closest open-source equivalent to what Datadog or New Relic give you commercially.

The ClickHouse Tax

The cost is the underlying stack. A default SigNoz install brings up ClickHouse, ZooKeeper, the SigNoz query service, the SigNoz frontend, and an OpenTelemetry Collector. Even idle, ClickHouse alone wants around 1.5–2 GB of RAM, and the full stack idles closer to 3–3.5 GB. The SigNoz docs themselves recommend 8 GB minimum for non-production use and 16 GB for production.

On our 8 GB Hostinger VPS, SigNoz left me roughly 4 GB for the actual applications. That was tight enough that I had to swap to a larger plan to evaluate it fairly. If your VPS already has 16 GB+ and you're committing to OpenTelemetry as your instrumentation standard, this overhead pays for itself in operational power.

What You Get For The RAM

SQL-backed queries that are genuinely fast on multi-billion-row tables. Trace-to-log correlation that actually works out of the box. Service maps generated automatically from OTel data. Exception tracking. Alerting that understands traces, not just metrics. If you are building a service-oriented architecture from scratch and you instrument everything with the OTel SDK, SigNoz is the most coherent self-hosted choice in this list.

Best For

Teams adopting OpenTelemetry as their observability standard, with at least a 16 GB VPS or a dedicated observability node, who want logs + metrics + traces in one platform without paying SaaS prices.

4. Graylog — The Veteran Enterprise Choice

Graylog has been around since 2010 and shows it. Where the other three options feel like modern tools designed for a Kubernetes-shaped world, Graylog feels like a SIEM that grew sideways into a general log platform — which it largely is. It is the option I'd reach for first if my use case involved compliance audits, role-based access control across many teams, or long-term retention with serious search performance.

What It Takes To Run

Graylog 6.x requires three components: Graylog itself (the JVM application), MongoDB (for configuration and metadata), and OpenSearch or Elasticsearch (for the actual log index). That stack is the heaviest in this comparison. A reasonable minimum for production is 8 GB RAM total, but you'll want 16 GB to give OpenSearch's JVM heap room to breathe without GC pauses ruining your query latency.

I'd recommend Graylog on a dedicated 8 GB VPS at the smallest. Trying to share that node with web applications is a recipe for swap thrash.

Where Graylog Wins

Three places. First, the streams + pipelines + processing rules system is the most powerful in-flight log transformation toolkit of these four — if your logs need parsing, enriching, redacting (think GDPR-flagged PII), and routing to different indexes based on content, Graylog does it without external preprocessors. Second, role-based access control is enterprise-grade out of the box, including LDAP and SAML integration. Third, the full-text search backed by OpenSearch is unmatched for ad-hoc investigation when you don't know the structure of what you're looking for.

Best For

Organizations with multiple teams sharing one log platform, compliance-driven retention requirements, or use cases where unstructured log search across heterogeneous sources is the dominant workload.

Side-By-Side Comparison

Feature	Loki	OpenObserve	SigNoz	Graylog
Minimum RAM (idle)	~300 MB	~850 MB	~3 GB	~4 GB
Recommended VPS	2–4 GB	4 GB	16 GB	16 GB dedicated
Storage backend	Filesystem or S3	Filesystem or S3	ClickHouse	OpenSearch / MongoDB
Query language	LogQL	SQL	SQL + ClickHouse	Lucene + Graylog query
Logs + metrics + traces	Logs only (LGTM separate)	All in one binary	All in one platform	Logs-first, OTel via plugin
UI included	No (needs Grafana)	Yes	Yes	Yes
Maturity	Production-proven	Early-stage	Maturing	Battle-tested since 2010
Best storage efficiency	Very high	Very high	High	Medium

A Decision Framework That Actually Works

After spending real time with each of these on production-equivalent workloads, here is the decision tree I'd give a friend asking which to pick:

If you have less than 4 GB of free RAM on your VPS, your only realistic choices are Loki (with an existing Grafana install) or a hosted SaaS. OpenObserve will fit but won't have headroom for spikes. SigNoz and Graylog are not viable. I learned this the hard way when SigNoz's ClickHouse OOM-killed PHP-FPM during a backfill job — recoverable, but the kind of outage you don't want twice.

If you already use Grafana and Prometheus, install Loki. The integration is so tight that ignoring it costs you more than adopting it. Don't overthink this one.

If you are starting fresh and instrumenting with OpenTelemetry SDKs, SigNoz is the natural choice as long as you can afford the resources. The trace-to-log correlation alone justifies the RAM cost once you've debugged your first slow-endpoint incident with it.

If you have multiple teams, compliance retention requirements, or PII redaction needs, Graylog. Nothing else in this list has the same level of pipeline transformation and RBAC.

If you are a solo operator running a handful of services and want a single binary that does everything, OpenObserve. Just budget time for the occasional rough edge.

Hands-On Setup Notes From My Stack

A few specific things I'd tell my past self before standing any of these up on a Hostinger or Hetzner VPS:

Put the data directory on a separate volume if possible. Hostinger shared and KVM plans use a single root volume; if your log aggregator fills it, your web server starts returning 500s. I now keep a 50 GB block storage volume mounted at /var/lib/observability on the boxes that run Loki, with a cron job alerting at 80% full.

Use a process supervisor. Whether it is systemd, supervisord, or Docker Compose with restart policies, do not run any of these from a screen session. The first time the OOM killer reaps your aggregator at 3 AM and it doesn't come back, you will regret it.

Tune ingestion rate limits before opening the firewall. Every one of these tools has had a moment in the last two years where a misconfigured client looped and shipped gigabytes per minute. Loki's ingestion_rate_mb, OpenObserve's per-stream limits, and SigNoz's collector rate limits all exist for this reason. Set them low to start.

Test your retention policy by simulating time. Set retention to 24 hours, ingest a small batch, jump the system clock 48 hours forward in a disposable VM, and confirm the data actually gets removed. I have seen "retention" configurations silently keep data forever in two of these four projects.

Frequently Asked Questions

Can I run any of these on a $5 VPS? Loki yes, comfortably. OpenObserve yes, with light load. SigNoz and Graylog no — you'll need at least the $10 tier and ideally more.

Do I need Kubernetes for any of these? No. All four ship Docker Compose configurations or single-binary installs that work fine on a standalone VPS. The Kubernetes Helm charts are convenient if you're already in that world, but they are not required.

Which one has the best cloud backup story? OpenObserve and Loki both store cleanly in S3-compatible object storage (Cloudflare R2, Backblaze B2, Wasabi all work). That means your hot tier lives on the VPS disk, and historical data sits in cheap object storage. SigNoz and Graylog store everything in their own databases, so backup means snapshotting ClickHouse or OpenSearch — more involved.

What about Elastic Stack (ELK)? I deliberately left ELK out of this comparison. The licensing changes Elastic shipped in 2021 and the resource footprint of a self-hosted Elastic + Kibana + Logstash stack make it a hard sell against any of these four in 2026 for the small-to-medium VPS use case.

Can I use these with Cloudflare Logpush? Yes. All four can ingest Cloudflare's HTTP/JSON Logpush format with minimal collector configuration. I currently use Loki for this on CloudHostReview — about 40 MB/day of Cloudflare edge logs land in it with no measurable load impact.

The Bottom Line

There is no universally correct answer here. The right log aggregator depends on your VPS budget, your existing observability investments, and how much operational complexity you're willing to take on. Across our seven aggregator sites I ended up running Loki for the majority of workloads (low overhead, plays well with our existing Grafana install) and reserving SigNoz for the one application where OpenTelemetry trace correlation genuinely changes how we debug. OpenObserve sits on a watch list for a re-evaluation in early 2027.

Whatever you pick, the meta-lesson is this: by the time you actually need centralized logging, you'll already wish you had set it up six months earlier. The smallest install of any of these four is better than the most thorough grep session you'll ever run.