No-Logs VPS for Tor Workloads

We do not retain packet captures of tenant traffic. There is no pcap archive for any VPS plan in our catalog, and we do not have a TAP infrastructure that could be enabled retroactively to capture historical traffic. We do not retain netflow records of tenant connections; netflow is enabled at the edge for live operational monitoring of platform-wide congestion and DDoS triage, and the records are flushed continuously rather than archived. We do not retain DNS queries that tenants resolve through the platform resolver; the resolver is recursive, not logging.

We do retain account-level metadata that is necessary to operate the platform. This includes the email address on file, the crypto transaction hashes for invoices, the VPS provisioning record that includes the assigned IP and resource limits, and the live syslog of the host node that tracks events such as VPS start, stop, snapshot and migration. None of this metadata includes tenant traffic content. The provisioning record is retained for the life of the account; the host syslog is rotated on a 30-day cycle.

We do not retain access logs for the tenant control panel beyond the active session lifetime. Once a session closes, the panel-side access log entry is purged. This applies to standard login flows and to API token usage. We do retain the IP address from which a session was opened for the duration of that session for security purposes (anti-hijack), but the address is not archived after session close.

A Tor middle relay produces no observable abuse signal at the host level because the originating IP is never exposed to clearnet destinations. The relevant retention question is whether the host could reconstruct the relay's circuit history. Our answer is no: we do not capture packets and we do not archive netflow. The only traffic-derived data point that exists on the host is real-time bandwidth counters for the VPS interface, which are not retained as historical series.

A Tor exit relay produces a continuous abuse stream that the host must triage. The retention question here is whether the host retains the abuse-triage data after the complaint is processed. Our practice is to retain abuse complaints with the associated timestamp and destination IP for 90 days for operational continuity reasons, and to share the relevant excerpt with the exit operator on every forward. After 90 days the complaint record is purged. The traffic itself was never captured.

An onion hidden service has the strictest retention requirement because any retention by the host could be used to correlate onion traffic with the underlying VPS. Our position is identical: no packet capture, no netflow archive, no DNS log. The onion service operator's hardening responsibilities at the application layer (no clearnet egress, no leaky web server defaults, no timezone-revealing timestamps) remain entirely under the operator's control. We do not introduce a retention dependency that the operator cannot mitigate.

A no-log claim is only as strong as the operator's ability to verify it under adversarial conditions. The most important verification path is observed behaviour under legal process. We publish a transparency posture: when we receive a legal request for a specific account or VPS, we comply within the bounds of the request under our host jurisdiction. The data we can provide is limited to what we retain, which is the account metadata described above. We have never been able to provide traffic content or historical netflow because that data does not exist.

We notify the affected operator of legal requests to the extent permitted by the requesting authority and the host jurisdiction. In Iceland and Romania this notification window is generally compatible with practical operator response. In specific cases where notification is prohibited, we comply with the prohibition and document the case in the transparency report after the prohibition lifts.

The most direct verification an operator can perform is to spin up a test VPS, generate distinctive traffic patterns, then submit a request through legal counsel to enumerate everything the host retains about the test account. Several operators in our customer base have done this kind of verification and the result has been consistent with the posture described here. Verification is not a substitute for trust, but it is the discipline that converts a no-log claim into a no-log practice.