Deploying Your First Cloud Server: A Practical Checklist
A practical checklist for deploying a first cloud server on DigitalOcean, Vultr, Hetzner, or any VPS provider: region, image, sizing, SSH hardening, firewalls, private networking, backups, and alerts.
The first cloud server most people deploy is also the one they secure the least. The console makes it easy to get a public IP in a minute, and that speed hides decisions that are hard to undo later: region, image, login method, firewall rules, and how you will notice when the bill or the disk fills up. This checklist walks through those decisions in the order they come up on DigitalOcean Droplets, Vultr Cloud Compute, Hetzner Cloud, and most other VPS style providers, and it applies equally to an EC2 instance or an Azure VM.
Before you click Create
Three things should exist before the server does. The first is an SSH key pair on your workstation, because every serious provider lets you attach a public key at creation time and skip password login entirely. The second is a decision about the region. Pick the location closest to your users, not to you, and check that the region offers the server type and any extras you need, since block storage, load balancers, and GPU plans are not always available everywhere. The third is a budget alert or spending limit in the billing section of the account, so that a forgotten server or an attached volume shows up as a notification rather than a surprise on the invoice.
Also confirm the account’s server limit. New DigitalOcean accounts start with a cap on Droplets, Hetzner Cloud projects have a server limit, and Vultr applies similar account level limits. These caps are raised on request through the provider’s support or limit increase form, so ask early if your plan needs more servers.
Choosing the image and the size
Start with a current long term support Linux image from the provider’s official catalog. Ubuntu LTS, Debian stable, Rocky Linux, and AlmaLinux are offered by DigitalOcean, Vultr, and Hetzner in close to identical form, and they receive security updates for years. One-click images that bundle an application stack save setup time but often lag on package versions, so treat them as a starting point you will still maintain.
Size the server for the workload you have today, not the one you imagine in a year. Resizing upward is a supported operation on all three providers (with a short shutdown), and it is much cheaper to grow than to pay for idle RAM for months. Memory heavy workloads such as databases belong on memory optimized plans. If load is bursty, a shared vCPU plan is usually fine; steady CPU bound work belongs on a dedicated vCPU plan. The article on what a vCPU means for sizing goes into the difference.
| Decision | Safe default | Change it when |
|---|---|---|
| Operating system | Latest Ubuntu LTS or Debian stable from the official catalog | Your stack requires a specific distribution or kernel |
| Plan type | Smallest shared vCPU plan that fits RAM needs | Sustained CPU load, databases, or latency sensitive services |
| Storage | Root disk only; add a volume later | Data must survive a rebuild or exceed the root disk |
| Networking | Public IPv4 plus IPv6, private network enabled | Several servers need to talk without crossing the public internet |
| Backups | Provider backups enabled at creation | You already run your own snapshot schedule |
The first login and basic hardening
Log in over SSH with your key as root or as the default image user, then do the basics immediately. Update the package index and apply all pending updates, since the image was built some time ago. Create a regular user, add it to the sudo group, and copy your public key into that user’s authorized keys. Then edit the SSH daemon configuration to disable password authentication and root login, and restart the service while keeping your current session open so you can test a fresh connection before you close the old one.
Enable automatic security updates (the unattended upgrades package on Debian and Ubuntu, dnf automatic on Rocky and AlmaLinux), and install a small monitoring agent if your provider offers one. DigitalOcean has a metrics agent that feeds console graphs and alerts, Vultr and Hetzner expose basic CPU, network, and disk graphs from the hypervisor without an agent. This takes minutes and removes the most common ways a new server is compromised in its first week.
Firewall, ports, and the private network
Every server should sit behind two firewalls: one on the host and one at the provider edge. On the host, ufw on Ubuntu and Debian or firewalld on Rocky and AlmaLinux is enough: allow SSH, allow the ports your application actually serves (typically 80 and 443), and deny everything else inbound. At the provider edge, DigitalOcean Cloud Firewalls, Vultr Firewall groups, and Hetzner Cloud Firewalls are free and apply before traffic reaches the virtual NIC, which means a misconfigured service listening on all interfaces is still not reachable from the internet.
Restrict SSH to your own IP ranges if they are stable, or at least to a bastion host. Never open database ports to the world. If a second server needs to reach the database, put both on the provider’s private network (VPC on DigitalOcean and Vultr, a private Network on Hetzner) and bind the database to the private address only.
Outbound port 25 deserves a mention because new accounts on nearly all providers block or restrict it to control spam. This is a deliberate provider policy, not a bug. If the server needs to send mail, use an authenticated relay such as Amazon SES on port 587, or follow the provider’s documented process for requesting SMTP access and comply with their acceptable use policy. The Cloud Library covers why providers restrict port 25 in detail.
Backups, snapshots, and knowing when something breaks
DigitalOcean, Vultr, and Hetzner all offer automatic backups as a percentage surcharge on the plan, taken on a schedule you do not have to manage. Snapshots are the manual counterpart: take one before any risky change such as a distribution upgrade or a database migration. Neither replaces an off-provider copy, so also push database dumps and uploads to object storage on a schedule and test a restore.
For alerting, start with the provider’s built in metrics: sustained high CPU, disk usage above a threshold, and the server going unreachable. Add an external HTTPS uptime check, because a server that is up but serving errors looks healthy from the hypervisor. Finally, configure log rotation so that verbose application logs cannot fill the root disk, a common cause of a server that stops working months after launch.
- Automatic backups
- Enable at creation; provider managed, scheduled, priced as a surcharge on the plan
- Snapshots
- Manual point in time copies; take one before every risky change
- Off-provider copy
- Database dumps and uploads to object storage, with a tested restore
- External uptime check
- HTTPS probe from outside the provider network, alerting on failure
Where to go next
If you are still choosing a provider, common picks for a single VPS are DigitalOcean for its documentation and tooling, Vultr for its wide set of locations and plan types, and Hetzner Cloud for price to performance in its European and US regions. The marketplace lists DigitalOcean accounts with different Droplet limits, Vultr accounts with credit balances, and Hetzner accounts with five or ten server limits, with the exact variant labels on each page.
For the next steps after the checklist, read the guide on generating, adding, and rotating SSH keys, then the deeper article on firewalls, Fail2ban, and automatic updates. When you are ready to run containers, the guide to Docker on a cloud VPS picks up where this one ends. All of these live in the Cloud Library.