Clone, fetch, push, webhooks, deploy keys, and tokens.
SECURITY & PRIVACY · VERIFIED 2026-08-05
Self-hosting changes the boundary. It does not verify the boundary.
MonkeyCode documents private and offline deployment. Whether code, prompts, credentials, logs, and artifacts remain private depends on your selected models, integrations, network routes, configuration, and operations.
DIRECT ANSWERA self-hosted MonkeyCode deployment can place the platform inside your infrastructure, but that alone does not prove that every data flow stays local.
Model endpoints, Git services, package registries, updates, telemetry, previews, administrator access, logs, and backups must each be traced and tested.
This page is an evaluation framework, not a certification, penetration-test result, or guarantee for a specific release.
Trust boundary
Trace data from requirement to reviewed change.
Record the owner, location, credential, retention rule, and allowed network path for every component.
YOUR DEPLOYMENTConsole · tasks · development environments
Requirements, repository copies, commands, generated code, build output, previews, and task history may exist here.
Prompts, source context, responses, provider logs, and retention.
Packages, images, installers, signatures, and provenance.
Task output, secrets exposure, snapshots, retention, and restores.
Evidence levels
Separate documented facts from deployment assumptions.
This prevents architecture guidance from being mistaken for a product guarantee.
| Evidence level | What can be said | Required action |
|---|---|---|
| Documented | The public project describes private and offline deployment. | Confirm the statement against the release you install. |
| Configurable | Model, Git, network, logging, backup, and retention choices affect the real boundary. | Document and test your selected topology. |
| Must verify | Isolation strength, default telemetry, encryption, RBAC, SSO, audit detail, retention, certifications, and incident response are release-specific. | Request evidence; do not infer these controls from self-hosting. |
Security acceptance checklist
Test controls with non-sensitive code first.
Record evidence and an owner for every failed or unknown item.
Use scoped Git and model credentials; test expiry, rotation, and revocation.
Attempt cross-project filesystem, process, network, cache, and secret access.
Allow only approved model, Git, registry, update, DNS, and observability destinations.
Search prompts, task logs, build output, previews, exports, and backups for credentials.
Confirm who initiated work, what executed, which model was used, and what changed.
Restore the console and task data, replace a host, and test upgrade rollback.
Primary evidence
Verify current behavior at the source.
Common questions
Security and privacy, answered.
Source-backed direct answers: does self-hosting keep code private?, does it send code externally?, can it run air-gapped?
Does self-hosting MonkeyCode keep all my code private?
Not by itself. Self-hosting places the console and environments in your infrastructure, but model endpoints, Git providers, package registries, updates, logs, and backups must each be traced and tested before a deployment can be called private.
Does MonkeyCode send my code to external services?
It depends on your configured model route and integrations. A self-hosted control plane can still call an external model API, so map every outbound path and deny egress by default until each destination is approved.
Can MonkeyCode run air-gapped or fully offline?
The project documents private and offline deployment. For a true air gap, the model must run on an in-network endpoint and outbound access must be denied by default; verify this against your release and configuration.
Is MonkeyCode security-certified or penetration-tested?
Isolation strength, default telemetry, encryption, RBAC, SSO, audit detail, retention, certifications, and incident response are release-specific. Request evidence directly; do not infer these controls from the fact that the platform is self-hosted.
What should a MonkeyCode security pilot test first?
Start with least-privilege credentials, environment isolation, egress control, secret handling in logs and backups, auditability, and recovery. Test with non-sensitive code before trusting the boundary with proprietary repositories.
USE A BOUNDED PILOT