VPSRENTO
No-KYC hosting: a wallet is the only ID you will need.
No email. No name. No phone. Your VPSRento account is a 24-character access token, shown once and stored as a hash. There is no customer database to breach, subpoena, or sell — because there are no customers’ identities to put in one.
- No email field exists
- Token shown once, stored hashed
- Zero identities since 2021
Why every other host wants to know who you are
Identity collection at a mainstream host is rarely about the law. It is about the payment rails. Card networks require merchants to perform fraud screening, and fraud screening at scale means knowing the customer: name, billing address, phone number, a verified email. The host passes that requirement down to you at signup, not because a VPS needs an owner’s passport to boot, but because Visa’s risk model wants a human attached to every chargeback.
Then the data stays. What begins as fraud screening becomes a marketing asset — the newsletter list, the “win-back” campaign, the upsell funnel. Your email sits in a CRM next to your invoices, your support tickets, your login IPs, and the list of services you run. Over the years that table becomes the single most complete record of your infrastructure that exists anywhere, written entirely by you, stored by a company whose business is servers, not secrets.
And it becomes a liability with a timer on it. Every year, another provider’s customer table appears on a forum: names, addresses, password hashes, partial cards. Breaches are a statistical certainty given enough databases and enough years. Worse, the data does not need to be stolen to leave the building — a subpoena works just as well, and a KYC host’s first move under legal pressure is to hand over the file it so carefully built.
VPSRento was founded by people who watched this happen from the inside. Our position is architectural, not rhetorical: data that was never collected cannot be breached, sold, leaked, or compelled. The most secure customer database is the one that was never created. That is why the signup form on this site has no fields for who you are — only a decision about what you want to run, and a token at the end of it.
The token account: authentication without identity
An account is supposed to prove that the person returning is the person who paid. Mainstream hosts solve this by collecting your identity. We solve it the way cryptography solves everything else: with a secret only you hold.
Deploy and pay
Pick a plan, a location, an OS. Pay with crypto-only payments. No registration form appears at any point — there is nothing to fill in about you.
Receive your token
The success screen shows your 24-character access token exactly once. We store only its SHA-256 hash. Screenshot it, write it down, treat it like a seed phrase.
Generate sub-tokens
First stop in the client area: settings. Mint a sub-token per device or per use — laptop, automation, read-only monitoring — and store the master offline.
The token looks like this. It is the whole account — the login page is a single field, and pasting it is the entire sign-in ceremony. No password manager entry with your email attached, no reset link, no “verify it’s you” flow that quietly harvests your phone number.
Because we store a hash rather than the token itself, even a full read of our database yields nothing an attacker can log in with. And because the token carries no identity, the account it unlocks contains nothing about who holds it. Authentication without identification. That is the entire trick, and it took the industry twenty years to notice it was possible.
Sub-tokens are scoped. Mint one that can only read service status for your monitoring, one that can only open tickets, one with billing access for your accountant. Lose a device, revoke one sub-token. The master never leaves your password manager.
A breach at a KYC host vs. a breach at VPSRento
Assume the worst: the provider’s database is dumped in full, tonight. Here is what an attacker — or a litigant, or a three-letter agency — walks away with in each case. This is the honest arithmetic behind everything we build.
| Data point | Typical KYC host | VPSRento |
|---|---|---|
| Legal name | Stored — breachable, subpoena-able | Never collected |
| Home / billing address | Stored with every invoice | Never collected |
| Passport / ID scan | Often required for “verification” | Never collected |
| Email address | Login identifier, marketing list | Field does not exist |
| Phone number | “For your security” (2FA pretext) | Field does not exist |
| Card number / bank details | Tokenized but tied to your name | No card rails exist |
| Payment history | Card statements naming the host | Public txids — the blockchain already shows them |
| Account credentials | Email + password hash, resettable by support | SHA-256 of a token — unrecoverable even by us |
| Activity / connection logs | Retention varies by policy and law | Not written in the first place |
Read the right column again. It is not a promise about what we would do under pressure — promises are what KYC hosts make before folding. It is a description of what physically exists on our disks. A court order compelling disclosure of “all customer identifying information” at VPSRento returns a token hash and a list of public transaction IDs. That is not defiance. It is inventory.
This is also why we can run an abuse desk that takes privacy seriously without contradiction. The AUP is enforced against services — spam sources, botnets, attackers — using network telemetry and complaint evidence, not customer files. We do not need to know who you are to know what a server is doing. Five years in, the system has never required an identity to keep the network clean.
What no-KYC costs you
Every design has a price, and hosts that pretend otherwise are lying about something else too. Ours has three, and you should know them before you deploy.
No recovery. Ever.
Lose your token and every sub-token, and the account is gone. We store only a hash, so there is nothing to verify you against — no support agent can “look you up.” We can’t reset what we never knew. This is the feature working as designed, and it will still hurt if it happens to you.
No renewal reminders
We have no email address to warn you at. Expiry dates are shown prominently in the client area, invoices appear there before they are due, and the credit balance can auto-cover renewals — but the habit of checking is yours. Set a calendar reminder the day you deploy.
The token is the keys
Anyone holding your master token holds your infrastructure. Store it like a crypto seed phrase, not like a password: offline backup, sub-tokens for daily use, TOTP 2FA on top. The settings page also shows active sessions — check it the way you would check a bank statement.
Day-one ritual, thirty seconds: deploy → store the master token in your password manager → open Settings → mint one sub-token per device → enable TOTP. Do that, and the tradeoffs above shrink to a rounding error. Skip it, and no privacy architecture on earth will save you from yourself.
Infrastructure that never learns your name
Every plan ships with the same account model: a token, a hash, and nothing else. Standard-tier locations from $5.99/mo.
Iceland +15% · Switzerland +20%. Full specs on the VPS page · test first on the hourly sandbox at $0.009/hr.
Accounts the way they should work
“Token login felt weird for a day. Now the idea of a password reset email feels insane. This is how accounts should work.”
“Migrated 40 boxes from Hetzner after the second identity request. Deploy times are faster and nobody has asked me who I am in four years.”
Frequently asked questions
Identity & access
Correct. There is no signup form: no email field, no name field, no phone field. You configure a server, pay the crypto invoice, and receive a 24-character access token. That token is the account. In five years of operation we have never asked a customer who they are, and the privacy policy lists everything we store — it fits in a paragraph.
You don’t — and that is deliberate. We store only the token’s hash, so there is nothing to verify a recovery request against. The mitigation is preparation: on day one, generate a sub-token in settings and store the two in separate places. Thirty seconds of setup removes the single biggest risk of the model.
Sub-tokens are scoped credentials minted from your account: one for your laptop, one for automation scripts, a read-only one for monitoring, a billing-scoped one for whoever pays your invoices. Each can be revoked independently. The rule of thumb: the master token lives in your password manager and never touches a terminal; sub-tokens do the daily work.
We can discuss any invoice or transaction you reference, and confirm whether a token you paste is valid. What we cannot do is bypass a lost token, because the person asking could be anyone — that is precisely the attack this model exists to stop. Treat the token like a seed phrase, because operationally, it is one.
Open an account nobody can tie to you.
No form, no email, no password. A token, a payment, and root in 55 seconds.