I've set up a lot of VMs. Some for production workloads, some for testing wild ideas at 11pm, some because a developer messaged us asking "what tier should I use for X?" and I wanted to actually test before answering. That hands-on context is what I'm bringing to this post.
Cloud VMs aren't magic. They're just computers you rent by the month — powerful, flexible ones that don't sit under your desk. But the use cases where they genuinely make your development life better are worth spelling out concretely. Here are ten I see regularly, with specific notes on what works and what to watch out for.
1 — Running a Persistent Development Environment
Your local machine is shared: your browser, Slack, music, and four other projects all compete for CPU and RAM with whatever you're actually trying to build. A cloud VM gives you a dedicated, distraction-free environment that's always on and always ready.
The practical benefit isn't just performance — it's consistency. When you SSH into your Raff
VM and run your project, it behaves exactly the same way it did yesterday, last week, and
three months ago. No accidental brew upgrade that broke your Node version. No OS update
that shuffled your Python path.
A Tier 3 VM (2 vCPU / 4 GB RAM) handles most development environments comfortably — running a dev server, a database, and a background worker simultaneously without swapping. If you're working with larger codebases or running build tools like webpack or esbuild on every save, Tier 4 (4 vCPU / 8 GB RAM) is where compilation times stop being annoying.
2 — CI/CD Pipeline Runners
Running CI jobs on your local machine ties up your machine for the duration of every build. Running them on a shared CI provider means queuing. Running them on a dedicated VM means neither.
A self-hosted GitHub Actions runner or GitLab Runner on a Raff VM gives you a fixed build environment you fully control. You choose the OS, the installed tools, the Node or Python version, and the available memory. There's no "runner unavailable" wait, and there's no per- minute charge that compounds across a team running dozens of builds per day.
For a small team running builds for 2-3 repositories, a Tier 3 VM handles the load well. For teams with parallel jobs or longer compilation steps (Go, Rust, Java), Tier 4 or Tier 5 gives you the vCPU headroom to run multiple jobs concurrently without builds queuing behind each other.
Tip: Pair your CI runner VM with a block storage volume for caching build artefacts and Docker layers between runs. This alone can cut build times by 40-60% on dependency-heavy projects.
3 — Hosting Development and Staging Servers
Sending a teammate a localhost URL is a dead end — they can't access it, and you can't leave your machine running overnight. A cloud VM running your staging environment means anyone with the IP and credentials can hit it at any time.
This is especially useful for:
- Sharing in-progress work with non-technical stakeholders
- Running end-to-end tests against a real server (not a mocked localhost)
- Keeping a stable staging environment separate from your local dev loop
- Webhooks that need a real public endpoint (Stripe, GitHub, Slack integrations)
A Tier 2 VM (1 vCPU / 2 GB RAM) is enough for most staging environments. You're not handling real traffic — just QA, demos, and integration tests.
4 — Self-Hosted Automation with n8n
n8n is an open-source workflow automation tool — think Zapier, but self-hosted. It connects APIs, triggers actions on schedules, processes webhooks, and chains together workflows that would otherwise require a custom script for every integration.
Running n8n on a cloud VM means your automations run 24/7 without keeping your laptop open. We've seen this use case grow significantly among developers who want automation power without the per-task pricing of SaaS tools.
Raff offers a dedicated n8n VM image that gets you running in minutes. For most automation workloads, a Tier 2 or Tier 3 VM is sufficient — n8n is lightweight unless you're processing very large payloads or running dozens of concurrent workflows.
Tip: Enable automated backups on your n8n VM. Your workflow configurations and credentials are stored on disk — a daily backup costs almost nothing and means you can restore a full working environment in minutes if something goes wrong.
5 — Isolated Experiment Environments
Testing a new database, trying a different web server configuration, running a beta version of a framework — these experiments have a way of leaving traces on your local machine that cause problems weeks later.
A cloud VM gives you a genuinely isolated environment. You can install whatever you want, break whatever you want, and either fix it or destroy the VM and create a fresh one from a snapshot. The experiment stays contained.
The workflow I recommend: before you start an experiment, take a snapshot of the VM. Run your experiment. If it works, keep going. If it breaks, restore the snapshot and you're back to a clean state in under a minute.
Raff's snapshot feature is available on all tiers at no fixed cost — you pay only for the storage the snapshot uses.
6 — Learning Linux and Server Administration
If you want to get serious about Linux, DevOps, or cloud infrastructure, you need a real server to practice on. Your local VM is fine for basics, but it doesn't replicate the experience of managing a remote machine: SSH access, firewall rules, service management, log monitoring, disk management.
A Tier 1 VM ($3.99/month, 1 vCPU / 1 GB RAM) is enough for learning. It runs Ubuntu or Debian comfortably, handles all the standard tooling, and costs less than a coffee per week. The 7-day free trial means you can run through an entire learning project before spending anything.
Common things developers practice on a dedicated cloud VM:
- Configuring Nginx or Apache as a reverse proxy
- Setting up SSL certificates with Let's Encrypt
- Managing systemd services
- Configuring UFW firewall rules
- Setting up SSH key authentication and disabling password login
- Monitoring disk usage, process lists, and system logs
These skills don't transfer from reading — you need to break things and fix them on a real server.
7 — Running Databases Separately from Application Servers
A common mistake in early-stage projects is running your database on the same VM as your application. It works until it doesn't — a memory spike from your application kills your database, or a misconfigured query runs the CPU to 100% and takes down both.
Separating your database onto its own VM, connected via private networking, gives each layer its own resources and makes both easier to scale independently.
A dedicated database VM on Tier 3 or Tier 4 (depending on data size and query load) with a block storage volume attached for the data directory is a reliable setup that mirrors how production environments are actually built.
Note: Use Raff's private network (VPC) to connect your application VM and database VM. Traffic between VMs on the same private network doesn't leave the data centre — it's faster and more secure than connecting over a public IP.
8 — Deploying and Testing Docker Workloads
Docker is easier to learn and manage on a cloud VM than on a local machine. You get a consistent Linux environment, no macOS networking quirks, no Docker Desktop memory limits, and a public IP so you can test containers that expose ports.
A Tier 3 VM comfortably runs a multi-container Docker Compose stack — a web app, a database, and a cache — with room to spare. If you're building container images as part of your workflow, the faster NVMe I/O on Raff VMs makes layer reads and writes noticeably quicker than on slower storage backends.
For developers learning Docker for the first time, starting with a Raff VM removes a lot of the environment-specific friction that makes local Docker setups frustrating.
9 — Web Scraping and Long-Running Scripts
Scripts that take hours to run — web scrapers, data processors, bulk API callers — can't live on your local machine. Your laptop goes to sleep. The VPN disconnects. You need the terminal tab to stay open.
A cloud VM runs your scripts 24/7 with no interruptions. SSH in, start your script in a
tmux or screen session, disconnect, and come back when it's done. The process keeps
running regardless of what happens on your local machine.
For scraping and data processing workloads, the right tier depends on how CPU-intensive your processing is. Pure I/O-bound scrapers run fine on Tier 2. If you're doing heavy parsing, image processing, or running headless browsers (Playwright, Puppeteer), Tier 3 or Tier 4 gives you the CPU to handle concurrent workers without throttling.
10 — Building Your Portfolio: Always-On Project Hosting
Side projects that only run when your laptop is open aren't impressive to show people. A cloud VM that hosts your project at a real domain, with HTTPS, running 24/7 — that's something you can put on a resume and send to a hiring manager at midnight.
A Tier 2 VM ($9.99/month) running Nginx, a Node.js or Python app, and a small database handles portfolio-scale traffic comfortably. Add a free SSL certificate from Let's Encrypt, point your domain, and your side project looks like a real product.
This is one of the most underrated uses of a cheap cloud VM — the professional credibility of having your work actually live on the internet, not just in a GitHub repo.
What This Means for You
The pattern across all ten use cases is the same: a cloud VM gives you a computer that's always on, always available, and completely yours to configure. It removes the constraints of your local machine — power management, shared resources, environment pollution — without adding complexity.
Most of the use cases above work fine on a Tier 2 or Tier 3 Linux VM. Start there, watch your actual CPU and RAM usage for a week, and resize up if the numbers tell you to. Raff's monthly billing means you're not locked into anything.
If you're not sure which tier fits your specific use case, the pricing page has the full breakdown. Or just try it — the 7-day free trial gives you enough time to run through a real workload and see how it performs.