Logging posture

Exactly what we store. And what we don’t.

We log the minimum needed to bill you correctly and handle abuse reports. We deliberately don’t log anything else, because anything we don’t have is something nobody can compel us to hand over.

What’s in the database

For each session, the control plane stores:

• A session id (opaque, surfaces in your invoice).
• The region you connected to.
• The exit public_ip you appeared as.
• The peer WireGuard public key your CLI generated (so we can re-key for handoffs).
• created_at and (once ended) terminated_at / terminated_reason timestamps.
• Cumulative bytes_in and bytes_out, updated from the node agent in batches.
• The account or anonymous-token this session belongs to.

For each account: email (free / paid), Stripe customer id (paid), creation timestamp.

For each anonymous token: install fingerprint hash, ASN at issuance, issuance timestamp.

That’s it. Per-session data is retained for 90 days for abuse-response purposes, then deleted. Per-account billing records are kept as long as German tax law requires (10 years for invoices).

What we explicitly do not log

• Packet contents. No DPI, no TLS interception, no any-of-that. Most of your traffic is TLS to a destination we can’t see anyway, but for the plain-HTTP minority we still don’t look.
• Destination IPs or hostnames. We don’t record where your traffic goes, ever.
• DNS lookups. Your DNS goes through the tunnel and we don’t log it. (Anonymous-tier DNS is filtered against a known-malicious-domains list at the resolver level; the lookups themselves still aren’t logged.)
• Browser fingerprints, user agents, request headers. None of this is visible to us - the WireGuard tunnel is transport-layer.

Telemetry

The CLI itself does not phone home with telemetry. Versions of the binary do not check for updates. Crashes are not reported.

The only network requests the CLI makes during normal operation are:

1. POST /v1/tokens/* during install (token issuance).
2. POST /v1/sessions and GET /v1/sessions/{id} during a tunnel.
3. GET /v1/regions for the region picker.
4. The WireGuard handshake itself, to the exit node.
5. GET https://ipapi.co/json/ for geo-auto-pick (no API key, no token; a single IP-only request). Opt out with --region.

That’s the full network surface of tunnelbyte. You can tcpdump it.

What we publish

The IP-attribution endpoint at tunnelbyte.dev/ip/<addr> is the only data we make publicly queryable about our infrastructure. It tells you which IPs are ours and where to send abuse reports. It does not tell you who is using a given exit IP, because we don’t surface that and wouldn’t even if we could.

Trust signals you can verify yourself

• tcpdump the CLI. The five outbound requests under “Telemetry” above are the entire network footprint. No analytics, no update pings, no crash reporting. If you see anything else, file an issue at [e-mail].
• The exit-IP list is public. Every IP we route traffic through resolves at tunnelbyte.dev/ip with the region and abuse contact. If an IP isn’t on that page, it isn’t ours.
• Account deletion is real. Email [e-mail] to delete an account. Within 24 hours: account row dropped, anonymous tokens revoked, session metadata anonymised (we keep the per-session byte/duration totals for billing reconciliation, but no link back to you). German tax law obliges us to keep paid-tier invoice records for 10 years; everything else is gone.
• Exit nodes are spread across multiple independent VPS providers so no single one carries more than ~40% of the data plane. The current provider and region for any given exit IP is shown at tunnelbyte.dev/ip.
• Nightly Postgres dumps are end-to-end encrypted with age (X25519 + ChaCha20-Poly1305) before they touch our R2 backup bucket. The age private key lives offline; only the public recipient sits on the control plane host. A leaked R2 key alone cannot decrypt a backup.
• Inbound webhooks are deduplicated by event id in a journal table, so a replayed or reordered delivery from the payment provider cannot flip your account state.
• See Security for the apt repo signing key fingerprint and the install verification flow.

Legal

We comply with valid orders from German courts.

We don’t have a “law enforcement portal.” Requests come to [e-mail] and get forwarded to legal counsel.

Because we don’t log destinations or packet contents, the most we can hand over in response to any order is: “this account was active during this window, used these exit IPs, transferred this much data.” That’s it. We can’t hand over what you were doing on the other side of the tunnel, because we don’t have it.

See also

• Abuse policy - how we act on the data we do have.
• Security - signing keys + the install verification flow.