VPS and cloud providers

01Four ways to host an app

Think of hosting like housing. Shared hosting is a room in a shared flat: cheap and managed for you, but you share resources with hundreds of sites, cannot install your own software and one noisy neighbor slows you down. It works for simple PHP sites. A VPS is your own apartment: a virtual machine with guaranteed CPU, RAM and disk and full root access, where you are responsible for everything inside. A managed platform (PaaS) such as Vercel, Render, Fly.io, Railway or Laravel Cloud is a serviced apartment: you push code and it handles servers, scaling and TLS, at a higher price per resource and with platform limits. A hyperscale cloud (AWS, Google Cloud, Azure) is a whole city: virtual machines plus managed databases, queues, storage and networking, very flexible and very complex.

• Shared hosting: cheapest, least control. Good for brochure sites and small WordPress installs.
• VPS: full control at low cost; you own security, updates and backups.
• Managed platform: fastest to ship, pay for convenience, limited control.
• Hyperscale cloud: everything is available, but cost and configuration need real expertise.

02Choosing a provider

For VPS hosting, the popular options are DigitalOcean (droplets, clear UI, good docs, managed databases and object storage), Hetzner (very strong price-to-performance, data centers in Europe and the US), Vultr, Linode (now Akamai) and OVHcloud. AWS Lightsail offers simple VPS plans inside AWS. The big clouds make sense when you need specific managed services, compliance certifications, many regions, or your company already runs there. When comparing, look past the monthly price: check the data center locations, included bandwidth and the price beyond it, the quality of snapshots and backups, whether there is a cloud firewall and private networking, managed database and object storage options, API and Terraform support, and how support responds. Prices change, so compare current pricing pages rather than old blog posts.

• Location: close to your users; consider data-residency rules such as GDPR.
• Network: included traffic, egress price, IPv6, DDoS protection.
• Extras: cloud firewall, private network, snapshots, backups, object storage, managed DB.
• Operations: API, CLI, Terraform provider, status history and support quality.

03Sizing and region

Start small and measure; it is easy to resize a VPS later, and most providers let you scale up in minutes. A small site with nginx and PHP or Node runs comfortably on 1 to 2 vCPUs and 2 GB of RAM. Add a database, Redis and queue workers on the same machine and 4 GB or more is a safer start. Memory is usually the first limit, not CPU. Shared vCPU plans are cheap and fine for most web apps; dedicated vCPU plans give steady performance for CPU-heavy work. Choose the region closest to most of your users, keep servers that talk to each other in the same region, and remember that a CDN like Cloudflare can serve static files close to users anywhere. Watch load, memory and disk for a few weeks and resize based on data.

• Memory runs out before CPU on most web servers; plan for the database and workers.
• SSD or NVMe disk; keep user uploads and backups in object storage instead of a huge disk.
• Resizing up is usually easy; resizing the disk down often is not.

04Snapshots, backups and private networking

A snapshot is a full image of the server's disk at one moment. It is perfect before risky changes, because you can roll the whole machine back. Provider backups are scheduled snapshots, typically daily or weekly for a small surcharge. But both live at the same provider, and a disk snapshot of a running database may not be consistent. So also make application-level backups, such as a database dump, and copy them off the server, ideally to object storage at another provider or region. A backup only counts once you have restored it successfully. Private networking connects your servers over an internal network that is not reachable from the internet, so the app server can reach the database without exposing it publicly.

• Snapshot before upgrades, migrations and big config changes.
• Database dumps plus off-site copies; follow the 3-2-1 idea (3 copies, 2 media, 1 off-site).
• Test restores on a fresh server on a schedule.
• Use the private network for database and cache traffic between servers.

05Keeping costs under control

Cloud bills grow quietly. The usual leaks are forgotten servers and test environments, old snapshots and unattached volumes, oversized instances nobody resized, load balancers and static IPs you no longer use, and above all outbound traffic (egress), which on the big clouds is billed per gigabyte and can dwarf the server price. A VPS provider with generous included traffic is often far cheaper for bandwidth-heavy sites. Simple habits help: set a billing alert, tag or name every resource by project, review the bill monthly, delete what you do not use, and put a CDN in front of static assets. Consolidating many small, half-empty servers into fewer well-sized ones often cuts cost and maintenance at the same time.

• Billing alerts and budgets on every account.
• Monthly cleanup: old snapshots, volumes, IPs, test servers.
• Mind egress pricing; cache static files at a CDN.
• Commit to reserved or savings plans only for steady, long-term workloads.

06The first 10 minutes on a new server

A fresh public server is scanned within minutes, so secure it before you deploy anything. Create the server with your SSH key added, log in, update packages, create your own sudo user, confirm key login works for that user in a second terminal, then disable password and root login. Turn on the firewall with only SSH, HTTP and HTTPS, and mirror that in the provider's cloud firewall. Enable automatic security updates, install fail2ban, set the time zone and hostname, add a swap file on small instances, and take a first snapshot of the clean base. Finally set up monitoring and a disk alert. The commands for each step are covered in the other Linux lessons.

1ssh [email protected]                      # first login with your key
2apt update && apt full-upgrade -y
3adduser your_user && usermod -aG sudo your_user
4rsync -a --chown=your_user:your_user ~/.ssh /home/your_user/
5# New terminal: ssh [email protected] must work before continuing
6printf "PasswordAuthentication no\nPermitRootLogin no\n" > /etc/ssh/sshd_config.d/10-hardening.conf
7sshd -t && systemctl reload ssh
8ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
9apt install -y unattended-upgrades fail2ban
10dpkg-reconfigure -plow unattended-upgrades
11timedatectl set-timezone UTC && hostnamectl set-hostname web1

07What a vCPU really is: hypervisors, steal time and storage

A VPS is a virtual machine on a physical host shared with other customers, run by a hypervisor such as KVM. A vCPU is usually one hardware thread of a host core, scheduled among many guests. On shared-CPU plans the provider assumes not everyone is busy at once; when neighbors are, your VM waits, and that waiting shows up as steal time, the st value in top and vmstat. Consistent steal above a few percent means you are paying for CPU you do not get, and a dedicated-CPU plan or another host fixes it. Storage differs too: local NVMe is fast and low-latency but tied to the host, while network block volumes survive host failures and can be moved, but have higher latency and IOPS limits per volume size. Knowing which one you have explains benchmark results that otherwise make no sense.

1top -bn1 | head -5            # look at 'st' in the %Cpu(s) line
2vmstat 1 10                   # last column 'st' = steal
3lscpu | grep -E 'Model name|Thread|Hypervisor'
4systemd-detect-virt           # kvm, xen, microsoft...
5# Quick disk benchmark (apt install fio), on a test file, not a live DB
6fio --name=randread --rw=randread --bs=4k --size=1G --runtime=30 \
7    --ioengine=libaio --direct=1 --filename=/var/tmp/fio.test

08Servers as code: cloud-init and rebuildable machines

The most robust server is one you can recreate in minutes. Almost every provider supports cloud-init: you pass a user-data document when creating the VM, and on first boot it creates users, installs SSH keys, installs packages and runs commands. That turns the first ten minutes of hardening into a file you review and version, so every new server starts identical. Tools like Terraform or OpenTofu go one level higher and describe the servers, firewalls, volumes and DNS records themselves through the provider's API, and configuration tools like Ansible handle ongoing changes inside the machine. Even if you never automate fully, keeping user-data and a written runbook means a lost server is an inconvenience rather than a crisis, because nothing important exists only in someone's memory.

1#cloud-config
2users:
3  - name: your_user
4    groups: [sudo]
5    shell: /bin/bash
6    lock_passwd: true
7    ssh_authorized_keys:
8      - ssh-ed25519 AAAAC3...placeholder your_user@laptop
9ssh_pwauth: false
10disable_root: true
11package_update: true
12package_upgrade: true
13packages: [ufw, fail2ban, unattended-upgrades]
14runcmd:
15  - [ufw, allow, OpenSSH]
16  - [ufw, allow, 80/tcp]
17  - [ufw, allow, 443/tcp]
18  - [ufw, --force, enable]

09Availability on a small budget: RPO, RTO and single points of failure

Two numbers make availability discussions concrete. RPO (recovery point objective) is how much data you can afford to lose, which sets the backup frequency: nightly dumps mean up to a day of lost orders. RTO (recovery time objective) is how long you can be down, which sets how much must be automated. A single VPS is a single point of failure, and that is often acceptable if RPO and RTO are agreed and tested. Cheap improvements come first: more frequent dumps or continuous binlog or WAL archiving to object storage, a reserved or floating IP that can be moved to a replacement server, DNS TTLs kept moderate, and a rehearsed restore. Running two app servers behind a load balancer only helps once the database, sessions and uploads are no longer on a single machine.

• Agree RPO and RTO with the business before choosing the architecture.
• A floating or reserved IP lets you swap servers without waiting for DNS.
• Restore drills turn a written RTO into a measured one.

10The scaling path from one VPS

Scale in steps and only when measurements demand it. Step one is vertical: a bigger plan, which takes minutes and changes nothing in the app. Step two is separation: move the database to its own server or a managed database on the private network, so app and data stop competing for memory, and move uploads to object storage. Step three is horizontal: several identical app servers behind a load balancer. That requires stateless app servers: sessions and cache in Redis or the database, files in object storage, scheduled jobs running on exactly one node, and deploys that update every node consistently. Step four is read replicas, queues for slow work and a CDN for static content. Each step adds cost and operational work, so a well-tuned single server often goes further than people expect.

• Vertical first, then split the database, then go horizontal.
• Horizontal scaling needs stateless app servers.
• Make sure cron and schedulers run on one node only.