146 lines
4.2 KiB
Markdown
146 lines
4.2 KiB
Markdown
# 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:
|
||
|
||
1. **Keep game logic out of core provisioning code** — Minecraft is a workload definition, not a foundation
|
||
2. **Keep the agent generic** — it runs any workload, not just game servers
|
||
3. **Keep template definitions abstract** — game types are plugins, not hardcoded paths
|
||
4. **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.
|