"Anonymous" is not the same as "private", and neither is the same as "no-KYC". Anonymity is operational — you cannot be identified as the operator from the available data. Privacy is contractual — the provider commits not to share what they know. No-KYC is a specific subset of anonymity at the signup layer. All three matter; most hosting marketing conflates them. This page separates them, and walks the four layers of VPS anonymity that actually determine your exposure.
Anonymity does not live in one place; it lives in four. Two are the provider's job, two are yours. Cryptoservers handles the first two structurally; the second two require operational discipline that no provider can do for you.
The information collected when you create the relationship: email, name, address, phone, ID document, billing details. Cryptoservers asks for a single field — a working email — and never validates name, address or phone because they are not collected. The signup form is two dropdowns and an email box. Nothing is enriched against third-party databases. This is the no-KYC layer; it is necessary but not sufficient for anonymity.
Every payment leaves a trace somewhere. A card creates a chargeable record at your issuing bank. A bank wire creates a SWIFT log. Bitcoin creates a public UTXO graph. Monero creates an opaque commitment with no source visible. Cryptoservers accepts seven cryptocurrencies; XMR is the only one with protocol-level privacy at the payment layer. BTC, LTC, ETH, BCH, DOGE, DASH are pseudonymous — strong if you use fresh wallets, weak if you withdraw directly from a KYC exchange. We never accept fiat, so card-network surveillance is structurally absent.
Every SSH session and panel login leaves a trace at your end. If you SSH from a residential IP that your home ISP can attribute to you, the network-layer anonymity is gone regardless of what the VPS knows. Cryptoservers does not block Tor or VPN traffic on the deploy form, the panel or the VPS itself; the operational discipline of routing through Tor (Tor-only or Tor → VPN → SSH) is yours to maintain. We do log panel session IPs for 24 hours for brute-force protection — short retention, deliberately limited scope.
The text of support tickets, the contents of abuse reports filed against you, the workload running on the VPS, the public IP your services bind to, and any leaks the workload itself produces (banner strings, login fingerprints, SSL certificates, EXIF data, analytics cookies). Tickets and abuse correspondence are subject to our 90-day retention; the workload's leaks are out of our hands. This is the layer most users underestimate, and the one a determined adversary will go after first.
A flat table of every category of data flowing through a Cryptoservers VPS, and what we do with it. No marketing copy: just three columns — what we see, what we log, what we share.
| Layer | What WE see | What we LOG | What we SHARE |
|---|---|---|---|
| Signup email | The address you submit | Stored on customer record | Only on valid local court order |
| Real name / ID / phone | Nothing — never collected | Nothing — never collected | Cannot share what we never had |
| Ödeme | On-chain tx id, receive address, amount | Invoice line + tx id, 7 yrs (corp law) | Only on valid local court order |
| Panel session IP | Source IP of the login | 24 hours (anti brute-force) | Only on valid local court order |
| Panel actions | Provision / reboot / rebuild / snapshot | 90 days (abuse / security) | Only on valid local court order |
| SSH connection to your VPS | Nothing — terminates inside guest | Nothing — not on host | Cannot share what we don't see |
| Customer NIC traffic | Per-port byte counters only | No netflow, no packet capture | No data exists to share |
| Support tickets | Content you send us | 2 years (service continuity) | Only on valid local court order |
The provider can clean up layers 1 and 2; you have to clean up 3 and 4. Below: the discipline that makes the difference between "anonymous on paper" and "anonymous in practice".
Network discipline:
Wallet discipline:
Email discipline:
Workload discipline:
The honest section. Anonymous VPS is a useful tool with a defined threat model. Below: the threats it does not address. If any of these match your adversary, layer the VPS with the additional defences mentioned.
Global passive adversaries. A global passive adversary (GPA) — typically a signals-intelligence agency with broad network observation capability — can correlate Tor entry and exit timing, deanonymise long-lived flows by traffic-pattern analysis, and link your VPS public IP back through the Tor circuit to your residential ISP under sufficient observation density. Anonymous VPS does nothing to defeat a GPA. Defending against a GPA requires a different toolkit (Tails, mixnets, intermittent connectivity, OPSEC discipline far beyond hosting choice).
Side channels via the workload itself. If the public service running on your anonymous VPS leaks your identity through a login fingerprint, a unique writing style, an embedded analytics tag you forgot to remove, or a single tweet that mentions the IP — anonymity collapses regardless of how clean the VPS purchase was. This is the most common failure mode we see in post-mortem write-ups; the workload is the weakest link.
ISP-level metadata if you SSH in directly. Your home ISP records that you connected to the VPS public IP at this timestamp, this volume, this protocol. Even without packet capture, NetFlow-grade metadata is sufficient to link "VPS A made noise" with "subscriber X was online and connected to A at the same moment". The fix is not to SSH from a home connection: route through Tor or through a VPN you bought separately.
Forensic disk images. A VPS lives on physical hardware in a rack. If the underlying disk is imaged through a court order or hypervisor introspection, anything you stored unencrypted is recoverable. Encrypt sensitive data at rest <em>inside the guest</em> with keys held by you (LUKS, dm-crypt with passphrase prompt at boot, file-level encryption like age or gocryptfs). The anonymity of the VPS purchase does not protect what is on the disk.
Compelled disclosure of email contents. Your signup email, even on Proton or Tutanota, lives at a provider with its own jurisdiction and its own court-order obligations. If that provider is compelled to hand over inbox contents, they would include your Cryptoservers deploy emails (containing the VPS IP). PGP-encrypt mail-at-rest where possible; consider self-hosted mail behind Tor for the highest-paranoia profiles.
Eight questions buyers and journalists ask us most about the anonymity properties of a Cryptoservers VPS.
Threat-model and anonymity references:
Tor Project — How Tor protects your privacy
EFF — Surveillance Self-Defense (full guide)
IETF RFC 6973 — Privacy Considerations for Internet Protocols
IETF RFC 7258 — Pervasive Monitoring Is an Attack
Wikipedia — Anonymity (concept primer)
Five tiers, four jurisdictions, no ID, no phone, optional account, Tor-friendly. Pay in any of seven coins.
