Self-hosted on-premise logging

Some logs are not allowed to leave the building.

If that describes you, most of the log management market is already out. Hosted services are off the table by definition. What is left is software you run on hardware you control, and the useful question becomes: which of it works on a network that cannot phone home?

Who actually needs on-premise

Four situations, and they are different problems.

Data residency in a contract. A customer agreement says their data stays in a jurisdiction, or on infrastructure you control. Logs are their data. A hosted log service in another region breaks the clause.

Regulated data in log lines. Health records, payment data, government systems. The logs inherit the classification of what they describe, whether or not anyone planned for that.

Segmented networks. The log server sits inside the perimeter. Hosts push to it. Nothing crosses the boundary.

Genuinely air-gapped. No outbound route at all. Software gets in on removable media or through a one-way transfer.

The first three are ordinary self-hosting. The fourth changes what software you can use, and it is worth being precise about why.

What air-gapped rules out

Ask any candidate tool these five questions.

1. Does it phone home? Telemetry, license checks, usage reporting, update pings. Anything that expects an outbound connection will fail, and some tools fail badly rather than quietly.
2. How does it get a TLS certificate? Automatic certificates from Let’s Encrypt need an outbound connection to an ACME endpoint. On an isolated network there is none.
3. How do updates work? If the update mechanism downloads from the vendor, you need a manual path instead.
4. Where does the data land? You need to know which files to back up and which files to shred.
5. Does the license need to reach anything? Ask this explicitly, before purchase, not after installation.

Most tools answer three of the five. The answers matter more than the feature list.

Central Logging on-premise

No telemetry. Your log data stays on your server, on your disks. Nothing about your logs, your hosts or your usage is reported anywhere.

One outbound request, and you can ignore it. Once an hour the server fetches a small static file that says what the newest published version is. That is what draws the “new version available” badge in the admin UI. It sends no identifiers and no data about your install. On an isolated network the fetch fails, the failure is logged, and everything else carries on. Block it at the firewall if you would rather it never tried.

No external dependencies at runtime. It is one statically linked binary. No JVM, no Docker, no separate database, no package repository to reach at start-up.

Data lives in files you can point at:

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

SQLite databases in a directory. When an auditor asks where the data is, that is the answer. When you need to delete a log source’s data, it is one directory.

Agents push outbound, not inbound. clagent sends logs from each host up to the server over HTTPS. No inbound connection to your hosts is required, which suits a segmented network. Configure it in /etc/clagent.toml:

URL = "https://logs.internal.example.com/your-log-source-token"

TLS without Let’s Encrypt

Automatic certificate issuance needs outbound access to an ACME endpoint. On an isolated network you will not have it. Run the server on a plain port instead and terminate TLS yourself, with a certificate from your internal CA:

PORT=:8080 ./centrallogging-linux-amd64

Then put nginx, Caddy or your existing load balancer in front. This is the same setup people use behind a corporate proxy, and it is a supported configuration.

Updates without outbound access

The built-in -update flag downloads a new binary from the vendor. On an air-gapped network it cannot.

Do it by hand instead. Bring the new binary in the way everything else gets in, then:

sudo systemctl stop centrallogging
# replace the binary
sudo systemctl start centrallogging

The binary is the entire application. Replacing it is the entire update. This is one of the places a single-binary design earns its keep — there is no coordinated upgrade across four services, and no package repository to mirror.

Backups that never leave the network

Nightly backups upload the main database and every per-source log database over the S3 protocol. That does not have to mean AWS. Point them at a self-hosted S3-compatible server on your own network — Garage or MinIO both work:

BACKUP_S3_ENDPOINT=https://s3.internal.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}/. Anything older than 15 days is removed automatically.

If you would rather not run object storage at all, skip the feature. The data is SQLite files. Copy the cl-data/ directory with whatever backs up the rest of that server.

Retention, deletion and data minimisation

Retention is set per log source and defaults to 15 days. Older entries are removed automatically. Set it to match your retention policy rather than your disk size.

Two related things worth doing:

Filter at the source. The safest handling of a secret in a log line is to never log it. Each log source supports a JavaScript transform script that runs on incoming lines, so you can drop or redact fields before they are stored. Scripts get a 1 second timeout per line, and you can test them in the UI before saving.

Know your deletion story. If someone asks you to delete their data, you need to be able to find it. Structured JSON logs and json_extract make that a query rather than an archaeology project.

Before you buy

Two answers decide this for most isolated networks, and a sales page is the wrong place to hunt for them. Here they are.

License activation works offline

This is the question air-gapped buyers ask first, so here is the direct answer: the license key is verified locally and never leaves your server.

The key is a signed token. Paste it into Settings and the server checks the signature against a public key compiled into the binary. That check needs no network at all. It is the same check on every restart, forever. There is no activation call, no license server, no periodic revalidation, and no expiry date to renew.

Take the binary in on a USB stick, paste the key, and it is licensed.

There is no SSO, and one admin account

Central Logging has a single admin user. One email, one password. Sign in through the login page, or use the same credentials as HTTP Basic Auth for curl and scripts.

That is the whole authentication story. No SSO, no SAML, no OIDC, no LDAP, and no per-user roles. Everyone who can sign in sees everything.

If your compliance policy requires named accounts with individual audit trails, this fails that requirement today. Better to know now than after the purchase order. Teams that need it usually put an authenticating reverse proxy in front, which gets you named sign-in but not per-user permissions inside the app.

Two more things to check against your own environment

• Your volume. The design target is under roughly 10GB/day on a single node. There is no clustering and no multi-node failover. Above that, or where HA is mandatory, run something built for it.
• Your network path. Agents reach the server over HTTPS on a port you choose. Confirm the firewall rule between your host subnet and the log server before install day, not during it.

There is a 14-day refund, and the free download is the complete product rather than a trial, so you can test the whole thing on your own network before spending anything.

Getting started on-premise

1. Set up the server — the full walkthrough. Skip the Let’s Encrypt step and use PORT with your own TLS.
2. Install clagent on each host and point it at the internal hostname.
3. Set retention per source to match your policy.
4. Configure backups to internal object storage, or back up cl-data/ directly.
5. Create one alert, and test the notification channel.

Related reading: self-hosted log management covers how the options compare and how to size a server.