What Is a VPS? Virtual Private Servers Explained for Developers

By Facundo F · Updated on

Devops & Infrastructure and Tips & Tricks

What Is a VPS? Virtual Private Servers Explained for Developers

A VPS, or Virtual Private Server, is a slice of a physical server that behaves like its own dedicated machine. You get a guaranteed share of CPU, RAM, storage, and bandwidth, root access, and full control over the operating system and software stack — without paying for a whole server. It sits between shared hosting (cheap, but you fight other tenants for resources) and dedicated hosting (expensive, but yours alone). For most production web apps, side projects, and self-hosted tools, a VPS is the sweet spot.

This guide explains what a VPS actually is, how the underlying virtualisation works, when you should pick one over the alternatives, what to look for in a provider, and how to keep deployments painless once you have one.

What is a VPS, really?

A physical server in a data centre is divided into multiple virtual machines by a piece of software called a hypervisor (KVM, Xen, VMware ESXi, or Microsoft Hyper-V). Each VM gets its own kernel, its own filesystem, its own network stack, and a fixed allocation of resources. From inside the VM you cannot see the other tenants on the host, you cannot read their memory, and they cannot read yours. That is the private in Virtual Private Server.

Not every VPS is built this way. Some budget providers still sell container-based VPS plans (OpenVZ 7, LXC, Virtuozzo) where tenants share the host kernel. Containers are cheaper to run — the provider can pack more of them onto a box — but the isolation is weaker, you cannot run a custom kernel, and noisy neighbours bite harder. If you have a choice, prefer KVM-based VPS — it is the de facto standard at AWS Lightsail, DigitalOcean, Linode (Akamai), Hetzner, Vultr, OVH, and Contabo, and it gives you full hardware-level virtualisation.

You will see four numbers on every VPS plan page:

  • vCPU — the number of virtual cores assigned to your VM. One vCPU is usually one hyperthread on a shared core, not a dedicated physical core. Dedicated-core plans (Hetzner CCX, DigitalOcean CPU-Optimized, Linode Dedicated) cost more but eliminate steal time.
  • RAM — guaranteed memory. Unlike shared hosting, this is reserved for you whether you use it or not.
  • Storage — almost always NVMe SSD on modern plans. Watch the IOPS limit; cheap plans cap you at 1,000–3,000 IOPS, which a busy database will saturate.
  • Bandwidth — the monthly egress allowance. Hetzner gives you 20 TB on a €4 plan; AWS Lightsail gives you 2 TB and charges $0.09/GB after that. Always read the overage clause.

How a VPS compares to shared, cloud, and dedicated hosting

Option Isolation Root access Typical cost Best for
Shared hosting Same OS, neighbours No $3–$15/mo Static sites, brochure WordPress
VPS (KVM) Dedicated VM Yes $5–$80/mo Web apps, APIs, self-hosted tools
Cloud instance (EC2, GCP, Azure) Dedicated VM Yes Pay-per-hour, scales up Variable load, autoscaling fleets
Bare-metal / dedicated Whole machine Yes $80–$500+/mo Heavy workloads, compliance

A cloud server and a VPS are technically the same thing — both are KVM virtual machines on commodity x86 hardware. The marketing distinction is mostly about pricing model and tooling: cloud providers bill per second and ship managed services around the instance (load balancers, queues, object storage); classic VPS providers bill flat-monthly and assume you bring your own stack. For more on which fits a growing site, see the breakdown in shared hosting vs VPS for junior developers and the signs it is time to upgrade from shared hosting.

What people actually run on a VPS

The you can do anything framing is true but unhelpful. In practice, here is what a VPS is good at — with concrete examples you can deploy in an afternoon:

VPS hosting types: managed, unmanaged, and semi-managed

The VPS itself is a piece of infrastructure. Who runs the OS layer is a separate question.

  • Unmanaged VPS — provider gives you an IP and root access; everything else is yours. Patches, hardening, backups, monitoring, kernel upgrades — you own it. This is what DigitalOcean, Hetzner, Vultr, and Linode default to.
  • Managed VPS — the provider patches the OS, runs the firewall, takes nightly backups, and answers tickets when something breaks. You pay 2–3× more.
  • Semi-managed VPS — middle ground. The provider installs and supports a defined stack (say, LAMP or a control panel like cPanel/Plesk) but leaves your application alone.

If you are comfortable on a Linux command line and you have a deployment automation tool wired up (we will get there), unmanaged is almost always the right call — you get more compute for the money and you keep control of the stack.

What to look for in a VPS provider

Spec sheets all look similar. The differences that matter in production:

  • CPU model and steal time. Ask which CPU. Hetzner CCX uses dedicated AMD EPYC cores; DigitalOcean Basic shares Intel Xeon hyperthreads with up to 30 neighbours. On a noisy host you will see 5–15% CPU steal time in top — that is your performance evaporating.
  • Storage IOPS, not just capacity. A 50 GB disk capped at 1,000 IOPS will choke any write-heavy database. Look for NVMe, local SSD, or a published IOPS number.
  • Network throughput and DDoS protection. 1 Gbps shared is fine for a web app. OVH and Hetzner include free DDoS scrubbing; many cheaper providers do not.
  • Snapshot and backup model. Snapshots that count against your storage quota are a footgun. Off-host backups with a documented restore process are non-negotiable for anything you care about.
  • Data centre region. Latency between your users and the host dominates page-load time. Pick a region within ~50 ms of your traffic.
  • Pricing transparency. Egress overage, snapshot storage, IPv4 add-ons, and premium CPU surcharges are where the cheap plan stops being cheap.

If your project lives on AWS, AWS Lightsail is a managed VPS with predictable monthly billing that still lets you peer into a real VPC.

Is a VPS secure?

It is as secure as you make it. The hypervisor isolates you from other tenants, but everything inside the VM is your problem. The non-negotiable checklist on day one:

  1. Disable password SSH; use keys only. Add PasswordAuthentication no and PermitRootLogin no to /etc/ssh/sshd_config. Move SSH to a non-default port if you want, though that is theatre rather than security.
  2. Enable an automatic-update channel. unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL/Rocky/Alma. Critical CVEs in OpenSSH, sudo, the kernel, and TLS libraries are shipped weekly.
  3. Run a firewall. ufw or firewalld is fine. Default-deny inbound, allow only the ports you actually serve. Most providers also expose a network-level firewall in their console — use both.
  4. Add an intrusion-prevention layer. Fail2Ban bans IPs after repeated SSH or web auth failures. Five minutes to set up; eliminates 99% of bot noise in your auth logs.
  5. Run the app as a non-root user. Anything internet-facing should be behind systemd, in its own user, with a reverse proxy (nginx, Caddy) in front — see nginx vs Apache vs Caddy.
  6. Back up off-host. Snapshots on the same provider are not a backup. Push tarballs or database dumps to S3, B2, or another provider on a cron.

The most common way a VPS gets compromised is not a kernel exploit — it is a default root password on a fresh image, an outdated WordPress install, or an exposed Redis/Mongo/Elasticsearch with no auth. Patch on a schedule and audit your open ports.

Performance: what to actually expect

Numbers are more useful than adjectives.

  • A 1 vCPU / 2 GB / NVMe VPS at Hetzner (€4–5/mo) handles 800–1,500 requests/sec for a static-cached WordPress, or 200–400 req/sec for a dynamic Laravel or Rails app with a local PostgreSQL.
  • The same plan struggles with anything that needs more than ~1.5 GB resident memory — Node apps with multiple workers, Java/JVM apps, or a database with a working set bigger than a couple of gigs.
  • Latency dominates real-world performance more than raw throughput. A page rendered in 80 ms in Frankfurt becomes 280 ms for a US user. Pick the right region, then put a CDN in front of static assets.
  • Don't size for peak — size for p95. Most apps idle below 20% CPU. Pay for more cores when you see steal time, not when load average spikes for thirty seconds during a deploy.

How to keep your VPS deployments sane

The single biggest reason teams move off a VPS is not performance — it is that deploys turn into ad-hoc SSH sessions. After six months, nobody remembers how the production environment was built. Avoid that from day one:

  • Treat the server as cattle, not a pet. A short bootstrap script (cloud-init, Ansible, or a plain shell script) should turn a fresh image into your production server. If you cannot rebuild the box from scratch in under an hour, you have drift.
  • Deploy from Git, not from your laptop. Push to main; the server pulls and restarts. This is what DeployHQ automates — connect a GitHub repo, GitLab repo, Bitbucket repo, or self-hosted Git instance to one or more VPS targets and ship code by pushing a branch.
  • Build artifacts before they hit the server. Run npm ci && npm run build or composer install --no-dev on a build agent, not on production. DeployHQ's build pipelines run in an isolated container per deploy so your VPS only ever serves the compiled output.
  • Atomic, rollback-friendly deploys. Symlink-swap the current directory or use a release-per-folder layout. Combined with zero-downtime deployments and one-click rollback, a bad release stops being a 2 a.m. incident.
  • Manage config and secrets separately from code. .env files copied at deploy time, secrets pulled from a vault, never committed to Git.
  • Repeatable across servers. When the box runs out of headroom, a second identical VPS behind a load balancer should take ten minutes to bring up — not a day. See setting up Git-based deployment on a VPS for the basic pattern, or the easiest way to deploy on a VPS for the DeployHQ-specific walkthrough.

If you are running Docker on the VPS, the same rules apply — your compose.yml is your bootstrap, your image registry is your build artifact, and a docker compose up -d against a tagged image is your deploy.

When a VPS stops being the right answer

A VPS is the default answer for most projects, but it is not always the right one. Move on when:

  • Your traffic is bursty and unpredictable, and you actually need horizontal autoscaling — pick AWS, GCP, or a managed Kubernetes platform.
  • You need geographic redundancy across continents — multi-region cloud or a CDN-first architecture beats a fleet of independent VPSes.
  • You are building a fully serverless stack and never want to touch a Linux box — managed platforms (Vercel, Netlify, Fly, Railway) trade cost and lock-in for zero ops. DeployHQ also supports serverless deployments for that case.
  • You have hard compliance requirements that demand bare metal or a private cloud.

For everything else — and that is most of what gets built on the web — a $5 to $40 VPS with disciplined deployments will take you a long, long way.

Get started

If you already have a VPS and want to stop SSH-ing into it to deploy, start a free DeployHQ trial — connect your repo, point it at the server, and your next git push is your next deploy. Running multiple sites or client projects? The agency plan gives unlimited team members and project templating; full pricing is on the plans page.

Questions about migrating to a VPS or wiring up automated deploys? Email us at support@deployhq.com or ping @deployhq on X.