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](https://www.deployhq.com/blog/shared-hosting-vs-vps-a-comprehensive-guide-for-junior-developers) and the [signs it is time to upgrade from shared hosting](https://www.deployhq.com/blog/5-signs-it-s-time-to-upgrade-from-shared-hosting-to-automated-deployments).

## 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:

- **Production web apps and APIs** : Next.js, Laravel, Rails, Django, Node, Go services. A 2 vCPU / 4 GB plan handles tens of thousands of requests per day for most stacks. See [how to deploy a Next.js app on a VPS](https://www.deployhq.com/blog/deploy-nextjs-on-vps) for a worked example.
- **Self-hosted developer tools** : GitLab, Gitea, Drone, Jenkins. [Self-hosting GitLab on a VPS](https://www.deployhq.com/blog/how-to-deploy-gitlab-on-a-vps-a-step-by-step-guide) needs at least 4 GB RAM; 8 GB is comfortable.
- **Self-hosted SaaS replacements** : n8n (Zapier alternative), Metabase (BI), Nextcloud (Dropbox), Paperclip (link saver), Open WebUI + Ollama (local ChatGPT). See [self-hosting Paperclip on a VPS with Docker](https://www.deployhq.com/blog/self-host-paperclip-vps-docker-deployhq), [self-hosting n8n on Alibaba Cloud Linux 3](https://www.deployhq.com/blog/deploying-n8n-on-alibaba-cloud-using-docker), [deploying Metabase with Docker Compose](https://www.deployhq.com/blog/how-to-deploy-metabase-on-ubuntu-20-04-with-docker-and-deployhq), and [installing Open WebUI and Ollama on a VPS](https://www.deployhq.com/blog/how-to-install-and-run-chatgpt-on-a-vps).
- **Authentication and identity** : a small Keycloak instance on a 4 GB VPS can serve hundreds of thousands of users. See [deploying Keycloak 26 on Ubuntu 24.04](https://www.deployhq.com/blog/simplifying-authentication-a-comprehensive-guide-to-installing-keycloak-on-a-vps).
- **Game servers, IRC, Mastodon, Matrix** : anything that needs a long-running process and a stable IP.
- **Staging and test environments** : spin up, deploy a branch, tear down. Cheaper than running parallel cloud accounts.

## 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](https://www.deployhq.com/guides/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](https://www.deployhq.com/blog/fail2ban-comprehensive-protection-for-your-servers) 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](https://www.deployhq.com/blog/nginx-vs-apache-vs-caddy-choosing-the-right-web-server).
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](https://www.deployhq.com) automates — connect a [GitHub repo](https://www.deployhq.com/deploy-from-github), [GitLab repo](https://www.deployhq.com/deploy-from-gitlab), 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](https://www.deployhq.com/features/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](https://www.deployhq.com/features/zero-downtime-deployments) and [one-click rollback](https://www.deployhq.com/features/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](https://www.deployhq.com/blog/setting-up-git-based-deployment-on-a-virtual-private-server-vps) for the basic pattern, or [the easiest way to deploy on a VPS](https://www.deployhq.com/blog/what-s-the-easiest-way-to-deploy-on-a-vps) for the DeployHQ-specific walkthrough.

If you are running [Docker](https://www.deployhq.com/blog/what-is-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](https://www.deployhq.com) also supports [serverless deployments](https://www.deployhq.com/blog/serverless-deployments-with-deployhq-aws-lambda-vercel-and-netlify) 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](https://www.deployhq.com/signup)[DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/for-agencies) gives unlimited team members and project templating; full pricing is on the [plans page](https://www.deployhq.com/pricing).

Questions about migrating to a VPS or wiring up automated deploys? Email us at [support@deployhq.com](mailto:support@deployhq.com) or ping [@deployhq](https://x.com/deployhq) on X.