Repository copies, files, terminal, builds, tests, ports, previews, caches, and artifacts.
ARCHITECTURE GUIDE · VERIFIED 2026-08-05
Map the control plane, execution plane, and every external route.
Public materials distinguish a MonkeyCode console from development environment hosts and describe server-side task execution. The exact runtime, storage, isolation, protocol, and high-availability implementation must be verified in the release you deploy.
Logical architecture
A documented core with configurable edges.
This is an evaluation model, not an undocumented claim about internal services.
CONTROL PLANEMonkeyCode console
Users, projects, requirements, AI tasks, model configuration, and task state.
Repository access, branch/write scope, credentials, and event routes must be verified.
Prompt and source context route, provider terms, credentials, quotas, logs, and fallback.
Installers, packages, images, DNS, TLS, updates, logs, monitoring, backups, and restore.
Published floor
Two roles have separate minimums.
These figures are evaluation starting points, not production capacity, concurrency, availability, or isolation guarantees.
4 GB memory · 40 GB storage
16 GB memory · 100 GB storage
Evidence levels
Know what the diagram proves.
Keep implementation hypotheses out of architecture claims.
| Level | Included | Excluded |
|---|---|---|
| Documented | Console and environment-host roles; server-side environments; build, test, terminal, preview workflows; hosted and private deployment paths | Performance and production suitability |
| Configurable | Git, models, package access, egress, DNS, TLS, logging, backup, retention, and administrator access | A universal default for every deployment |
| Must verify | Runtime, containers or VMs, ports, protocols, databases, queues, storage implementation, HA, scaling, isolation, encryption, and telemetry | Any inference from minimum hardware figures |
Failure boundaries
Assign an owner and recovery target.
- 01Console unavailable
Test configuration backup, restore, upgrade rollback, and task-state recovery.
- 02Environment host unavailable
Test task interruption, cleanup, replacement, retained artifacts, and repository safety.
- 03Model or Git unavailable
Test timeout, revoked credentials, partial work, retries, and operator visibility.
- 04Storage or egress constrained
Test disk limits, dependency failure, logs, alerts, cleanup, and safe degradation.
Common questions
Architecture, answered.
Related: minimum requirements, security boundaries, self-hosting guide.
What is MonkeyCode’s architecture?
Public materials describe a control plane (the MonkeyCode console: users, projects, requirements, AI tasks, model configuration, and task state) plus separate development environment hosts that run repository work, with external routes to source control, model inference, and the operations supply chain. Exact runtime, storage, and isolation are release-specific.
How does the console differ from the development environment host?
The console manages users, projects, tasks, and model configuration; the development environment host runs code, builds, tests, and previews. They are distinct roles with separate minimum requirements and fail for different reasons.
What are MonkeyCode’s trust boundaries?
The important boundaries are the console, development hosts, source control, model endpoints, and the operations supply chain. Record the owner, credential, retention rule, and allowed network path for each before trusting the deployment with sensitive code.
What are the minimum requirements?
Published starting minimums are about 2 cores / 4 GB / 40 GB for the console and 8 cores / 16 GB / 100 GB for a development environment host — an evaluation floor, not a production capacity or availability guarantee.
Does the architecture guarantee data isolation?
No. Isolation strength, encryption, and default telemetry are release-specific and must be verified against the version you deploy; do not infer them from a diagram or minimum hardware figures.
IMPLEMENT THE MODEL