01
Scope discipline
CMesh V1 is explicit about what it does now: connect workers, report capacity, benchmark machines, show cluster state, and place jobs.
Private AI compute cluster
CMesh
CMesh is an open-source infrastructure project for private AI compute. It starts from a practical constraint: useful machines are often spread across laptops, workstations, GPU rigs, lab boxes, and small servers. The system provides manager and worker roles, resource discovery, benchmark-aware capacity reporting, job placement, artifact-cache direction, and a dashboard-oriented operator model. The architecture intentionally begins with a single-manager bootstrap while keeping consensus, scheduling, membership, storage, resources, and transport separated for future multi-manager operation.
GoHTTP APIResource discoverySchedulerConsensus boundaryDockerGitHub
Delivery record
From internal product thinking into public open-source software.
The work covered scope discipline, public documentation, product framing, architecture decisions, visual presentation, and repository-ready delivery.
02
Clean package boundaries
The codebase keeps consensus, scheduling, membership, storage, resources, transport, jobs, and manager behavior separated.
03
Worker onboarding model
Workers join with bounded CPU, memory, disk, and future GPU limits so the cluster can reason about usable capacity.
04
Future-ready architecture
The project can start with one manager while preserving a path toward replicated manager nodes and consensus-backed state.
Product screens
Real product surfaces, staged like a launch system.
Key screens, workflow states, launch pages, and operating surfaces are arranged as a moving system instead of static thumbnails.
Cluster dashboard
Manager and worker architecture
Worker node profile
Product system
What this case proves.
AI compute cluster / Go architecture / open-source infrastructure
Manager node
Worker runtime
Resource discovery
Benchmark model
Job scheduler
Artifact cache
Dashboard direction
Consensus boundary
No false distributed-compute claims
The README draws a clear line between practical private clustering now and future multi-machine model execution later.
Architecture before polish
The repository starts with package boundaries and operating concepts that can survive growth beyond a prototype.
Operator-first visibility
The planned dashboard centers the facts an operator needs: nodes, capacity, benchmarks, jobs, and placement decisions.
Outcomes
Built for real delivery pressure.
01 / 03
Cluster dashboard
The operator view focuses on available CPU, memory, queued jobs, worker capacity, and scheduling decisions.
01
Created an open-source architecture for turning scattered private machines into an understandable AI compute cluster.
02
Separated core domains into manager, worker, consensus, scheduling, membership, resources, storage, transport, and jobs packages.
03
Defined V1 around practical cluster visibility and job placement instead of overpromising distributed execution of one large model.
04
Documented the project clearly with architecture, development, API, roadmap, security, and contribution guidance.
Technology stack
Real tools behind the product.
The stack was selected around the delivery goal, production constraints, operating model, and future iteration path.
GO
Go
cluster manager, worker runtime, scheduler, and package architecture
Docker
deployment direction for local and future multi-node environments
Linux
resource discovery and worker runtime target
Node.js
dashboard development direction for operator surfaces
GI
GitHub
open-source repository, documentation, issues, and contribution workflow
Start a similar build
Bring a product idea into a shippable system.
Use the same request flow as the main site. We will route the conversation to product strategy, mobile app, CRM/admin, agentic engineering, or launch-site work.