Loghound is self-hosted. There is no Loghound company, no telemetry and no vendor with a copy of your traffic — which makes almost every privacy question here your decision rather than the software’s. This page says exactly what is collected so you can make it.
| Destination | What is sent | Turn it off with |
|---|---|---|
| Geolocation lookup | Visitor addresses, plus your account email and API key so the platform knows whose lookup it is | the geo switch |
| Network lookup | Visitor addresses | the ASN switch |
| Registry whois | Visitor addresses | the whois switch |
| Your DNS resolver | Visitor addresses, for reverse lookups | the reverse DNS switch |
| Your two Opensolr indexes | Everything Loghound stores — every hit and session document | cannot be turned off |
| The Opensolr platform API | Your account email and API key, and the index names being created or checked. No visitor data. Only during setup, and afterwards for the credential check and the plan figures | cannot be turned off |
Loghound provisions and manages them and cannot do that on a Solr it does not administer, so an account is a hard requirement and your log-derived data leaves your machine for Opensolr’s infrastructure. That is a processor relationship and you should treat it as one in your records.
With all four enrichers off, no visitor address leaves the machine for anywhere but your own indexes. Loghound still works: it loses geography, network data and reverse DNS, which costs you the Networks view and three of the seventeen rules — the timezone mismatch, the datacentre-plus-browser one and the reverse DNS claim check. Everything on the behavioural and execution planes is unaffected. The strongest posture available is all four off plus hashed addresses.
Figure 1 — everything that leaves the machine, in one picture. The two destinations on the right cannot be switched off; the four on the top can, each on its own.
| Full (default) | Truncated | Hashed | |
|---|---|---|---|
| Bot detection quality | best | good | reduced |
| Geography, network, reverse DNS | yes | yes | no |
| Following a person across days | possible | partly | no |
| Abuse reporting | yes | approximately | no |
| Personal data under GDPR? | yes | pseudonymised | pseudonymised, strongly |
- Full is the default because you already have the raw address in your own access logs, indefinitely, by default. Loghound storing it changes your exposure far less than people assume — the liability was already sitting in your log directory.
- Truncated zeroes the host part. A defensible middle ground, widely accepted as pseudonymisation. Note the detection cost: the fingerprint rule counts distinct addresses, so truncation merges a fleet’s exits that share a range and can push it below the threshold — and merges unrelated people, which pushes the other way. Expect noisier verdicts.
- Hashed, with the salt rotating daily, makes following an individual across days impossible while keeping same-day sessions working. It loses geography, network data and reverse DNS entirely, because there is no address left to look up. The salt is the whole protection — without it the address space is small enough to brute force in seconds, so treat it like a password.
Changing the mode affects new documents only. It does not rewrite history.
- No session replay. No page recording, no mouse-path recording, no screen capture, and no plan to add one.
- No keystrokes, no form values, no clipboard. The beacon counts key-press events; it never looks at which key.
- No page content. Loghound never reads the body of your pages.
- No cross-site tracking. No shared identifier, no third-party domain, no cookie sync, nothing to join against.
- No cookies set by the beacon, at all, by default. The visitor identifier is a derived hash, documented as such rather than presented as anonymous. The panel sets one session cookie for your administrators.
- No query strings, except parameters you name yourself.
- No mouse coordinates on the wire. Up to sixteen are sampled into memory purely to answer one question — do three consecutive points fall on an exactly straight line — and only the verdict leaves the browser.
- No telemetry to the project. There is nothing to send it to.
If your application puts anything identifying in a URL — an address in a query string, a password reset token, an order number, a document name — it is already in your access log, and Loghound will index it and make it searchable. That is not a change Loghound introduces, but it does make it much easier to find. Check what your URLs contain before you index a year of them.
The same applies, more sharply, to the option that stores the complete original log line. It roughly doubles the index and keeps a full copy of every request line including anything sensitive in it — turn it off unless you actually need to re-score history under a future ruleset.
Not legal advice. Written by an engineer so your lawyer has something accurate to read.
- Roles. You are the controller. Loghound is software, not a service, and there is no Loghound entity that processes anything. Opensolr is a processor and you need the usual paperwork with them.
- Lawful basis. Server-log analytics is commonly run under legitimate interest, and that is easier to argue here than for most analytics: it processes logs you already generate and already keep, it sets no cookies and does no cross-site tracking so there is nothing to join against, and a substantial part of its purpose is security. Do a legitimate interests assessment and write it down.
- Cookie banner. The beacon by default stores nothing on the device — no cookie, no local storage. On the common reading that means no consent banner is required for it. This is a genuinely contested area and national regulators differ; check your own jurisdiction.
- Data minimisation. Choose the address mode and retention window you can justify, not the maximum the software allows.
- Automated decision-making. Loghound classifies traffic; it does not act on it. If you wire a verdict into something that blocks people, that is your automated decision — and the reason codes exist partly so such a decision can be explained, which is a legal requirement as well as good engineering.
Data subject requests
Access and erasure by address are only possible in full or truncated mode; in hashed mode you cannot identify the subject’s records, which is by design and is worth saying in your response. Do the log files first — Loghound is downstream of them, and deleting from the index while the original line is still on disk means it comes back the next time you replay.
There is no per-visitor opt-out. The practical answer is to exclude the requester’s address at the source, with a condition in your web server that stops the line being written at all.
Adapt it; do not paste it without reading it against your actual configuration.
Server logs and analytics
We analyse our own web server logs to understand how this site is used and to detect automated abuse. This is done with self-hosted software running on our own infrastructure. We do not use any third-party analytics service, and we do not sell or share this data.
What we record. For each request: the address, the date and time, the page requested, the status and size, the browser’s User-Agent string, the referring page, and a small number of standard request headers.
A small script on our pages measures how long a page was actually visible and whether it was being interacted with, so that we can tell real reading time from a tab left open in the background. It also runs technical checks that help us identify automated traffic. It sets no cookies and stores nothing on your device. It does not record what you type, what you click on, your mouse movements, or the contents of any page.
Addresses. [Choose: we store them in full and use them to identify and block abuse / we shorten them before storing so they identify a network rather than a device / we do not store them, they are replaced with an irreversible code that changes daily.]
How long we keep it. [N] days, after which it is automatically deleted. We keep anonymous daily totals for longer.
Third parties. [Choose: addresses are sent to a geolocation and network-lookup service to determine the approximate country and network operator, and no other data is shared / no data is shared with any third party.]
Your rights. You can ask what we hold about you and ask us to delete it. Please note that if we do not store addresses in an identifiable form, we may not be able to locate records relating to you.
If you switch to hashed addresses, say so — it is a real commitment and it is worth the credit. If you turn enrichment off entirely, say that too: “no visitor data leaves our servers for a third party” is a strong and true claim in that configuration, and very few analytics setups can make it.