Why ForestVPN keeps no logs — and how we prove it
A no-logs VPN is only as honest as the line it holds. Here is ours — no destinations, no DNS, no traffic content — and the engineering that makes it true.
George Kutsurua
- privacy
- security
- engineering
A VPN sits in the most sensitive position on the internet: every byte you send passes through it. That position is exactly why a VPN's privacy promise has to be structural, not aspirational — and why it has to be precise. The safest data is the data we never collect, so ForestVPN is built so there is nothing that could reconstruct where you went or what you did.
What "no logs" actually means
People mean very different things by "no logs", and the honest version is a line, not a slogan. Ours is the same one written into our Privacy Policy: we never log where to or what. No browsing history, no DNS queries, no contents of your traffic, and none of the destination IP addresses, ports, hosts, or domains you connect to. There is no timestamped record that could be used to reconstruct your activity. The default is absence of the one thing that would matter — the record of where you went — and that absence is enforced in the code paths that handle a tunnel, not in a policy document.
Privacy isn't a setting you toggle on. It's the default we build around. We'd rather draw one clear line and hold it than promise everything and explain later.
How the tunnel forgets
Our data plane handles a packet and then forgets it. There is no per-flow audit trail written to disk: the exit node never records the source or destination of the traffic it forwards. Conceptually, the hot path looks like this:
// The exit node never persists per-flow detail. It forwards and forgets:
function handlePacket(pkt: Packet): void {
const peer = resolvePeer(pkt.publicKey); // in-memory, from the live config
forward(pkt, peer.endpoint); // encrypt + send — no write to disk
// no logger.info(pkt.srcIp, pkt.dstIp): there is intentionally no such line
}The point of the missing line is the whole post. A destination we never write down cannot be subpoenaed, leaked, or sold.
What we do keep — and why
Running a global network is not free of bookkeeping, and we would rather be exact about that than hide behind the word "aggregate". To route your traffic, enforce plan limits, and bill metered plans, we keep a small amount of connection metadata — the how much, which region, and when of a session, never the where to or what:
| What we keep | What it records | Where to / what? |
|---|---|---|
| Byte/packet counters | How much you transferred, by region | No |
| Session start + duration | When a session ran, and for how long | No |
| Device record | Device name, platform, last-seen, region | No |
| Connection metadata | Direct-vs-relay and region, to route/secure | No |
These records are tied to your account and device — that is what makes them a usage meter we can bill and rate-limit against, not an anonymous stat. What they never contain is a destination: the connection-metadata table simply has no column for a hostname, a domain, a DNS query, or the address you reached. It can tell us the tunnel carried 2 GB through the Frankfurt region this month; it can never tell us who you talked to. Raw counters are deleted after 90 days.
The line we hold
- No browsing history, and no DNS queries
- No contents of your traffic
- No destination IP addresses, ports, hosts, or domains
- No timestamped record that reconstructs where you went
You don't have to take a paragraph's word for it — the same line is written plainly in our Privacy Policy, reviewed by counsel, and the architecture is built so the easy path is also the private one. We keep the accounting a network needs to run; we never keep the record of where you went or what you did.