Is VPS hosting safe? What you control

Is VPS hosting safe? The short answer

Yes. VPS hosting is safe for the work most people buy it for, and it is a real improvement on shared hosting. A VPS (virtual private server) is a virtual machine with its own kernel, its own memory, its own disk and its own user accounts, and the hypervisor that runs it keeps other customers out of all four. The person renting the server next to yours on the same physical machine cannot read your files, list your processes, log into your server or see your network traffic.

The honest answer has two halves. The provider owns the hardware and the hypervisor. You own everything inside your virtual machine, and that is where almost every real incident starts. Servers get broken into through an open port, a weak SSH password, a package nobody updated or a secret in a file that got published. They very rarely get broken into through the hypervisor.

What the hypervisor actually separates

A hypervisor is the software that runs virtual machines on one physical host. On a KVM VPS (KVM means kernel based virtual machine, the standard on Linux hosts) your server is a full virtual machine. It boots its own kernel. The host gives it a fixed region of physical memory, and the processor's memory management unit refuses any access outside that region, so code running in another guest cannot address your RAM at all. There is no shared filesystem and no shared user table, so file permissions on a neighbour's server mean nothing on yours.

Shared hosting works differently. Many sites live inside one operating system, under one web server and one PHP install, as ordinary user accounts. The only boundary is file permissions. A permission mistake, or a vulnerable plugin running as a user that can read too much, can therefore reach another account's files. That is the gap moving from shared hosting to a VPS closes.

Check what you are buying, because not every plan sold as a VPS is a virtual machine. Container based plans (OpenVZ, LXC, Virtuozzo) share the host's kernel and separate customers with namespaces and cgroups instead of hardware virtualization. That is a weaker boundary, because a kernel bug on the host is a kernel bug in your server too. You also cannot load kernel modules on those plans, which rules out some software. KVM is the safer default. Ask which one you are getting before you pay.

What a noisy neighbour can do to you

Sharing a physical host costs you speed, and speed is the only thing it costs. The guests on one machine share the physical CPU and the disks. When the CPU is busy with someone else, your virtual CPU waits, and Linux reports that wait as steal time: the %st field in top and vmstat. Steal time that sits above a few percent for hours means the host is oversubscribed. It does not mean anyone is reading your data. The fix is a different plan or a different provider, and you can measure the CPU and disk you actually got before you decide.

One cross customer effect is worth knowing about, and it is not a security hole. If you send email from your VPS, your IP address sits in a range that other customers also use. A neighbour who sends spam can get part of that range listed on a blocklist, so your mail lands in spam folders for a reason you did not cause. Providers that police abuse keep cleaner ranges. Ask about that if email matters to you.

What a hostile neighbour cannot do, and the rare case where they can

A customer on the same host has no path to your files. They cannot see your processes, mount your disk or open a shell on your server, because none of those things exist inside their virtual machine. One exception is worth stating: treat any provider private network as a network you share with strangers, and encrypt what crosses it rather than assuming it is invisible.

Hypervisor escapes are real. A bug in the virtualization layer can let code inside one guest reach the host, and from the host reach every guest on it. These bugs are found, published with a CVE (common vulnerabilities and exposures) identifier and patched, and hosting providers patch them quickly because their whole business sits on that layer. Using one takes a working exploit for a specific hypervisor version, which is an expensive thing to spend on a small hosting account.

Cross guest side channels are also real. They are the Spectre and Meltdown family, and they abuse shared processor caches to infer small amounts of data across a boundary. Microcode and kernel updates mitigate them, and the leak rates in published work are tiny. Published cases are research demonstrations rather than mass attacks. The risk is not zero. It is simply nowhere near the top of the list of things that will hurt you.

Where the provider's job ends and yours begins

The provider is responsible for the building, the host hardware, the hypervisor and host kernel, the physical network, and the control panel that can start, stop, rebuild and snapshot your server. If any of that fails, it is their failure to fix.

You are responsible for everything from your operating system upward. That means the packages you install, the ports you leave open, the accounts and keys that can log in, the updates you apply, your backups, and your own application code. Most VPS plans are unmanaged, which means nobody is patching your server for you and no support ticket will do it. The managed and unmanaged split is worth reading before you buy, because it decides how much of that list lands on you.

One part of your half is easy to forget: the hosting control panel itself. Whoever holds that login can rebuild your server or attach your disk to a rescue system, without ever knowing a password from inside the server. Turn on two factor authentication (2FA) on the hosting account, and do not reuse that password anywhere else.

Can your hosting provider see your data?

Yes, in principle, and this is the honest limit of what a VPS gives you. Your disk image sits on the provider's storage. Their console gives screen level access to your virtual machine. Rescue mode can boot a different system with your disk attached. A VPS protects you from other customers, and the provider stays outside that promise.

If you hold data that must stay unreadable to the host, encrypt it in your application before it is written. Full disk encryption inside the guest helps against a copied image at rest, but the key has to sit in memory while the server runs, so it does not take the provider out of the picture. The same trust applies to a dedicated server you rent alone, with one shared layer fewer.

What actually breaks into a VPS

A service listening on every interface. Databases, caches, message queues and admin panels often bind to 0.0.0.0 by default, which means every network interface, including the public one. Internet wide scanning is constant and automated, so a fresh IP address gets its first unsolicited probe within minutes of coming online. Redis with no password, an unauthenticated Elasticsearch node, an open Docker API on port 2375 and an admin panel still using its default login are all found this way, by a scanner that has no idea who you are. Bind a service to 127.0.0.1 when only the local machine needs it, and block the rest at the firewall.

Docker going around your firewall. Publishing a container port writes network address translation (NAT) rules that are evaluated before the rules from ufw (uncomplicated firewall), so a container can be reachable from the internet while ufw status says that port is denied. This catches people who did everything else correctly. The reason a Docker port ignores ufw is worth reading before you publish a container port.

SSH with passwords enabled. Read /var/log/auth.log on any public server and you will find lines like Failed password for root from 203.0.113.10 port 54312 ssh2, thousands of them, day and night. Bots work through common usernames and common passwords. Password login plus a root account that accepts logins is all an attacker needs. Keys only, with root login off, turns that traffic into noise you can ignore.

One private key used everywhere. A single key copied to every laptop and every server means one stolen laptop unlocks everything, and SSH keys do not expire, so a key handed to a contractor two years ago still works today. One key per person and per machine costs nothing and limits what a single stolen key can reach.

Packages nobody updated. A published CVE against your web server or your application framework is a public set of instructions, and scanners start testing for it within days. Security updates are the cheapest defence available, and they can run on their own: see automatic security updates on Ubuntu.

A leaked secret. Database passwords and API keys live in .env files, and those files get committed to a public repository, or served by a web server pointed at the wrong directory. Anything pasted into an AI coding agent's context can end up in a log as well, which is its own subject: keeping secrets out of an agent's reach.

Everything running as root. When your application runs as root, one bug in it owns the whole machine, because there is no boundary left inside the server to stop it spreading.

Your half of the job

None of the following is hypervisor work. All of it sits on your side of the line, and it is the side that decides whether your VPS is safe.

• Do the first hour properly: the first ten minutes on a new VPS covers a non root user and a firewall.
• Lock down remote access: hardening SSH on a VPS.
• Close the ports you are not using: ufw firewall basics.
• Give each service only the access it needs: least privilege users on a VPS.
• Slow down brute force logins: fail2ban on Ubuntu 24.04.
• Keep a backup you have restored at least once: restic backups for a VPS.

The provider's half is already done by the time your server boots. Your half takes about an hour on the first day and a few minutes a month after that. If you are still comparing options, what a VPS actually is covers the ground under all of this.

FAQ

Can another customer on the same physical server read my files?

No, not on a KVM VPS. Your server is a virtual machine with its own kernel and its own virtual disk, plus a region of physical memory the host assigns to it, and the processor blocks any access outside that region. There is no shared filesystem between guests, so file permissions inside a neighbour's server have no meaning inside yours. Container based plans such as OpenVZ and LXC share the host kernel and give a weaker boundary, so check which type you are buying.

Is a VPS safer than shared hosting?

For isolation, yes. On shared hosting many sites run inside one operating system and the only boundary is file permissions, so a mistake in another account can sometimes expose files. On a VPS the boundary is a virtual machine. The trade is that shared hosting is patched by the host, while an unmanaged VPS is patched by you. A VPS is safer only if you actually apply the updates and close the ports.

Can my hosting provider read my data?

In principle yes, and no VPS product changes that. The disk image is stored on the provider's hardware, the console gives screen level access to the running machine, and rescue mode can boot a different system with your disk attached. If some data must stay unreadable to the host, encrypt it in your application before writing it. Disk encryption inside the guest still keeps the key in memory while the server runs, so it does not remove the provider from the trust picture.

What is the most common way a VPS gets compromised?

An exposed service or a weak SSH login, by a wide margin. Automated scanners probe every public IP address continuously, so a database bound to 0.0.0.0 with no password, or an admin panel left on its default credentials, is found in minutes rather than months. /var/log/auth.log on any public server shows the SSH half of it: repeated Failed password for root lines from addresses all over the world. Hypervisor escapes exist, but they are research grade work aimed at high value targets, not the cause of ordinary breaches.