Private Cloud Manager

Private Cloud Manager is a local-first VM control plane for VMware Workstation Pro. It turns a workstation-based private cloud into a real operator platform with inventory, APIs, jobs, audit logs, browser SSH, and an AI tool layer through OpenClaw.

It combines:

• a React frontend for inventory, jobs, audit, authentication, and browser-based SSH
• an Express backend for orchestration, VMware control, VM activity tracking, and audit logging
• an OpenClaw plugin so a local Ollama-powered assistant can operate the platform through structured tools

Highlights

• Live VM power state in the dashboard
• Per-VM last online and last SSH login activity indicators
• Managed update action for Ubuntu, Debian, Kali, and Windows with OS version, last updated, and reboot-required visibility
• On-demand security change feed with kernel/core package highlights before patching
• Frontend-to-backend API traffic telemetry chart for live operator activity volume
• Automatic OS metadata refresh on interactive SSH connect
• Job-based start and stop orchestration with logs and timestamps
• Audit view for operator actions and API activity
• Token-gated web interface
• Editable SSH connection details from the dashboard
• Lab preset buttons for Blue Team, Red Team, Purple Team, and WG-VPN
• Multi-tab browser SSH workspace with same-VM parallel tabs
• Auto boot-and-connect flow for powered-off VMs
• Clickable reboot-required badge with soft/hard reboot actions
• Cyber news feed with modal story view and curated RSS aggregation
• Fixed in-view navigation for jumping between overview, charts, runbooks, SSH, and inventory
• Two-plane VM management with separate Guest and VMware Workstation views
• UI-based VM registration for existing VMX paths plus VMware Workstation provisioning from ISO with CPU, RAM, disk, and network inputs
• Delete VM flow with an explicit choice between PCM-only removal and full VMware Workstation delete-from-disk
• OpenClaw integration on top of the same backend used by the UI

Why I Built It

Once a local lab grows past a few VMs, operating everything through the VMware GUI, one-off shell commands, and scattered notes becomes noisy and fragile. I wanted the same qualities we expect from internal platform tooling, but applied to a local VMware environment:

• centralized inventory
• consistent APIs
• observable jobs
• browser-based access
• auditability
• AI-assisted operations without direct shell trust

Screenshots

Add screenshots to docs/screenshots/ and update the image paths below.

VM Inventory

Jobs View

Browser SSH Workspace

OpenClaw Tool Use

Architecture

frontend/

React + Vite + TypeScript + React Query + Tailwind CSS + xterm

Responsibilities:

• display VM inventory and live power state
• expose token-gated access to the operator UI
• show jobs, logs, and audit activity
• show job volume and API traffic telemetry
• let operators update SSH connection details
• let operators manage VMware Workstation profile data such as CPU, memory, ISO, and network mode
• trigger managed Linux and Windows server updates
• refresh OS family, version, and reboot-needed state on SSH connect
• provide a multi-session browser SSH workspace

backend/

Express + TypeScript + Prisma + SQLite + ssh2 + ws

Responsibilities:

• persist VM inventory directly in the database
• expose VM, job, audit, and readiness APIs
• execute VMware operations through vmrun
• provision VMware Workstation VMs from ISO-backed specs and persist separate Workstation profile metadata
• run managed Linux and Windows update jobs
• refresh remote OS metadata on successful interactive SSH login
• expose lightweight in-memory API traffic metrics for dashboard charts
• process background job handlers
• expose interactive SSH sessions over WebSocket
• record audit events and VM activity timestamps

openclaw-plugin-private-cloud-manager/

OpenClaw plugin that exposes the backend as tools:

• pcm_list_vms
• pcm_create_vm
• pcm_update_vm_settings
• pcm_delete_vm
• pcm_start_vm
• pcm_stop_vm
• pcm_ssh_exec
• pcm_get_job_status
• pcm_update_vm
• pcm_get_update_feed
• pcm_update_vm_workstation
• pcm_rotate_security_updates
• pcm_fire_lab
• pcm_stop_lab

This lets a local OpenClaw assistant running on top of Ollama interact with the same backend APIs used by the frontend.

How Prisma and the Database Work

Prisma is the ORM layer that defines and accesses the local SQLite database used by the backend.

The project uses a local SQLite file:

backend/dev.db

The main records are:

• VM: normalized VM inventory plus live operational metadata
• Job: queued, running, failed, and completed operations
• JobLog: execution logs for each job
• AuditEvent: traceable operator and API actions

The database is now the only source of truth for VM inventory.

That means:

1. VMs live in Prisma + SQLite
2. the backend does not import a startup inventory file
3. the frontend and OpenClaw plugin read and modify the same database-backed VM records
4. VM edits survive backend restarts because there is no boot-time overwrite from inventory.json

You can add and edit VMs from:

• the web UI
• the POST /api/vms and PATCH /api/vms/:id/settings APIs
• OpenClaw tools such as pcm_create_vm and pcm_update_vm_settings
• OpenClaw tools such as pcm_create_vm, pcm_update_vm_settings, pcm_update_vm_workstation, and pcm_delete_vm

Project Structure

.
├─ frontend/
├─ backend/
├─ openclaw-plugin-private-cloud-manager/
└─ docs/

Local Setup

Prerequisites

• Node.js installed
• VMware Workstation Pro installed on the host machine
• vmrun.exe available at the path expected by the backend
• Ollama installed locally if you want the AI integration
• OpenClaw installed locally if you want the AI tool workflow
• SSH enabled on guest VMs you want to access or update through the dashboard

Backend

cd backend
npm install
npx prisma generate
npx prisma db push
npm run dev

Default backend URL:

http://127.0.0.1:8000

Important backend notes:

• API auth uses a bearer token
• if API_TOKEN is not set, the default fallback is dev-token
• set PCM_SECRET_KEY in real deployments so VM SSH passwords are encrypted at rest with a dedicated key instead of falling back to the API token
• the backend tracks VM state, SSH readiness, jobs, and audit activity
• the backend also exposes lightweight API traffic metrics for the dashboard
• Ubuntu, Debian, Kali, and Windows VMs can be updated through a managed job instead of ad hoc SSH commands
• managed Linux and Windows VMs can expose an on-demand package/security change feed that highlights kernel, cumulative, servicing-stack, and other critical package updates before patching when classification is available
• interactive SSH logins refresh lastSshLoginAt, OS family, OS version, and reboot-required state

Frontend

cd frontend
npm install
npm run dev

Default frontend URL:

http://127.0.0.1:5173

The frontend asks for the backend token at login and stores it in the browser for the current operator session.

The dashboard now also includes:

• compact fleet metric cards
• Chart.js-based job volume and API traffic charts
• a cyber news feed with story modal drill-down
• a retractable sidebar for denser operator workflows
• write-only password fields for VM SSH credentials; stored secrets are not returned by the API

Ollama

Install and start Ollama locally, then pull at least one model that behaves reasonably with tools.

Example:

ollama serve
ollama pull qwen2.5:7b-instruct-q4_K_M

Default Ollama URL used by OpenClaw:

http://127.0.0.1:11434

Models can vary a lot in tool-following quality. In practice, smaller models may still invent recap text around correct tool calls, so test and compare.

OpenClaw

Install OpenClaw locally and point it at your local Ollama instance.

Core pieces to configure:

1. Model provider:

{
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434",
        "api": "ollama"
      }
    }
  }
}

2. Workspace:

{
  "agents": {
    "defaults": {
      "workspace": "C:\\Users\\<you>\\.openclaw\\workspace"
    }
  }
}

3. Plugin loading and allowlist:

{
  "plugins": {
    "allow": [
      "private-cloud-manager"
    ],
    "load": {
      "paths": [
        "D:\\Projects\\private-cloud-manager\\openclaw-plugin-private-cloud-manager"
      ]
    }
  }
}

OpenClaw Plugin

Install the local plugin:

openclaw plugins install -l D:\Projects\private-cloud-manager\openclaw-plugin-private-cloud-manager

Example plugin config:

{
  "baseUrl": "http://127.0.0.1:8000/api",
  "token": "dev-token",
  "timeoutMs": 15000
}

Add the PCM tools to the OpenClaw agent allowlist:

[
  "pcm_list_vms",
  "pcm_create_vm",
  "pcm_update_vm_settings",
  "pcm_delete_vm",
  "pcm_start_vm",
  "pcm_stop_vm",
  "pcm_ssh_exec",
  "pcm_get_job_status",
  "pcm_update_vm",
  "pcm_get_update_feed",
  "pcm_rotate_security_updates",
  "pcm_fire_lab",
  "pcm_stop_lab"
]

After changing plugin code, reinstall it from the local folder and restart OpenClaw:

openclaw plugins install -l D:\Projects\private-cloud-manager\openclaw-plugin-private-cloud-manager

Recommended local OpenClaw workspace files:

• USER.md with who the operator is and what they care about
• IDENTITY.md for the assistant persona
• TOOLS.md with environment-specific tool-grounding rules

These files do not make the tools work, but they improve consistency and reduce unhelpful narration.

End-to-End Setup Flow

1. Start the backend and let Prisma create/sync the SQLite database
2. Start the frontend and verify you can log in with the backend token
3. Add your VMware VMs through the UI or the VM API
4. Verify VM listing, power-state refresh, and SSH access from the browser UI
5. Start Ollama and pull a model
6. Install and configure OpenClaw
7. Install the local PCM plugin, allow the PCM tools, and restart OpenClaw
8. Test with pcm_list_vms, then pcm_start_vm, then pcm_get_job_status

Example OpenClaw Prompts

• Use pcm_list_vms to list my VMs. Do not use exec.
• Use pcm_create_vm with id "win-srv-2025", name "Windows Server 2025", vmxPath "D:\\Vms\\WIN-SRV-2025\\Windows Server 2025.vmx", osFamily "windows", sshHost "10.10.0.5", sshUser "Administrator". Do not use exec.
• Use pcm_delete_vm with vmId "old-lab-vm". Do not use exec.
• Use pcm_delete_vm with vmId "old-template" and deleteFromDisk true. Do not use exec.
• Use pcm_stop_vm with vmId "wireguard". Do not use exec.
• Use pcm_get_job_status with a job id returned by the backend.
• Use pcm_update_vm with vmId "kali-01". Do not use exec.
• Use pcm_get_update_feed with vmId "windows-dc" and mode "security". Do not use exec.
• Use pcm_rotate_security_updates. Do not use exec.
• Use pcm_fire_lab with lab "blue_team". Do not use exec.
• Use pcm_stop_lab with lab "wg_vpn" and includeGateway false. Do not use exec.

Design Choices

One of the strongest decisions in this project is that the AI layer does not directly control the host. Instead:

• the assistant uses explicit tools
• those tools call the backend API
• the backend remains the single execution layer

That keeps policy, logging, and operational behavior centralized for both human and AI operators.

Community

This project is not just for my own environment. I want it to be understandable, reusable, and useful to other people building local labs, private-cloud tooling, and AI-assisted operations workflows.

That is why the public repo includes:

• a real project writeup
• architecture documentation across frontend, backend, and OpenClaw integration
• a structure that other builders can adapt to their own VMware environments

The goal is to contribute something practical to the community: a concrete example of how local infrastructure, platform engineering, and local AI tooling can work together in a clean and controlled way.

Documentation

• Project writeup
• Runbooks phase 1
• Frontend notes
• Backend notes
• OpenClaw plugin notes

Roadmap

• transitional VM states such as booting and stopping
• snapshot lifecycle support
• richer SSH readiness and connection diagnostics
• authentication and access management beyond a single token
• stronger SSH policy controls
• approval flows for sensitive actions
• multi-host support
• more OpenClaw tools and operational workflows
• a real-time world map for attack telemetry focused on lab VMs and especially honeypot activity