Local VM vs Cloud VM for Development
A practical comparison of local and cloud-based development VMs, based on real experience moving a VSCode Remote SSH workflow from VMware to Google Cloud.
When I started building my startup, one of the first infrastructure decisions was where my development environment should live.
There are two obvious options:
- run a local development machine
- run a cloud-based development machine
At first I assumed the local option would be simpler. In practice, my experience turned out differently.
This article describes my move from a local VM to a cloud VM, and why I eventually settled on a standard virtual machine on Google Cloud.
The starting point: a local development VM
My first setup used a local virtual machine running on VMware Workstation Pro. Since VMware became free for personal use and is easy to download, it looked like an attractive choice for development.
The VM configuration was:
- OS: Debian 13
- RAM: 8 GB
- CPU: 2 vCPUs
- Hypervisor: VMware Workstation Pro
My workflow looked like this:
Laptop (VSCode)
|
| Remote Development (SSH)
v
Linux development server
I use VSCode Remote Development so the laptop stays clean while dependencies, tools, and project setup live on the remote machine. I still think this workflow is excellent regardless of whether the machine is local or cloud-hosted.
Where the local VM started to break down
Even with a relatively small codebase, the local VM felt slower than expected.
The difference was most noticeable when using IDE extensions, especially AI-assisted tools such as Codex or Amazon Q. Typical problems included:
- slow code analysis
- slower extension response times
- noticeable delays when interacting with tools
- generally sluggish system behavior
Although the VM had 8 GB of RAM, the experience felt roughly twice as slow as the cloud VMs I tested. The slowdown also affected other applications on my laptop, which made the whole setup less comfortable to use throughout the day.
At that point, it became clear that keeping the development environment local was not the best fit for my workflow.
Moving development into Google Cloud
Because my startup already uses Google Cloud, moving development into GCP felt like the natural next step.
I created a Debian-based VM with this configuration:
- machine type:
e2-standard-4 - CPU: 4 vCPUs
- memory: 16 GB
- OS: Debian
To reduce costs, I initially used Spot instances.
Region choice did not matter much in practice
Spot instances depend on spare capacity, so I tested several zones:
us-central1-aus-central1-cus-central1-f
In practice, performance across those zones felt very similar for this kind of workload.
The cloud VM was immediately faster
Moving to a cloud VM improved development speed right away.
The differences were easy to notice:
- faster IDE responsiveness
- faster plugin execution
- faster code analysis
- smoother overall development
The machine cost roughly $50 per month if it stayed up most of the time. For the performance gain, that felt reasonable.
Why Spot instances did not work well for development
Spot instances have a major downside: they can be terminated at any time when the provider needs the capacity elsewhere.
In practice, I saw around three to four interruptions per day during a normal eight to ten hour workday.
The VM could usually be restarted immediately, but sometimes it was terminated again almost right away. That made the development workflow unpredictable in exactly the way I wanted to avoid.
Dynamic DNS helped, but did not remove reconnection friction
To avoid manually updating the IP address in VSCode after every restart, I used a dynamic DNS setup.
That let me connect to the VM through a hostname instead of a raw IP address. It worked, but it introduced another small delay: after a restart, DNS changes still needed time to propagate. In my experience, reconnecting often took another one to two minutes.
That delay was not huge on its own, but combined with repeated Spot interruptions it added unnecessary friction to the workday.
Switching to a standard VM solved the main problem
After several months on Spot instances, I switched to a standard VM. The machine configuration stayed the same:
- 4 vCPUs
- 16 GB RAM
- Debian
The cost of a standard VM is roughly $100 per month if it runs continuously, but the experience became stable immediately because the interruptions disappeared.
Cost control with automatic shutdown
To keep the cost reasonable, I added a simple idle shutdown script. The VM powers off when:
- CPU usage stays very low
- network traffic is negligible
- no SSH sessions are active
That means the machine runs only when I am actually using it.
In practice, this gave me the best balance:
- no development interruptions
- good performance
- a clean local machine
- costs that stay proportional to actual usage
Final setup
My current workflow looks like this:
Laptop (VSCode)
|
| Remote Development (SSH)
v
GCP Standard VM (Debian)
This setup gives me:
- a stable development environment
- consistent performance
- no interruption from capacity reclaim events
- a cleaner personal laptop
Takeaways
The main lesson from this experiment was simple: local VMs can be convenient, but they are not automatically the best choice for day-to-day development.
For my workflow:
- a local VM was easy to start with, but felt resource constrained
- a cloud VM delivered better performance at an added cost
- Spot instances were fine in theory, but too disruptive for interactive development
- a standard VM with automatic shutdown ended up being the best compromise
If your development setup depends heavily on remote tooling, AI-assisted IDE features, or a consistently responsive Linux environment, a standard cloud VM may be a much better long-term choice than a local virtual machine.