Skip to content
TLDBunker

Transparency

No-logs policy

The short answer

We are not a “zero logs” absolutist. We keep the operational minimum needed to run and bill an active service — the current order-to-subaddress mapping, current service state, and aggregate infrastructure metrics — and nothing that ties your identity to what you do. Because Monero is native, we never hold payment identity in the first place.

Version 1.0 — last updated 2026-07-14

Versioned in public Git

This is not a marketing paragraph we can rewrite silently. The full policy lives as a text file in our public repository, so every change is a timestamped commit with a readable diff. If you want to know what we keep, read the file — and its history — rather than take our word for it. See the transparency report for a summary of material changes.

Most “no-logs” claims are marketing. A server that boots, accepts payments, routes packets and renews subscriptions cannot literally record nothing — so a provider that swears it logs zero is either misusing the word or hoping you will not ask. We would rather be precise. This page states the operational minimum we retain to run and bill an active service, the things we deliberately do not keep, and how you can check both.

The design principle is simple: data we never collect cannot be logged, leaked, subpoenaed or sold. So the honest question is not “do you keep logs?” but “what is the smallest set of records that lets the service function, and does any of it tie your identity to your activity?” The answer to the second half is no.

1. What we keep, why, and for how long

We hold a narrow set of records, and almost all of it is current-state data — the facts needed to keep a running service running — not a historical trail. Retention windows below are marked pending a joint operations-and-legal review; they will be filled in with concrete durations before launch and versioned like everything else.

What we keep Why it is necessary How long
Order ↔ subaddress / payment mapping Reconciles your Monero (or BTCPay) payment with the right service so renewals and top-ups work. While the service is active, then purged
Current service state Which plan is provisioned, its region and status (active, suspended, expiring), so the panel and the hypervisor agree. Life of the service
Aggregate infrastructure metrics Capacity planning and abuse detection at the fleet level — CPU, bandwidth and error rates, not tied to an account. Aggregated / rolled up
Transient connection data (edge & panel) Rate-limiting, DDoS and abuse mitigation at the moment a request arrives. Short-lived, then discarded

Notice what unites this list: it is the mapping and state required to operate the thing you paid for. The order-to-subaddress link exists so your renewal lands on the correct server, not so we can profile you — and because Monero is native to checkout, that mapping points at an on-chain payment with no sender identity attached, not at a name, card or bank account.

2. What we do not keep

The following are not retention gaps we are hoping to close — they are deliberate absences. We do not build the pipelines that would collect them, because the safest record is the one that never exists.

  • No identity-to-activity logs. Nothing on our side links “who you are” to “what you did” — because we never asked who you are. Signup is a 32-character random order ID, with no name, no email and no ID document required.
  • No long-term visitor IP logs. We keep no durable log of the IP addresses you connect from tied to your account. Transient edge data used for abuse mitigation is purged after a short window, and the panel is reachable over .onion so you can manage a service without presenting an IP at all.
  • No payment identity. There is no card number, billing address, bank reference or KYC dossier — none is ever collected. Monero payments carry no sender identity we could store even if we wanted to.
  • No inspection of what you run. Your VPS is yours. We do not log the contents of your disk, your network payloads, your process list or your command history. Fleet metrics are aggregate, not per-tenant packet capture.
  • No behavioural or marketing tracking. No advertising pixels, no cross-site profiling, no selling of anything to anyone.

Honesty over absolutism

We are a privacy host with a published Acceptable Use Policy and a real abuse desk — not a “bulletproof” host and not an immunity service. When we say we cannot hand over data that identifies you, it is because that data does not exist, not because we would refuse a lawful order. What little we can produce, and how often we are asked, is counted in the transparency report.

How to verify this

Read the policy file and its commit history in our public Git repository; the version and date at the top of this page correspond to a specific commit. Cross-check it against the numbers in the transparency report, and against the payment model described on how to pay with Monero. If a claim on this page is not something you can independently confirm, treat it as marketing and tell us — that is the standard we hold ourselves to, and it is why we disclose the whole network of sites up front.

Version history

Version 1.0 — 2026-07-14. Initial published policy. Subsequent revisions are tracked as commits in public Git; this page reflects the latest committed version.

Frequently asked questions

Do you keep any logs at all?

Yes — and any host that claims otherwise is not being honest. We keep the minimum needed to operate and bill an active service: the current order-to-subaddress mapping, current service state, and aggregate infrastructure metrics. We do not keep records that link your identity to your activity.

Do you log my IP address?

Not as a long-term identity record. Edge and panel components hold transient connection data for abuse mitigation and are purged after a short window. We keep no long-lived visitor IP log tied to an account, and you can reach the panel over our .onion to avoid presenting an IP at all.

Can you link my Monero payment back to my server?

While a service is active we hold the mapping between your order ID and the Monero subaddress that funded it, because that is how renewals reconcile. Monero itself reveals no sender identity, so there is no name, card, or bank record to hand over — only an on-chain payment we cannot deanonymise.

How do I know this policy has not quietly changed?

The full text is versioned in our public Git repository. Every edit is a commit with a timestamp and a diff, so you can read the exact history rather than trust a single “last updated” date. Material changes are also summarised in the transparency report.

What happens to what little you keep if you receive a legal request?

We can only ever produce what actually exists — which, by design, is close to nothing that identifies you. We answer legitimate legal process without exposing customer data beyond what the law compels, and we count such requests in the transparency report. We are a privacy host with an AUP and an abuse desk, not a bulletproof host.

Run infrastructure on a host that keeps less

A 32-character ID, a Monero payment, and a policy you can read in Git line by line.