Ghost Shell — Strategic Vision

Status: Concept phase. Do not build yet. ZLH must stabilize first.
Last Updated: April 7, 2026

The Core Insight

ZeroLagHub is not a game host.
It is a control substrate over Proxmox.
Gaming is the first application layer.

Strip away Minecraft and dev container presets. What remains is:

VMID allocator
LXC provisioning logic
Bridge assignment model
API-driven lifecycle management
Agent-based execution abstraction
PTY console streaming
Metrics aggregation
Versioned agent updates
Tenant isolation enforcement
Auth + RBAC
Billing integration

That is not gaming infrastructure. That is an orchestration framework.

The Layer Model

Layer 0 — Infrastructure
  Proxmox, Storage, Networking, Bridges, VMID ranges

Layer 1 — Control Plane (Ghost Shell Core)
  API, Auth, Provisioning logic, Agent lifecycle,
  Metrics aggregation, Isolation enforcement

Layer 2 — Execution Substrate
  LXC containers, Agent runtime

Layer 3 — Application Layer (Pluggable)
  Minecraft
  Dev environments
  Future workloads

Gaming lives in Layer 3.
Everything below it is generic.
Ghost Shell is Layers 0–2.

What Ghost Shell Is

A branded-neutral, multi-tenant, API-first LXC control plane with agent-based execution.

More precisely: infrastructure middleware.

Closer to a lightweight Render, Railway, or Fly.io — but:

Self-hosted
On bare metal
Your cost structure
Proxmox-native

The Strategic Separation

ZeroLagHub = Product built on Ghost Shell (gaming application layer)
Ghost Shell = The core platform
Red Castle / other ventures = Different products built on the same governance model

This means you are not building two companies.
You are building one core capability with multiple market applications:

Governed edge execution over deterministic container environments.

That is the niche. Not gaming. Not hosting. Not PLCs.
Control plane engineering.

Critical Constraints (Must Preserve Now)

For Ghost Shell to remain viable, these rules apply to ZLH development today:

Keep game logic out of core provisioning code — Minecraft is a workload definition, not a foundation
Keep the agent generic — it runs any workload, not just game servers
Keep template definitions abstract — game types are plugins, not hardcoded paths
Treat application layer as pluggable — Layer 3 must be swappable

If Minecraft becomes embedded in lifecycle logic, Ghost Shell dies.
If Minecraft is a plug-in workload definition, Ghost Shell lives.

These constraints should be checked in every architectural review.

Phased Extraction Plan

Phase 1 — ZLH as application layer (NOW)
  Build ZLH on top of what will become Ghost Shell.
  Do not abstract yet.

Phase 2 — Stabilize core (NEXT)
  ZLH reaches: stable, operational, minimal rewrite pressure.
  Revenue generating.

Phase 3 — Extract core into Ghost Shell
  Clean separation of Layer 1-2 from Layer 3.
  Ghost Shell becomes a named, standalone codebase.

Phase 4 — ZLH becomes one implementation of Ghost Shell
  Other products can be built on the same substrate.

The wrong move is abstracting too early — it will stall ZLH.

Open Strategic Question

The answer to this determines architecture decisions being made now:

How do you intend to use Ghost Shell?

A) Selling it as a Proxmox SaaS control panel competitor
B) Selling it to MSPs
C) Using it internally across multiple ventures (Red Castle, etc.)
D) Open-core with monetized extensions

This question is deliberately left open. The answer should be committed here when decided, because early architectural decisions will lock or unlock each option.

Connection to Owner Background

This architecture emerged naturally from controls engineering thinking applied to cloud infrastructure. The layer model above is structurally identical to how industrial control systems are organized (field devices → controllers → supervisory → operator interface). That is not accidental — it is trained instinct applied to a new domain.

See OWNER_PROFILE.md for full context.

4.2 KiB Raw Blame History Unescape Escape