Your First Cloud Server: What to Do After You Provision It

Introduction

You provisioned a cloud server — now what? The server is running, you have an IP address, and you can connect. But a freshly created VM is like moving into a new apartment: the door is unlocked, the utilities are not set up, and there is no alarm system. This guide gives you the post-provisioning checklist in the right order so you do not skip a step that costs you later.

Raff Technologies provisions new VMs in under 60 seconds with a public IP, root access, and a clean OS image. What happens in the first 30 minutes after provisioning determines whether your server stays secure or becomes part of a botnet. Automated scanners find new public IPs within minutes and start probing SSH, HTTP, and database ports immediately. This is not a hypothetical risk — our monitoring shows an average of 2,500 unauthorized SSH attempts per day against a new VM within the first 24 hours.

This guide covers the complete post-provisioning workflow in the order that matters: access, updates, user setup, firewall, SSH hardening, monitoring, backups, and first deployment. Each section links to a detailed step-by-step tutorial if you need the specific commands.

The Checklist at a Glance

Before diving into each section, here is the full checklist. Each item links to the detailed explanation below and to the relevant tutorial where applicable.

1. First login and orientation
2. Update the operating system
3. Create a non-root user
4. Set up SSH key authentication
5. Disable password and root login
6. Configure the firewall
7. Set up automated updates
8. Enable monitoring
9. Configure backups
10. Deploy your first application

The first six items are security-critical and should be completed before you deploy anything. Items 7-9 are operational hygiene. Item 10 is where the fun starts.

First Login and Orientation

When you first connect to your server, you are logged in as root with either a password or an SSH key, depending on how you set up the VM. The first thing to do is verify where you are and what you are working with.

Check the OS version, available resources, and network configuration. This confirms that the VM matches what you ordered and that networking is functional. On a Raff VM, you will see the AMD EPYC processor, your allocated RAM, and NVMe SSD storage.

If you chose Ubuntu 24.04 (the most popular choice among Raff customers), you are on a long-term support release with security updates guaranteed through 2029. This is the right choice for production servers.

What to check:

• OS version and kernel
• Available CPU cores and RAM
• Disk size and mount points
• Public and private IP addresses
• DNS resolution

If anything does not match your expected configuration, contact support before proceeding. It is easier to fix provisioning issues on a fresh server than after you have deployed applications.

Update the Operating System

A fresh OS image may be days or weeks behind on security patches. Package updates are the single most important step you can take — most server compromises exploit known vulnerabilities that already have patches available.

Update the package index and upgrade all installed packages. On Ubuntu, this means apt update followed by apt upgrade. Reboot if the kernel was updated, since the old kernel remains in memory until reboot.

This step takes 2-5 minutes depending on how many packages need updating. Do it before any other configuration because some packages you install later depend on updated libraries.

Detailed commands: Follow Step 1 of our server security tutorial.

Create a Non-Root User

Running everything as root means every mistake is permanent and every compromised service has full system access. Create a regular user with sudo privileges for daily operations. Use root only for initial setup and emergencies.

Choose a username that is not easily guessable (avoid admin, user, deploy). Add the user to the sudo group so they can run administrative commands when needed, but default to unprivileged operation.

Why this matters: If an attacker gains access to a non-root user, the blast radius is limited to that user's files and permissions. If they gain root, they own the entire server. Defense in depth starts with this separation.

Detailed commands: Follow Step 2 of our server security tutorial.

Set Up SSH Key Authentication

Passwords are the weakest link in server security. They can be brute-forced, phished, or guessed. SSH keys use asymmetric cryptography — a private key on your local machine and a public key on the server. Without the private key file, access is impossible regardless of how many login attempts an attacker makes.

Generate a key pair on your local machine (not on the server). Copy the public key to the server. Test that key-based login works before disabling passwords.

Common mistake: Generating the SSH key on the server instead of your local machine. The private key should never exist on the server.

Detailed commands: See our SSH key setup tutorial.

Disable Password and Root Login

Once you have confirmed that SSH key authentication works for your non-root user, disable password authentication and direct root login. This eliminates the entire category of brute-force attacks — there is no password to guess.

Edit the SSH daemon configuration to set PasswordAuthentication no and PermitRootLogin no. Restart the SSH service and test from a new terminal before closing your existing session.

Detailed commands: Follow Step 3 of our server security tutorial.

Configure the Firewall

A firewall controls which ports accept incoming connections. Without one, every service you run is exposed to the internet. The principle is simple: deny everything by default, then allow only the ports you need.

For most servers, you need three ports open: SSH (22), HTTP (80), and HTTPS (443). Everything else should be blocked. If you run a database, it should listen only on localhost or a private network, never on a public port.

Ubuntu ships with UFW (Uncomplicated Firewall), which makes this straightforward. Enable UFW with default deny and explicit allows for SSH, HTTP, and HTTPS. Order matters — allow SSH before enabling the firewall, or you lock yourself out.

Detailed commands: See our UFW firewall tutorial.

Additional protection: Install fail2ban to automatically ban IPs that repeatedly fail SSH authentication. This reduces log noise and blocks persistent scanners.

Set Up Automated Security Updates

Security patches are published regularly, and the window between a vulnerability disclosure and active exploitation is shrinking — sometimes to hours. Automated security updates ensure critical patches are applied without waiting for you to log in and run them manually.

On Ubuntu 24.04, the unattended-upgrades package handles this. Configure it to install security updates automatically and optionally reboot when required. Set the reboot time to a low-traffic period.

This is not a substitute for planned maintenance — automated updates handle security patches, but you should still schedule regular full upgrades and test them in a staging environment first.

Enable Monitoring

You cannot fix what you cannot see. At minimum, monitor CPU utilization, memory usage, disk space, and network traffic. These four metrics tell you whether your server is healthy, overloaded, or being attacked.

There are three approaches depending on your needs:

Basic (built-in): The Raff dashboard provides CPU, network, and disk I/O graphs for every VM. This is sufficient for a single server running a simple application.

Intermediate (self-hosted): Install Prometheus and Grafana on the same VM or a dedicated monitoring VM. This gives you historical data, custom dashboards, and alerting. Most Raff customers running 2-5 VMs use this approach.

Lightweight (uptime only): Deploy Uptime Kuma for external availability monitoring. This checks whether your services respond and sends alerts when they go down.

Choose the level that matches your current needs. You can always upgrade later. The worst option is no monitoring at all.

Configure Backups

Backups are not optional. Hardware fails, code has bugs, and humans make mistakes. The question is not whether you will need a restore — it is whether you will have something to restore from.

Raff offers two complementary backup mechanisms:

Snapshots capture the complete state of your VM at a point in time. They are fast to create and fast to restore. Use on-demand snapshots before major changes (OS upgrades, database migrations, new deployments). See our guide on snapshots vs backups for when to use each.

Automated backups run on a schedule (daily, weekly, monthly) with configurable retention. Enable automated daily backups from the Raff dashboard data protection page.

Application-level backups are your responsibility. For databases, schedule regular dumps. For application files, sync to Raff Object Storage using our backup automation tutorial.

The key principle: your data should exist in at least two places at all times. A VM snapshot plus an off-server backup to object storage covers most failure scenarios.

Deploy Your First Application

With security, monitoring, and backups in place, you are ready to deploy. The deployment approach depends on what you are building:

Static sites and simple apps: Install Nginx or Caddy as a web server, add SSL with Let's Encrypt, and serve your files directly.

Node.js applications: Install Node.js and use a process manager like PM2 for production. See our tutorial on deploying Node.js with PM2 (coming soon).

Python/Django applications: Set up a virtual environment, Gunicorn as the WSGI server, and Nginx as the reverse proxy. See our tutorial on deploying Django (coming soon).

WordPress and PHP: Install a LEMP stack (Nginx, MariaDB, PHP) and then WordPress.

Containerized apps: Install Docker and manage containers with Docker Compose or Portainer.

Self-hosted tools: Deploy n8n for automation, Nextcloud for file sync, Gitea for Git hosting, or Uptime Kuma for monitoring.

When to Scale Up

Start with the smallest server that fits your workload. Monitor usage for a week. If CPU utilization stays above 70% or RAM is consistently above 80%, it is time to resize.

Raff VMs support instant resize — you power off, change the tier, and power back on. Your data stays intact. No migration, no new IP address. Start with a General Purpose VM for development and testing, then move to CPU-Optimized when you need consistent performance for production.

The most common mistake beginners make is overprovisioning. A 2 vCPU, 4 GB RAM server ($19.99/month on Raff CPU-Optimized) handles far more than most people expect. Our data shows that 65% of customers running web applications stay on Tier 2 or Tier 3 for over six months before needing to upgrade.

Conclusion

The first 30 minutes after provisioning determine the security and reliability of your server. Follow the checklist in order: update, create a user, set up SSH keys, disable passwords, configure the firewall, enable monitoring, and set up backups. Only then deploy your application.

This guide serves as the starting point for the Getting Started cluster of the Raff Learn Hub. For the specific commands behind each step, follow the linked tutorials. For deeper understanding of the decisions involved, explore our guides on cloud security fundamentals, choosing the right VM size, and self-hosting applications.

Every recommendation in this guide comes from what we see operating Raff's infrastructure. The 2,500 daily SSH attempts, the 65% of customers on Tier 2-3, the 15-minute security setup — these are real numbers from our platform, not generic advice.