Short answer: self-hosting increases infrastructure control, but it is only private and reliable when model routes, repository access, workload isolation, secrets, logs, backups, upgrades, and operational ownership are explicitly designed.
Self-hosting an AI development platform gives an organization more control over code, project data, model access, and execution infrastructure. It also moves important operational responsibilities onto the organization.
The right question is not simply “Can we deploy it?” The right question is “Can we operate it reliably, securely, and usefully for an engineering team?”
Use this checklist to prepare a pilot before wider rollout.
1. Define the reason for self-hosting
Start with the constraint you are solving. Common reasons include:
- source code must remain inside a private network;
- development tasks need access to internal services;
- the organization wants to manage model providers centrally;
- data residency or internal policy limits hosted services;
- teams need custom images, compute, or network topology;
- the organization wants operational independence from a single hosted interface.
Write the reason down. It will drive architecture decisions and prevent a self-hosted project from becoming an open-ended infrastructure exercise.
2. Separate the control plane from task environments
An AI development platform typically has two different infrastructure roles.
The control plane manages users, projects, requirements, tasks, model configuration, and administrative state. The development environment hosts run code, install dependencies, build projects, execute tests, and expose previews.
Separating those roles helps with isolation and capacity planning. A burst of builds should not make the management console unavailable.
MonkeyCode’s current public deployment guidance recommends:
| Component | Minimum starting configuration |
|---|---|
| MonkeyCode console | 2 CPU cores, 4 GB memory, 40 GB storage |
| Development environment host | 8 CPU cores, 16 GB memory, 100 GB storage |
These are starting points, not sizing guarantees. Actual capacity depends on task concurrency, repository size, build workload, base images, and retention policy.
3. Plan isolation before concurrency
Each task may execute untrusted project code and model-generated commands. Treat development environments as workload isolation boundaries.
Confirm:
- how task filesystems are separated;
- which network destinations are reachable;
- how CPU, memory, storage, and execution time are limited;
- how credentials enter and leave an environment;
- whether privileged containers or host mounts are required;
- when environments and artifacts are deleted;
- how a developer can inspect a running task without bypassing controls.
Start with low concurrency. Increase it only after observing real CPU, memory, disk, and network behavior.
4. Inventory source control and credentials
List the repositories included in the pilot and use narrowly scoped credentials. Avoid starting with organization-wide tokens.
For each source control integration, document:
- repository read and write permissions;
- branch creation permissions;
- pull or merge request permissions;
- webhook endpoints and secrets;
- token owner and rotation process;
- audit log availability;
- behavior when credentials expire.
An AI agent should receive only the access required for the selected task. The platform’s administrative convenience should not expand a token’s scope.
5. Decide how models are reached
Self-hosting the platform does not automatically mean every model runs locally. A deployment may call external model APIs, private model gateways, or models operated inside the same network.
Evaluate each route across:
- code and prompt data sent to the provider;
- provider retention and training policies;
- regional availability and latency;
- authentication and quota management;
- model quality for your representative tasks;
- fallback behavior during provider outages;
- cost visibility by team or project.
MonkeyCode supports multiple model families, including GLM, Kimi, MiniMax, Qwen, and DeepSeek. A pilot should test at least two task types instead of selecting a model from a general benchmark alone.
6. Build an approved environment image
The task environment should contain the tools a project needs without becoming an uncontrolled collection of credentials and packages.
Document:
- base operating system and update schedule;
- language runtimes and package managers;
- build tools, browsers, and system libraries;
- internal certificate authorities and package mirrors;
- vulnerability scanning and image signing;
- who can publish or select an image;
- how old environments receive security updates.
Use a small number of approved images for the pilot. Too much flexibility makes failures harder to reproduce.
7. Treat observability as a product requirement
Operators need infrastructure metrics, while developers need task-level evidence.
At minimum, collect:
- control-plane health and error rates;
- environment creation time and failure rate;
- CPU, memory, disk, and network use by host;
- task duration and status;
- model request errors and throttling;
- build and test outcomes;
- retention and cleanup events.
Decide which logs may contain source code, prompts, model responses, or credentials. Apply access and retention controls accordingly.
8. Prepare backup and upgrade procedures
Identify which state is durable and which environments can be recreated. Back up the durable state, test a restore, and document ownership.
Before upgrading:
- read the upstream release notes;
- back up persistent data;
- test the new version in a staging environment;
- run representative tasks and integrations;
- define the rollback trigger and procedure;
- communicate user-visible changes.
Open source gives teams the ability to inspect and adapt the system, but it does not remove routine platform operations.
9. Design a small, measurable pilot
Choose a handful of developers, a limited set of repositories, and three to five representative task types. Define success before the first task runs.
Useful measures include:
- environment startup success and time;
- percentage of tasks reaching a reviewable change;
- build and test pass rates;
- human review time;
- model and infrastructure cost per completed task;
- number and severity of access or reliability incidents;
- developer confidence in understanding and correcting agent work.
The pilot should reveal whether the workflow fits—not just whether the software can be installed.
10. Review licensing and organizational policy
MonkeyCode is released under the GNU Affero General Public License v3.0. Review the license, planned modifications, and network use with your legal team. Also align the deployment with existing policies for source code, secrets, third-party models, software supply chain, logging, and incident response.
Verify the deployment path upstream
Installation commands, configuration, and integrations are time-sensitive. Read the current MonkeyCode deployment documentation and inspect the open-source repository before installation.
If upstream documentation provides a remote installer, review its contents and test it in a non-production environment before running it with elevated privileges. Record the exact version, configuration, model route, and rollback procedure used by the pilot.