What We Log
What we log
This page states exactly what the VPN service records. It is deliberately short, specific, and written so that every claim in it can be checked against our infrastructure rather than taken on trust.
The claim, in one line: we keep no activity logs.
We do not record which websites you visit, which DNS names you look up, what you download, or who you talk to. We do not keep a record of when you connected.
We are equally precise about what we do hold, because “we keep no logs” is only meaningful when the exceptions are named.
What we do not keep
| Your browsing history | Not recorded. |
| The DNS names you resolve | Not recorded — on any tier. The resolver that answers you runs with its query log disabled and its statistics disabled. |
| Your traffic content | Encrypted end to end. We carry it; we cannot read it. |
| Your original IP address | We do not store your ISP-assigned address in connection with your account. |
| Connection times / session records | We do not keep a record of when you connected or disconnected. |
| Your device’s real network | Not recorded. |
What we do keep
Some data is unavoidable: you pay us, and you have an account.
| Data | Why it exists | Retention |
|---|---|---|
| Email address, password hash | Your account; you cannot log in without it | Life of the account |
| Subscription and payment record | Billing. Card details are handled by Stripe and never reach us | Life of the account |
| Device records — device name, tier, the tunnel IP we assigned you, your public key | Required to provision and revoke your access. This is configuration, not activity | Life of the account |
| Aggregate data-volume counters | Used to keep the service fast and fair (see fair use in our terms) and to stop abuse. These are byte counts only — they contain no destinations, no DNS and no browsing information | At most 90 days, per device |
| Speed-test results you run yourself | A throughput measurement you start from the portal: the two rates, the byte counts, the latency, and which of your own devices you labelled the test with. It is the result that was on your screen, and nothing about the transfer behind it | Five newest, per account |
On the last row. The counters show how much you transferred, not what. A byte total cannot be turned back into a browsing history, and it is never combined with destination data because we do not have any. We disclose it here because a policy that hides a meter is worse than one that explains it.
On the speed test. The portal’s throughput probe keeps the result it just showed you — the numbers, the time you ran it, and which of your own devices you labelled it with — because a history is the point of the page. It keeps the five newest tests per account and prunes older ones as new ones arrive. It keeps nothing about the transfer behind those numbers: no address at either end, no destination, and nothing you did outside that test. Whether a test ran over the tunnel is decided on our side from the address the traffic arrived from, not from anything the browser claims about itself. The page states all of this before you press the button, and the two tables on this page remain the complete list of what exists afterwards.
Server logs
Our servers produce ordinary operating-system logs — service starts and stops, crashes, errors, deployment records. These are:
- kept for 14 days in our central log store, and at most 30 days on the server that produced them;
- never contain customer traffic or DNS data;
- asserted to contain no client-tier addresses by the automated audit below.
No store anywhere in our infrastructure keeps anything longer than 90 days, and nothing attributable to you is kept longer than 30 days — the per-device byte counters above, the local copies of these logs, and the encrypted backups all stop there. Only measurements about our own machines (their uptime, and the audit’s own dated reports) sit at that 90-day ceiling.
How you can verify this
You do not have to take our word for it:
- Our infrastructure is declarative and its configuration is public. The servers are built from version-controlled source; the relevant parts are published at git.ymrtech.com. Nothing is hand-configured on a running machine.
- The no-log property is tested, not promised. The service continuously asserts its own behaviour: a real DNS query is sent through each resolver and then the system checks that nothing was written. If a log ever appears, the check fails and the change is rejected — it cannot reach production silently.
- We publish an audit. A scheduled job verifies the configuration of every resolver, signs the result, and publishes it. The current report, and the history behind it, is at the audit page.
When we are forced to hand something over
We can only disclose what we hold, and we hold what is listed above. We cannot produce browsing history, DNS records, or connection logs, because they do not exist.
We will:
- notify the affected account unless legally prohibited from doing so;
- publish a warrant canary — a signed statement, periodically renewed, at a stable address — recording how many demands we have received.
(The canary is being added alongside the audit.)
What we cannot protect you from
The same limit applies here. A VPN hides your traffic from your network provider. It does not protect you from:
- malware on your own device;
- logging in to an account that knows who you are;
- a browser using its own DNS (DNS-over-HTTPS) in a way your device does not route through the tunnel — our privacy tier exists to prevent that, and the portal includes a leak test;
- anything you do after you disconnect.
Changes
If this page ever changes in a way that expands what we collect, the change will be described here, in the public configuration history, and — where the change touches the no-log invariants themselves — it will show up as a change in the signed daily audit rather than only in prose. It will not be made quietly. The audit’s own generator is not public source; the boundary and what it costs you are described on the audit page.
- 2026-09-19 — the portal’s throughput probe. Added a speed test at
/account/speed-test, and its row to What we do keep above. It stores the five newest results per account — two rates, byte counts, latency, and the device you labelled the test with — and nothing about the transfer itself. No invariant changed: no address, no destination and no activity record is written, and the byte counts it holds are the class already disclosed.
Contact: yannick@ymrtech.com