Self-hosted log management

Self-hosting your logs trades a monthly bill for an afternoon of work.

That is the whole decision. Everything below is about how big the bill is, how long the afternoon takes, and which tool makes the afternoon shorter.

What log management actually has to do

Every log system does four jobs. Tools differ in how many they cover.

  1. Collect. Get log lines off the machines that produce them.
  2. Store. Write them somewhere durable, and delete them on a schedule.
  3. Search. Answer “what happened at 03:14 last Tuesday” in seconds.
  4. Alert. Tell you when something appears that should not.

A pile of files on a log server covers two of the four. You can search them with grep until the day you need to correlate two hosts. Then you find out why log management is a product category.

Why teams move off hosted services

The bill scales with your worst day. Hosted log services price per GB ingested. Your bill tracks your incident volume. A retry loop at 2am costs money.

Retention gets cut first. When the bill hurts, the retention window shrinks. Seven days is common. Seven days is not enough to investigate a bug a customer reports on Monday about something that happened the week before.

Logs contain things you did not mean to send. Session tokens. Email addresses. Query parameters with customer IDs. Every log line you ship to a third party is a copy of your data on someone else’s disk.

Contracts sometimes say no. Data residency clauses, regulated data, and air-gapped networks all rule out shipping logs offsite. See self-hosted on-premise logging if that is your situation.

What self-hosting costs instead

Be honest with yourself about this part.

  • A server. A 1–2GB VPS runs a small log server. Call it $10–20 a month.
  • Disk. Logs are mostly text and compress well, but they accumulate. Retention is a disk-budget decision.
  • Upgrades. Somebody has to apply them.
  • Backups. Your log server is now a system of record. Back it up.
  • Being on the hook. Nobody else gets paged when log ingest stops.

The last one is the real cost. The rest is rounding error next to a per-GB bill.

The options, and who each one suits

Option What you run Suits
rsyslog / syslog-ng + files One daemon, plus grep Few hosts, low volume, no search UI needed
ELK (Elasticsearch, Logstash, Kibana) 3–4 services, 2 JVMs, Beats on every host Large volume, a team to operate it
Graylog Graylog + Elasticsearch/OpenSearch + MongoDB Teams that want ELK power with a friendlier UI
Loki + Grafana + Promtail 3 services plus object storage Kubernetes shops already running Grafana
Central Logging One binary Small teams under ~10GB/day with no platform team

The pattern is straightforward. Capability goes up and so does the number of processes you keep alive. Pick the smallest thing that answers your questions.

Longer write-ups: ELK, Graylog, Papertrail, Datadog.

Sizing a self-hosted log server

Two numbers decide your hardware: daily ingest volume and retention window. Multiply them for a rough disk figure, then add headroom.

Central Logging’s own guidance: 1GB of RAM handles about 15GB of logs at 15-day retention. Elasticsearch-based stacks want several GB of RAM before they store a single line, because the JVM heap wants roughly half the machine.

Measure before you guess. On a Linux host:

journalctl --since "24 hours ago" | wc -c

That is one host’s systemd journal for a day. Multiply by your host count, add application logs, and you have a starting estimate.

Retention is a policy, not a setting you forget

Decide three things and write them down:

  1. How long you keep logs. Long enough to investigate the bug reports you actually receive.
  2. What you never log. Passwords, tokens, full card numbers. Filter at the source, not after storage.
  3. What happens when the disk fills. Either retention prunes automatically or you get paged.

In Central Logging, retention is per log source and defaults to 15 days. Older entries are cleaned up automatically.

Backups: your logs are now your problem

Self-hosting means the backup is yours to arrange. Look for a system whose storage you can copy.

Central Logging keeps everything in SQLite databases under a cl-data/ directory:

cl-data/
├── db.db                    # Main application database
├── sessions.db              # Session store
├── {source-token}/
│   └── logs.db              # Per-source log database
└── metrics/
    └── {metric-token}/
        └── metrics.db       # Per-metric time-series data

Those are files. Copying files is a solved problem.

It also ships nightly S3 backups. Point them at AWS S3, or at a self-hosted S3-compatible server like Garage or MinIO:

BACKUP_S3_ENDPOINT=https://s3.example.com:3900
BACKUP_AWS_REGION=garage
BACKUP_S3_BUCKET=cl-backups
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...

Backups land under appdb/ and logs/{source-token}/, and anything older than 15 days is removed.

A checklist for choosing

Ask each candidate these questions before you install it.

  • How many processes must stay running for ingest to work?
  • What happens to logs in flight when the server restarts?
  • Can I query across two hosts in one search?
  • How do I delete a customer’s data if I am asked to?
  • What does the upgrade look like? Is it coordinated across components?
  • Can I back it up by copying files?
  • What is the smallest machine it runs on?

If a tool cannot answer these plainly, you are the one who will answer them at 3am.

Where Central Logging fits

Central Logging is one static binary. No JVM, no Docker requirement, no database to install. Run it and you get an HTTPS server with an auto-issued TLS certificate, a web UI, an ingest API, SQL and full-text search, alerting, uptime checks, host monitoring, cron monitoring, and Prometheus metrics scraping. It costs $187 once.

It is built for teams under roughly 10GB/day. Storage is SQLite with WAL.

When it is the wrong choice: you need horizontal scale, multi-node high availability, or you push terabytes a day. Central Logging runs on one node. If that is disqualifying, run Loki or ELK and accept the operational work that comes with them.

Next steps

💌 Get notified on new features and updates

Only sent when a new version is released. Nothing else.