From localhost to VPS: why i stopped editing directly on servers and adopted modern SaaS workflows
Back to blog

From localhost to VPS: why i stopped editing directly on servers and adopted modern SaaS workflows

9/14/2026 · 3 min · DevOps

Anyone building and operating web applications has faced this foundational question: what is the most sustainable development workflow today?

Is it better to spin up an entire stack on a cloud VPS (Docker, database, runtime) and edit files directly over SSH, or is the optimal standard still developing 100% on localhost and deploying validated builds to the server?

If you have ever felt tempted to open a remote SSH terminal to hotfix code directly in production, you know how easily things can go wrong. Below, I break down both approaches, their trade-offs, and the workflow structure I use to maintain velocity and uptime.


1. The dilemma: remote editing on a VPS vs. local development#

When establishing a workflow, there are two primary architectures:


When does remote VPS development make sense?#

Direct SSH development has specific valid use cases:

  1. Severely constrained local hardware: If your physical workstation lacks sufficient RAM or CPU power to run multiple heavy containers simultaneously.
  2. Dedicated staging environments: For verifying external webhooks, valid SSL certificates, or third-party payment gateways requiring publicly accessible URLs.

The risks of editing on remote servers:#


2. Local development with decoupled deployment: the reliable standard#

The rule I follow is straightforward: build, test, and break everything locally; deploy only tested, validated code to the VPS.

Thanks to containerization with Docker, the classic "it works on my machine" problem is easily eliminated.

Practical benefits of working on localhost:#


3. Practical implementation and division of roles#

To maintain parity between local machines and production servers cleanly:

On the local machine (development):#

# Simple local docker-compose.dev.yml
services:
  app:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
    environment:
      - NODE_ENV=development
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: dev_password
      MYSQL_DATABASE: saas_dev
    ports:
      - "3306:3306"

On the remote server (production):#


Conclusion: the golden rule for SaaS stability#

Editing code directly on live servers over SSH might look like a tempting shortcut, but the cost of an unexpected production outage far outweighs the convenience.

Keeping the sandbox where you test and experiment completely separated from the infrastructure where real customers transact is essential for building a reliable, stress-free web product.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

CC BY-NC

This post is licensed under CC BY-NC.

Comments

Join the discussion below.

0 comments