Creating a VPS

What is it? #

Creating a VPS takes a few minutes and involves four decisions: where it runs, how big it is, what operating system it has, and how you will log in.

Region matters more than people expect. Distance to your users is latency you cannot optimise away, and data residency may be a legal requirement.

For the operating system, an LTS release is the right default. Long-term support means security updates for years without a distribution upgrade.

The most important choice is adding your SSH key at creation time. It means the server is never reachable by password, not even briefly.

Think of it like this #

Choosing premises. Location determines how long customers take to reach you, size determines what fits, and whether you fit a proper lock on day one determines whether the first week is spent worrying about the door.

Simple example #

You create a server for an application serving users in India: a Mumbai region, 2 CPUs and 4 GB, Ubuntu LTS, your SSH key added at creation, and automatic backups enabled.

Code #

The four decisions

1. Region        closest to your users; check data residency requirements
                 latency: same city ~5ms, same continent ~40ms, across the
                 world ~250ms — and that is before your code runs

2. Size          start at 2 CPU / 4 GB for an app plus a database
                 resizing up takes minutes; resizing down is often not possible

3. Image         Ubuntu LTS or Debian stable — long support, wide documentation
                 avoid non-LTS releases: support ends in nine months

4. Access        add your SSH public key during creation
                 do NOT choose password authentication "just for now"

# First connection
ssh [email protected]          # some providers create a non-root user instead

# Immediately confirm what you have
hostnamectl                    # OS, kernel, virtualisation type
nproc && free -h && df -h      # CPU, memory, disk
ip addr show                   # network interfaces and addresses

# Many providers accept cloud-init: the first-boot setup, automated
#cloud-config
users:
  - name: deploy
    groups: [sudo]
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3Nza... ravi@laptop

package_update: true
package_upgrade: true
packages: [ufw, fail2ban, unattended-upgrades]

runcmd:
  - ufw allow OpenSSH
  - ufw --force enable
  - sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
  - sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
  - systemctl reload sshd

Other options worth setting at creation

private networking    free, and how your servers should talk to each other
automatic backups     usually a small percentage of the cost, worth it
monitoring            provider-level CPU, memory and disk alerts
IPv6                  enable it; it costs nothing and some clients need it
hostname              a meaningful name, not the default random string

How it works #

Region choice sets a latency floor. A request from Delhi to a server in Frankfurt spends roughly 250 milliseconds travelling before any processing happens, and no amount of optimisation recovers that.

Size is easy to increase and often impossible to decrease, because shrinking a disk is not safe. Starting small and growing is the practical order.

An LTS image receives security updates for five years. A non-LTS release stops receiving them after nine months, which means an unplanned distribution upgrade on a production machine.

Adding the SSH key at creation means the machine never accepts a password. Providers that email an initial root password are handing you a window during which the server is reachable by a credential that has travelled through email.

Cloud-init runs on first boot and performs the setup automatically. The example creates a user, installs the basics, enables the firewall and disables password and root login — the first hour of manual work, done before you connect.

Private networking is free on most providers and is how an application server should reach its database. Using public addresses for internal traffic is slower, sometimes billed, and unnecessarily exposed.

Real-world use #

Automating creation with cloud-init or a tool such as Terraform means servers are reproducible. Rebuilding is then a known, quick operation rather than an archaeological exercise.

Region selection also carries legal weight. Personal data for European users often must remain in the EU, and similar rules exist elsewhere.

Provider backups are inexpensive and worth enabling, with the caveat from the earlier lesson that they are not a complete backup strategy.

Naming matters more than it seems. app-prod-mumbai-01 tells you what a machine is during an incident; ubuntu-s-2vcpu-4gb-01 does not.

Once a VPS has been configured by hand over several months, nobody remembers how. Capturing the setup as a script or cloud-init file from the start avoids that.

Common mistakes #

• Choosing password authentication at creation "temporarily".
• Selecting a non-LTS image and losing security updates in nine months.
• Picking a region for price alone, adding permanent latency for your users.
• Over-provisioning because downsizing later is usually impossible.
• Configuring everything by hand with no record of what was done.

Practice #

Create a small VPS with an LTS image and your SSH key, in the region closest to your users. Confirm the CPU, memory and disk match what you chose, then write a cloud-init file that would reproduce the same setup automatically.