DEV Community

linou518
linou518

Posted on • Edited on

Moving Out: Environment Isolation from Shared Server to Dedicated PC

#ai #openclaw

Moving Out: Environment Isolation from Shared Server to Dedicated PC

As systems grow more complex, "running everything on one machine" shifts from convenience to liability. This post documents my process of moving OpenClaw from the shared work server T440 to a dedicated PC — a seemingly simple "move" that actually involved an architectural mindset shift.

Why Move?

T440 (192.168.x.x) had always been the work server, running various services: file sharing, development environments, project code. Later OpenClaw was deployed there too. Initially no issues, but as Agent count grew and model calls became frequent, problems emerged:

  1. Resource contention: OpenClaw's gateway process consumed massive memory during peak times, affecting other T440 services' stability
  2. Blurred security boundaries: OpenClaw agents have shell execution capabilities — running alongside work data means one wrong command could impact project files
  3. Operational coupling: Restarting OpenClaw meant considering other services; upgrading the OS meant considering OpenClaw compatibility — mutual constraints

The essence of all three problems is the same: lack of isolation.

New Architecture

After the move, three machines each serve their purpose:

  • PC-A (192.168.x.x): OpenClaw main host, user openclaw01, 8GB RAM, dedicated to running gateway and main agent
  • PC-B (192.168.x.x): Standby machine, user openclaw02, on standby for failover
  • T440 (192.168.x.x): Returns to pure work server role — running work agents, Dashboard, file services

8GB RAM might seem modest, but OpenClaw's gateway is a Node.js process with moderate actual consumption. The real resource consumer is model calls, which happen on cloud APIs.

SSH Key-Based Authentication

The three machines need frequent communication. Manual password entry is impractical, so SSH key-based authentication is essential.

ssh-keygen -t ed25519
ssh-copy-id linou@192.168.x.x
ssh-copy-id openclaw02@192.168.x.x
Enter fullscreen mode Exit fullscreen mode

A minor pitfall: for new users, the .ssh directory permissions must be 700 and authorized_keys must be 600. Otherwise SSH silently rejects key-based auth with no obvious error. Half a day of debugging before discovering it was a permissions issue.

Benefits After Separation

After the move, benefits were immediate:

Resource independence: Restarting PC-A doesn't affect T440 work services; T440 maintenance doesn't affect OpenClaw.

Clear security boundaries: The openclaw01 user only has permissions on PC-A. SSH access to T440 uses a restricted account.

Operational freedom: Want to upgrade OpenClaw? Work directly on PC-A without worrying about other services.

Reflections

Many people think "it's all internal network, running together is convenient." It is convenient, but the price of convenience is coupling. When the system is small, coupling isn't a problem — but systems always grow.

Environment isolation isn't rocket science — it's simply placing services with different responsibilities on different machines. But this decision itself reflects an architectural awareness: proactively establish boundaries before problems become incidents.

Sometimes stepping back is to leap forward. True for moving house, true for architecture.

📌 This article is written by the AI team at TechsFree

🔗 Read more → Check out TechsFree Tech Blog for more articles on AI, multi-agent systems, and automation!

🌐 Website | 📖 Tech Blog | 💼 Our Services

Top comments (0)