A practical threat model for no-KYC hosting: what the host sees, how to choose email and payment, SSH key hygiene, server opsec, and the limits of anonymity on a VPS.

What “no KYC” means here, concretely

Most hosts ask for a name, a billing address, a phone number and increasingly a scan of your ID before they will give you a root shell. BitVPS asks for one thing: an email address that can receive your access link. There is no account, no password, no profile and no verification step. You choose a plan, pay, and manage the server from a link.

That removes the identity layer, but it is worth being precise about what still exists. For each server we hold: the email address, the plan, location and OS, the paid period, the invoice and how it was settled (coin or card), and the server itself with its IP. The datacenter network we build on sees the server’s traffic as it would for any customer. The rest of this guide is about making each of those items point at nobody in particular, and about being honest on where that stops.

Decide what you are protecting against

Anonymity is a relationship between you and a specific adversary, not a property of a server. Three common cases, in rising order of difficulty:

You do not want a company’s customer database to contain your identity next to a server. Hosting without KYC alone solves this; pay however you like.
You do not want a determined party with legal process to connect a server to you. This requires that the email, the payment and the network path to the server each be unlinked from you. Monero (or Bitcoin from a non-KYC wallet), an alias email and Tor cover it.
You need to withstand a well-resourced adversary who can watch the network at both ends. No single VPS does this. Use the server as one hop behind Tor, keep nothing on it that identifies you, and assume it can be seized.

Pick your case before you order, because it decides whether the extra steps below are worth the friction.

Email: the one thing you must provide

The access link is sent by email, so the address is the only mandatory identifier. Make it one that does not point back at you.

Create a mailbox for this purpose with a privacy-focused provider and sign up for it over Tor. Several such providers run onion services for exactly this reason.
Or use an alias service that forwards to your real mailbox. This hides the address from us but not from the alias provider; fine for the first threat case, not the second.
Avoid your ISP, employer or primary personal address. Avoid addresses containing your name.
Keep the mailbox alive. Expiry reminders and fresh access links go there; if it dies, you lose the easy way back into the server.

Payment: ranked by how little it reveals

Monero (XMR): the blockchain reveals neither sender, recipient nor amount. Pay from your own wallet rather than an exchange withdrawal. This is the right default; the Monero guide walks through the checkout.
Bitcoin (BTC): the blockchain is public forever. It is only as anonymous as the coins’ history. Coins bought peer-to-peer or mined, held in your own wallet and never touched by a KYC exchange, are fine. Coins withdrawn from an exchange account in your name are not, no matter how many hops you add.
Ethereum and Solana: same transparent-ledger caveat as Bitcoin, faster confirmations.
Card: convenient and still accountless on our side, but the card network and processor know who you are. Choose it when you only care about the first threat case.

Order and manage over Tor

Your IP address when ordering is the easiest link to break and the easiest to forget. Open the site through Tor Browser, either on the clearnet domain or at the onion address shown in the footer and in every access-link email. Checkout, payment, the access page, console and reinstall all work over Tor. The companion guide on managing a VPS over Tor covers SSH through the Tor network and giving the server its own onion address for SSH so you never connect to its public IP from your home connection.

SSH keys and first login

Generate a key pair specifically for this server. Reusing your everyday key is a direct link: the same public key appearing in two places ties the two together to anyone who can read either authorized_keys file. Also strip the comment; by default ssh-keygen embeds user@hostname, which is a tidy little identifier that then sits on the server forever.

# On your own machine. Empty comment, strong passphrase, separate file.
ssh-keygen -t ed25519 -C "" -f ~/.ssh/anon_server

# Paste the contents of ~/.ssh/anon_server.pub into the SSH key field at checkout.
cat ~/.ssh/anon_server.pub

# ~/.ssh/config: pin the identity so other keys are never offered to this host.
cat >> ~/.ssh/config <<'EOF'
Host anon
    HostName YOUR.SERVER.IP
    User root
    IdentityFile ~/.ssh/anon_server
    IdentitiesOnly yes
    # Uncomment to connect through Tor (see the Tor guide):
    # ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p
EOF

If you chose a generated password instead, log in once, add your key to /root/.ssh/authorized_keys, confirm key login works, then disable password authentication as shown in the other guides’ server-prep section. A password that travelled by email should not stay valid longer than it has to.

Server hygiene

Hostname and timezone: pick something neutral and set the clock to UTC (timedatectl set-timezone UTC). Hostnames and local time zones leak into logs, email headers and TLS certificates.
Do not log into personal accounts from the server, and do not install tools that phone home with an account identifier. Package mirrors and the OS vendor’s update servers see the server IP; that is expected and harmless.
Keep the server’s job single-purpose. The more unrelated things run on one box, the more one compromise or one mistake connects.
Disk encryption on a VPS protects data at rest against disk images taken after the fact, not against the host while the machine is running, because the key is in RAM. Treat it as useful but not decisive; keep secrets that matter off the server.
Backups and snapshots copy whatever is on disk. If you enable the backups add-on, you are deliberately choosing recoverability over leaving no copies; make that choice knowingly.
Rotate: when a server has done its job, let it expire. A prepaid server that is not extended is deleted at the end of its period, which is a cleaner ending than a long-lived box accumulating history.

Where anonymity stops

Three honest limits. First, the network layer: the hosting network sees traffic volume and destination IPs for every server, as any ISP would. Anonymity about who you are does not make the server’s traffic invisible; use Tor or a VPN on top if the destinations matter. Second, the law: paying without ID does not change what you are allowed to run. The Acceptable Use Policy still applies and abuse reports still lead to termination; anonymity is not a shield for harming others, and we do not pretend otherwise. Third, your own behaviour: most deanonymisation is a correlation someone made between a careful setup and one careless moment, such as checking a personal mailbox from the server or pasting a hostname into a forum. The setup above gets you a server that knows nothing about you; keeping it that way is the ongoing part.

Which plan to pick

Anonymity costs nothing extra: every plan is accountless and accepts every payment method. For a VPN endpoint, onion service, chat relay or small web app, the entry plans (2 vCPU, 4 GB RAM, 40 GB NVMe from about $10/mo) are the usual choice, and a jurisdiction you are comfortable with (Germany, Finland, the US or Singapore) is selectable per server. Configure a server, choose Monero and a fresh email, and the access link arrives once the payment confirms.

Anonymous VPS without KYC: what it actually hides, what it does not, and how to set one up properly