What can your VPS provider see? A technical answer

Technically, whoever runs the host of a virtual server can read its disk and memory, and see its network traffic: the metadata always, the content whenever it is not encrypted. What protects you is encryption, the provider's policy and the law it operates under. A dedicated server removes the hypervisor layer, but not physical access.

So what can my VPS provider see in practice? Below, layer by layer, with our offshore VPS and dedicated servers as the example: the account, the network, the disk and memory, and what encryption changes. We say where our protection is technical and where it is a promise.

What can my VPS provider see about my account?

Whatever its sign-up and payment steps collect: at hosts that check identities, a name, an address, a phone number and a card; at many, the IP address you sign in from. Our privacy policy lists every item we hold; in short:

We ask for an email address and a password, nothing else: no name, no ID, no phone. We keep your billing and service records, and no IP address with your account. We never look inside your server.

• Sessions and security log: "a summary of the browser and operating system, and the country as reported by Cloudflare. Never your IP address."
• No traffic logging or inspection: no deep packet inspection, no scanning of your server's content, no records of what it sends or receives.
• No IP addresses in our web access logs. Form rate limits use a salted IP hash kept for at most 1 hour.

Billing records hold each top-up's coin, amount, deposit address and transaction ID. On public blockchains such as Bitcoin's, anyone can see amounts, timing and wallet addresses; Monero hides the sender, the receiver and the amount. More in our no-KYC hosting explainer.

What can my VPS provider see on the network?

Can my host see my traffic? Every packet crosses its network, so the provider sits on the path, like your internet provider and every transit network in between. Each of them sees:

• Addresses and ports, which travel unencrypted in every packet header.
• Timing and volumes. Even TLS 1.3 "does not hide the length of the data it transmits".
• DNS lookups, unless encrypted. Otherwise, "DNS traffic can be seen by an eavesdropper like any other traffic" (RFC 9076). DNS over TLS or HTTPS hides it on the wire; the resolver still sees it.
• Site names. TLS 1.3 encrypts the server certificate, but the Server Name Indication stays in plaintext unless both ends use Encrypted Client Hello (RFC 9849, March 2026).

Encryption hides the content: TLS protects HTTPS pages, forms and URL paths; SSH, your commands and file transfers; WireGuard, whole IP packets sent over UDP between two visible endpoints. Plaintext protocols such as HTTP, FTP or unencrypted DNS are readable by anyone on the path. A VPN on your server, such as one built with our WireGuard VPN guide, moves that boundary without removing it: traffic leaves the VPS as ordinary traffic. We do not log or inspect customer traffic, but that is a policy; encryption is the technical protection.

Inside a KVM VPS: disk, memory and console

A VPS is a guest on someone else's computer: its disk is an image on the host, its memory part of the host's RAM. In traditional virtualization, says the Linux kernel's confidential computing threat model, "the host has unlimited access to guest data". Any standard KVM host, ours included, can:

• copy or mount the disk image, running or not;
• dump the memory with QEMU's dump-guest-memory, or take a VM snapshot that includes the RAM;
• choose what the VM boots from and use its console, which is how password resets work without your password;
• read files and set passwords through the QEMU guest agent, if it runs in the VM.

So can a hosting provider see my files? On an unencrypted VPS, technically yes. Our protection here is a policy, "We never look inside your server", and the process in our law-enforcement guidelines: we act only on a valid order from a court or authority competent where the server runs, respond only to the extent the law requires, and tell the customer unless the law forbids it. Genuine emergencies go faster. A policy lasts as long as the provider and the law allow; encryption depends on neither, within the limits below.

Confidential computing: the technology that changes this

Confidential computing treats "a potentially misbehaving host" as an attacker and aims to "preserve the confidentiality and integrity of CoCo guest's private memory and registers", in the same kernel document's words. On x86, two technologies implement it:

• AMD SEV-SNP. SEV encrypts a guest's code and data so that "a decrypted version is available only within the VM itself", says the kernel's AMD documentation. SEV-SNP adds a reverse map table, "used to ensure a one-to-one mapping between system physical addresses and guest physical addresses".
• Intel TDX. Trust Domain Extensions "protect confidential guest VMs from the host and physical attacks".

Both support attestation, so the guest can verify its protection instead of trusting a product page. The limits: the host "retains full control over the CoCo guest resources, and can deny access to them at any time", and disk and network data still pass through devices it manages, so they need encryption inside the guest.

How to encrypt a VPS, and what it does not hide

LUKS full-disk encryption turns the disk image, its snapshots and any discarded drive into ciphertext. For the whole system, boot your own ISO from Server actions and choose guided partitioning with encrypted LVM in the Debian installer: everything but a separate /boot, swap included, is encrypted, and the server waits for your passphrase after every reboot. To keep your template, use an encrypted container file; cryptsetup attaches it to a loop device by itself:

fallocate -l 10G /root/vault.img
cryptsetup luksFormat /root/vault.img
cryptsetup open /root/vault.img vault
mkfs.ext4 /dev/mapper/vault
mkdir -p /mnt/vault
mount /dev/mapper/vault /mnt/vault

To lock it, unmount it and run cryptsetup close vault, which "wipes the key from kernel memory". Files outside the container, such as logs, stay in plaintext.

The limit: for LUKS2, the cryptsetup FAQ notes, "the keys of a mapped (open) container are now stored in the kernel key-store", and a VPS kernel runs in memory the host can read. So LUKS on a VPS protects stored copies, not a running VM. Application-level and client-side encryption go further, because the server never decrypts the data: GnuPG-encrypted uploads, restic or Borg backups, and end-to-end encrypted apps whose keys stay on users' devices.

VPS vs dedicated privacy: what bare metal changes

A dedicated server has no hypervisor and no host system beneath yours. The provider keeps physical access and IPMI: the baseboard management controller, a separate computer on the mainboard, provides the console, power control and virtual media. On ours, IPMI access is limited to the IP addresses you ask us to allow.

Full-disk encryption makes a powered-off server or a removed disk unreadable without your passphrase. Debian's dropbear-initramfs lets you "unlock your rootfs on bootup remotely, using SSH", as its README explains: add your public key to /etc/dropbear/initramfs/authorized_keys, run update-initramfs -u -k all, and after each reboot log in and run cryptroot-unlock. A passphrase typed in the IPMI console instead passes through the controller.

Two limits remain. A running server keeps the key in memory. And /boot "is usually not encrypted", as the same README notes, so someone with access to the machine, in person or through IPMI virtual media, could alter it to capture your passphrase at the next unlock: treat a reboot you did not cause as a warning. Still, reading a running VPS takes tools its host already has; an encrypted dedicated server takes an attack on its hardware or boot chain.

Side by side: what each setup exposes

What the provider can technically see; "with encryption" means LUKS inside the VM and TLS, SSH or WireGuard for all traffic.

Checklist: minimize what any provider can see

VPS privacy is layered: each step removes something a provider could see or hold.

1. Sign up with an email alias used nowhere else, as our guide to buying a VPS anonymously explains.
2. Pay with Monero, which hides sender, receiver and amount: see our Monero VPS page.
3. Log in with SSH keys. The first root password is shown in your client area, so it is not a secret only you hold: change it, then follow our hardening guide.
4. Encrypt all traffic with HTTPS, SSH, WireGuard and encrypted DNS.
5. Encrypt data at rest with LUKS, and client-side for data the server never needs to read.
6. Use a dedicated server with full-disk encryption for sensitive workloads.
7. Verify the warrant canary each quarter: our warrant canary is PGP-signed and states the date of the next renewal.

Frequently asked questions

Can my VPS provider see my files?

Technically, yes, unless they are encrypted: a standard KVM host can read the virtual disk and the VM's memory. LUKS keeps the disk image and snapshots unreadable at rest, but a running VM holds its key in memory. Client-side encryption protects files everywhere. Our privacy policy adds: "We never look inside your server."

Can my hosting provider see my traffic?

It sees the metadata of all of it: addresses, ports, timing and volumes, plus DNS lookups and site names unless those are encrypted. It reads content only when a protocol sends it in plaintext; TLS, SSH and WireGuard hide it. We do not log or inspect customer traffic, but encryption makes that technical, not a promise.

Does full-disk encryption protect a VPS?

Partly. LUKS protects data at rest: disk images, snapshots and discarded drives hold only ciphertext. It does not protect a running VPS from its host, because the unlocked key sits in the VM's memory. For protection while it runs, use a dedicated server, or a confidential VM that proves its protection through attestation.

Can a VPS provider access my server without my password?

Technically, yes. A KVM host controls the virtual disk, the boot and the console, so it can read files or reset a password without yours, or set one through the QEMU guest agent if it runs in the VM. A dedicated server has no hypervisor, but the provider keeps physical and IPMI access. Encryption protects the data; a password does not.

What does OffshoreServ log?

Very little: your email address; balance, top-up and service records; the tickets and requests you send; and sessions and a security log with the browser, operating system and country, never an IP address. Our web access logs hold no IP addresses, and server traffic is never logged or inspected.