Anonymous Windows RDP & GPU Servers for AI: Checklist

People search for “anonymous RDP” and “anonymous GPU server” for different reasons: a Windows desktop in another country without a passport scan, or an open-weight model whose prompts never touch a third-party API. Many want both.

This guide covers how to choose between Windows RDP and a GPU server, what to do in the first hour on each, and a privacy checklist you can work through before you put anything important on the machine. It is written around what MercureHosting actually sells, so the plan names, prices and limits below are the real ones.

What “anonymous” means here (and what it doesn't)

On our side, “anonymous” means a no-KYC checkout. We don't ask for a government ID, a selfie, a phone number or a proof of address. You create an account with an email address you control, top up a balance in cryptocurrency, and order. There is no card on file because we don't take cards.

It does not mean nobody knows anything. The privacy policy lists what we keep: your contact method, order records, payment references (invoice, receive address, transaction id), the server's assigned IPs, resource usage and power state, short-lived edge security logs, and any support mail you send. We don't log your server's traffic or its contents.

Three things outside our control matter just as much:

• The blockchain. Bitcoin, Ethereum, USDT and the other coins we accept sit on public ledgers. If the wallet you pay from is tied to an exchange account in your name, the payment is traceable to you no matter what our checkout asks.
• Your connection. Whatever IP address you use to reach the server is visible to the server, and to anyone watching that link.
• What you install. Signing into personal accounts, syncing a browser profile or activating software with your real identity undoes the separation you paid for.

RDP, GPU, or both?

The two products solve different problems, and the most common mistake is buying the wrong one.

When Windows RDP is the right tool

Windows RDP is a full Windows desktop with administrator rights, reached over Remote Desktop. It suits:

• Windows-only software: trading terminals, desktop office suites, testing tools, legacy line-of-business apps.
• A clean browser environment that exits from a specific country.
• A remote workstation you reach from a laptop or tablet, so the work stays on the server rather than on the device you carry.

Our RDP plans come in three sizes, and the Windows licence is included in the price:

RDP is available in all seven countries. Prices start at $18/month for Desk in Moldova or Russia and vary by location; the RDP catalog shows each one. Desk is a light desktop, Studio is the usual pick for daily work, and Office is for heavier local applications.

What RDP plans don't have is a GPU. They are fine for a small CPU-only script, but anything that needs CUDA belongs on a GPU server.

When you need a GPU server

GPU servers are Linux machines with one dedicated card passed through to your server. It is not a shared slice or a preemptible hourly instance. CUDA, drivers and JupyterLab are available from first boot, and SSH is the normal way in.

GPU plans are offered in Iceland, Romania, Switzerland and the Netherlands. Switzerland is priced about 12% above the other three. Panama, Moldova and Russia don't have GPU plans. Prepaying 3, 6 or 12 months lowers the effective monthly price by 25%, 35% or 50%.

When to run both

A pattern that works well: a Studio RDP desktop where you keep your editor, browser and notes, plus a GPU server in the same country that you reach over SSH from that desktop. The desktop is your workspace; the GPU box is a headless compute node. If you are building an agent that calls the model, a small VPS next to the GPU can host the agent itself, which is the setup described on the AI agent hosting page.

Pick the country for latency to wherever you sit, then read that location's considerations. The jurisdiction guide walks through how the seven countries differ.

Ordering without identity checks

The order flow is the same for both products:

1. Create an account with an email address you will still be able to open next year. If you lose it, we can't send credentials or recover the service.
2. Top up your balance in crypto. Choose an amount (the minimum is $30) and a coin and network, then send to the address on the invoice. Credit is added after staff confirm the transfer, so it is not instant. Pasting the transaction id on the invoice helps staff match it.
3. Configure and pay with credit. Choose the plan, country, image and term, then pay from your balance.
4. Wait for deploy. Orders are queued and deployed by staff. RDP is usually ready within minutes of that; GPU servers can take a few hours to a day.

Monero is not currently one of the receive options; the accepted coins and networks, and the mistakes to avoid when paying, are covered in how to pay for a VPS with crypto.

Windows RDP hardening checklist

A Windows machine with port 3389 open to the internet is found by automated scanners quickly. These steps close the obvious doors. The first-hour RDP guide has the short version; this is the longer one.

1. Change the password and store it properly

Sign in and change the administrator password before anything else. Use a long, unique passphrase from a password manager. Don't leave the initial password sitting in your email or chat history.

2. Keep Network Level Authentication on

Network Level Authentication (NLA) makes a client authenticate before a full remote session is created. It is on by default on current Windows builds. Check under System Properties → Remote that “Allow connections only from computers running Remote Desktop with Network Level Authentication” is ticked, and leave it that way.

3. Shrink who can reach RDP at all

This is the step that matters most. You have three good options, in rough order of strength:

• Scope the firewall rule to your IP. If your home or office IP is stable, allow RDP only from it.
• Put RDP behind a VPN. Run WireGuard on the server (or on a small Linux VPS in front of it) and allow RDP only from the tunnel address range. The WireGuard guide covers the server side.
• Change the listening port. This cuts down log noise from scanners. It is not real protection on its own, so pair it with one of the above.

Before you tighten anything, open a second RDP session and keep the first one connected. Test the new rule from the second session. If you lock yourself out, recovery means asking support for a reinstall.

Here is a scoped firewall rule in PowerShell, run as administrator. Replace the address with your own:

# Allow RDP only from one trusted address (or your WireGuard subnet, e.g. 10.8.0.0/24)
New-NetFirewallRule -DisplayName "RDP - trusted only" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 203.0.113.25 -Action Allow

# Then disable the built-in rules that allow RDP from anywhere
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Set-NetFirewallRule -Enabled False

# Confirm what is left
Get-NetFirewallRule -DisplayName "RDP - trusted only" | Get-NetFirewallAddressFilter

The display group name can differ on non-English Windows images, so check the output of Get-NetFirewallRule -DisplayGroup "Remote Desktop" before disabling anything.

4. Set an account lockout policy

Without a lockout policy, a password-guessing tool can try forever. In Local Security Policy → Account Policies → Account Lockout Policy, set a threshold of a handful of failed attempts and a lockout duration of several minutes. Recent Windows 11 builds ship with a default threshold, but confirm the setting on your image rather than assuming. If you rename the built-in Administrator account or create a separate admin user and disable the default one, automated tools that guess “Administrator” waste their time.

5. Install updates first, software second

Run Windows Update until nothing is pending, reboot, and only then install your own software. Download installers from the vendor's own site. A “pre-activated” bundle from a forum is the fastest way to put someone else's code on your desktop.

6. Turn off what you don't use

Every running service is something to patch. Remove roles, features and bundled apps you don't need, and keep file sharing and remote management off public interfaces.

7. Telemetry and accounts

Windows sends diagnostic data to Microsoft. You can reduce it under Settings → Privacy & security → Diagnostics & feedback, and Server editions expose more control through Group Policy. The exact options differ by edition, so read what each setting does rather than relying on third-party “debloat” scripts that change things you can't audit. Avoid signing the machine into a personal Microsoft account if you want it kept separate from your identity; a local account works for RDP.

8. Disk encryption: know the caveat

BitLocker can be enabled on many Windows editions, but on a virtual machine without a virtual TPM it usually needs a password or key at boot, which an unattended remote server can't type. It also protects data at rest, not a running machine. If encryption is a requirement, test it carefully, keep the recovery key somewhere safe and offline, or consider a dedicated server where full-disk encryption with your own keys is supported.

GPU server setup for AI workloads

A GPU server arrives as a Linux machine with drivers ready. The goal for the first hour is simple: only you can get in, and nothing you run is listening on the public internet unless you meant it to.

1. Switch to SSH keys

Generate a key on your own machine, copy the public half to the server, confirm you can log in with it, then turn off password logins. Keep the private key on your device, protected with a passphrase.

2. Check the card

Run nvidia-smi. You should see one card of the model you ordered, the driver version and the CUDA version it supports. If the output doesn't match your order, open a ticket before you start installing frameworks.

3. Keep JupyterLab off the public internet

JupyterLab is a full code-execution environment. If it listens on a public address, anyone who finds the URL and token can run commands as your user. Bind it to localhost and reach it through an SSH tunnel instead:

# On your own computer: generate a key and install it on the server
ssh-keygen -t ed25519 -f ~/.ssh/gpu_box
ssh-copy-id -i ~/.ssh/gpu_box.pub user@your-server-ip

# On the server: confirm the GPU, then start JupyterLab on localhost only
nvidia-smi
jupyter lab --no-browser --ip=127.0.0.1 --port=8888

# Back on your computer: forward the port through SSH
ssh -i ~/.ssh/gpu_box -N -L 8888:127.0.0.1:8888 user@your-server-ip
# Then open http://127.0.0.1:8888 in your local browser

Do the same for model servers, image-generation UIs and dashboards. If something must be public, such as an inference API your app calls, put authentication and TLS in front of it and restrict the firewall to expected callers.

4. Size the model to the memory

We don't publish benchmark scores, and you should be wary of anyone who quotes a single number for “tokens per second” without naming the model, quantisation, context length and software. Fit the model to VRAM first:

• 24 GB (RTX 4090): quantised 7B to 70B models for serving, and LoRA fine-tunes of many open-weight models.
• 32 GB (RTX 5090): the same jobs with more headroom for long contexts, a lighter quantisation, or an adapter loaded next to the weights.
• 80 GB (H100): large models that don't fit in 32 GB, and heavier training runs.

The GPU sizing guide expands on this. Read the memory notes published with the specific weights you plan to load; they are more reliable than any rule of thumb.

5. Read the model licence

Open-weight doesn't mean unrestricted. Many model licences have acceptable-use clauses, attribution requirements or limits on commercial use. Self-hosting changes who can see your prompts. It doesn't change the licence you agreed to when you downloaded the weights.

6. Keep data where you can see it

Store datasets and outputs on the server's NVMe, and back them up yourself: we don't back up customer data unless you've bought a backup service, and disks are wiped when a service ends. Encrypt sensitive datasets at rest, and pull results back to your own storage regularly.

What “uncensored” covers, and what it doesn't

When we say uncensored AI hosting, we mean something specific: there is no third-party content filter between you and the model, and we don't read or harvest your prompts. You choose the weights, the system prompt and the sampling settings. That is valuable for research, security review, fiction, and any team that won't send internal text to an API vendor.

It doesn't mean the server is outside the law. The AUP applies on every product in every location: no CSAM, malware, phishing, fraud, spam or botnets, and nothing illegal in the country where the server sits. Generating prohibited material is prohibited whether a human or a model produced it.

One resource rule is worth knowing before you order: cryptocurrency mining on shared VPS is not allowed, and sustained load that degrades service for others can be stopped under the fair-use terms. On a dedicated GPU, ask first.

If you are wondering how foreign copyright notices are handled for what your server publishes, that is a separate topic, covered in DMCA-ignored hosting explained.

The privacy checklist

Work through this before the machine holds anything you care about.

Where to go next

If you're still choosing a country, start with the jurisdiction guide. If you want the background on what no-KYC does and doesn't change, read no-KYC VPS hosting explained. For the product pages themselves, see no-KYC Windows RDP, no-KYC GPU servers and crypto-paid GPU hosting. If you're planning to drive servers from software, the AI agents and API page shows what exists today and what is still planned.