MonkeyCode console
- CPU
- 2 cores
- Memory
- 4 GB
- Storage
- 40 GB
SELF-HOSTING FIELD GUIDE · MINIMUM REQUIREMENTS CHECKED 2026-09-08
Self-hosting MonkeyCode is an infrastructure decision—not an install command.
The software can run inside a private network. The real work is defining environment isolation, model routes, credentials, observability, upgrades, and ownership.
Published starting floor
Two infrastructure roles, sized separately.
The project distinguishes the management console from the hosts that run development environments. Treat these numbers as minimums for evaluation, not a production capacity promise.
Development environment host
- CPU
- 8 cores
- Memory
- 16 GB
- Storage
- 100 GB
Published by the MonkeyCode project; checked 2026-09-08. Add headroom for concurrency, builds, image caches, repositories, logs, and retained artifacts.
Trust-boundary map
“Inside the network” still has exits.
Map each arrow before installation. This is where most privacy assumptions become testable architecture questions.
YOUR CONTROLLED NETWORKCONTROL PLANEUsers · projects · requirements · task state · model configuration ENVIRONMENT HOSTSRepositories · builds · tests · previews · generated artifacts
Readiness checklist
Eight decisions before the first production task.
If an owner cannot answer these questions, the deployment is still an experiment—and should be treated like one.
Workload isolation
How are filesystems, processes, CPU, memory, storage, and network access separated per task?
Model data route
Which code and prompts leave the network, to which provider, under what retention terms?
Repository access
What can each token read, write, branch, review, and trigger—and how is it rotated?
Approved images
Who owns runtimes, certificates, package mirrors, patches, signing, and vulnerability scans?
Observability
Which platform and task signals are logged, who can read them, and could they contain code or secrets?
Retention
When are environments, repositories, logs, prompts, artifacts, and backups removed?
Upgrade and rollback
How will new releases be staged, tested, backed up, and reversed without losing task state?
License review
How does AGPL-3.0 apply to intended use, modifications, and network access?
Capacity model
Size for concurrent work, not registered users.
A single heavy build can matter more than dozens of idle accounts. Measure the resource profile of representative tasks before setting concurrency.
PLANNING MODEL
Active task environments×Peak task footprint+Platform overhead+Failure headroom
Track environment startup time, CPU and memory peaks, disk growth, image pulls, repository size, build duration, artifact retention, and cleanup success.
Operational close conditions
A self-hosted deployment is not accepted until it survives a restart and a restore.
Install and one accepted task are the start. These two checks decide whether the platform is operable, not merely runnable.
| Check | Do this | Pass criterion |
|---|---|---|
| Restart | Stop and start the console and the development host, then run one task. | Services return without manual repair, task history and projects are intact, and a new task completes. |
| Backup | Back up platform state and configuration on a schedule and record what is excluded (for example transient execution containers). | A backup artifact exists, its scope is written down, and a restore has actually been tested from it — not assumed. |
| Restore | Restore the backup onto a clean or replacement host, then run one task. | The restored instance serves the existing projects and completes a task; record recovery time and any data gap. |
These are acceptance criteria to run in your own environment, not vendor guarantees. The evidence contract is `selfhost-install` in docs/PRODUCT_RUNTIME_EVIDENCE_2026-10-09.md; page content updated 2026-10-09.
Safe rollout
Deploy small enough to learn.
The first objective is not scale. It is discovering the operational and security assumptions that public documentation cannot answer for your environment.
- GATE 1Non-production network
Use a limited repository set, narrow tokens, approved models, and low concurrency.
- GATE 2Representative tasks
Run builds and tests that exercise real dependencies, internal services, and preview behavior.
- GATE 3Failure drills
Expire a token, stop a host, fill a disk, interrupt a model request, and test cleanup.
- GATE 4Restore and upgrade
Prove backup restoration and one staged version change before inviting a wider team.
Self-hosting answers
The short version.
Can MonkeyCode be deployed inside a private network?
Yes. MonkeyCode supports private, offline deployment for organizations that need local control of code and project data.
What are the published minimum requirements?
The project README recommends at least 2 CPU cores, 4 GB memory, and 40 GB storage for the MonkeyCode console, plus 8 CPU cores, 16 GB memory, and 100 GB storage for a development environment host.
Does self-hosted MonkeyCode require external AI APIs?
That depends on the model route you configure. Self-hosting the platform does not by itself guarantee that prompts or code never reach an external model provider.
Is the published minimum enough for production?
It is a starting floor, not a production sizing guarantee. Repository size, concurrent tasks, builds, image caches, artifact retention, and model traffic affect capacity.
GET STARTED