SELF-HOSTING

Self-Hosting erhöht die Kontrolle, garantiert aber nicht automatisch Datenschutz.

Die Software kann in einem privaten Netzwerk laufen. Die eigentliche Arbeit besteht darin, Umgebungsisolation, Modellrouten, Zugangsdaten, Observability, Upgrades und Verantwortlichkeiten zu definieren.

Sicherheit Bereitstellungsdokumentation ↗

DIREKTE ANTWORTJa. Das öffentliche MonkeyCode-Projekt dokumentiert die private Bereitstellung und beschreibt, dass Code und Projektdaten auf Infrastruktur unter Kontrolle der Organisation bleiben können.

Wichtig: Die private Bereitstellung der Plattform macht externe Modellaufrufe, Paket-Downloads, Logs und Source-Control-Verkehr nicht automatisch privat.

„Im Netz" gibt es trotzdem Ausgänge.

Erfassen Sie jeden Pfeil vor der Installation. Hier werden die meisten Datenschutzannahmen zu prüfbaren Architekturfragen.

IHR KONTROLLIERTES NETZ · Kontrollebene: Benutzer · Projekte · Anforderungen · Aufgabenstatus · Modellkonfiguration.
IHR KONTROLLIERTES NETZ · Umgebungshosts: Repositorys · Builds · Tests · Vorschauen · generierte Artefakte.
MODELLROUTE: externe API, privates Gateway oder lokales Modell.
CODE-HOST: Git-Anbieter, Webhooks und begrenzte Zugangsdaten.
LIEFERKETTE: Pakete, Images, Updates und Installer.

Acht Entscheidungen vor der ersten Produktionsaufgabe.

Kann keine verantwortliche Person diese Fragen beantworten, ist die Bereitstellung noch ein Experiment — und sollte auch so behandelt werden.

01 Workload-Isolation: Wie werden Dateisysteme, Prozesse, CPU, Arbeitsspeicher, Speicher und Netzwerkzugriff je Aufgabe getrennt?
02 Modell-Datenweg: Welcher Code und welche Prompts verlassen das Netz, an welchen Anbieter, unter welchen Aufbewahrungsbedingungen?
03 Repository-Zugriff: Was darf jedes Token lesen, schreiben, verzweigen, prüfen und auslösen — und wie wird es rotiert?
04 Freigegebene Images: Wer verantwortet Runtimes, Zertifikate, Paketspiegel, Patches, Signierung und Schwachstellenscans?
05 Observability: Welche Plattform- und Aufgabensignale werden protokolliert, wer darf sie lesen, und können sie Code oder Geheimnisse enthalten?
06 Aufbewahrung: Wann werden Umgebungen, Repositorys, Logs, Prompts, Artefakte und Backups entfernt?
07 Upgrade und Rollback: Wie werden neue Releases gestuft, getestet, gesichert und zurückgenommen, ohne Aufgabenstatus zu verlieren?
08 Lizenzprüfung: Wie gilt AGPL-3.0 für beabsichtigte Nutzung, Änderungen und Netzwerkzugriff?

Nach paralleler Arbeit dimensionieren, nicht nach registrierten Nutzern.

Ein einzelner schwerer Build kann mehr wiegen als Dutzende inaktive Konten. Messen Sie das Ressourcenprofil repräsentativer Aufgaben, bevor Sie die Parallelität festlegen.

Planungsmodell: aktive Aufgabenumgebungen × Spitzenbedarf je Aufgabe + Plattform-Overhead + Ausfallreserve.
Laufend erfassen: Startzeit der Umgebung, CPU- und Speicherspitzen, Festplattenwachstum, Image-Pulls, Repository-Größe, Build-Dauer, Artefakt-Aufbewahrung und Erfolg der Bereinigung.

Klein genug bereitstellen, um zu lernen.

Das erste Ziel ist nicht Skalierung, sondern die betrieblichen und sicherheitsrelevanten Annahmen zu finden, die öffentliche Dokumentation für Ihre Umgebung nicht beantworten kann.

TOR 1 · Nicht-Produktionsnetz: begrenzter Repository-Satz, enge Tokens, freigegebene Modelle, niedrige Parallelität.
TOR 2 · Repräsentative Aufgaben: Builds und Tests, die echte Abhängigkeiten, interne Dienste und Vorschauverhalten beanspruchen.
TOR 3 · Fehlerübungen: Token ablaufen lassen, Host stoppen, Festplatte füllen, Modellanfrage unterbrechen und Bereinigung testen.
TOR 4 · Wiederherstellung und Upgrade: Backup-Wiederherstellung und eine gestufte Versionsänderung nachweisen, bevor ein breiteres Team eingeladen wird.

Veröffentlichter Startwert

Zwei Infrastrukturrollen, getrennt dimensioniert.

Das Projekt unterscheidet die Verwaltungskonsole von den Hosts, die Entwicklungsumgebungen ausführen. Diese Zahlen sind Mindestwerte für die Evaluation, kein Produktionsversprechen.

Komponente	CPU	Arbeitsspeicher	Speicher
MonkeyCode-Konsole	2 cores	4 GB	40 GB
Entwicklungshost	8 cores	16 GB	100 GB

Vom MonkeyCode-Projekt veröffentlicht; geprüft am 05.08.2026. Reserven für Parallelität, Builds, Image-Caches, Repositorys, Logs und aufbewahrte Artefakte einplanen.

HÄUFIGE FRAGEN

Häufige Fragen, beantwortet

Kann MonkeyCode in einem privaten Netzwerk betrieben werden?

Ja. MonkeyCode unterstützt private und Offline-Bereitstellung für Organisationen, die Code- und Projektdaten lokal kontrollieren müssen.

Welche Mindestanforderungen sind veröffentlicht?

Das Projekt-README empfiehlt mindestens 2 CPU-Kerne, 4 GB Arbeitsspeicher und 40 GB Speicher für die MonkeyCode-Konsole sowie 8 CPU-Kerne, 16 GB Arbeitsspeicher und 100 GB Speicher für einen Entwicklungshost.

Benötigt selbst gehostetes MonkeyCode externe KI-APIs?

Das hängt von der konfigurierten Modellroute ab. Das Self-Hosting der Plattform garantiert für sich genommen nicht, dass Prompts oder Code keinen externen Modellanbieter erreichen.

Reicht das veröffentlichte Minimum für die Produktion?

Es ist eine Startuntergrenze, keine Produktionsgarantie. Repository-Größe, parallele Aufgaben, Builds, Image-Caches, Artefakt-Aufbewahrung und Modellverkehr beeinflussen die Kapazität.

EVIDENZHINWEIS

Anforderungen und Befehle können sich ändern. Vor der Ausführung die aktuelle Bereitstellungsdokumentation prüfen.

MONKEYCODE

Self-Hosting erhöht die Kontrolle, garantiert aber nicht automatisch Datenschutz.

MONKEYCODE DEUTSCH PRODUKTÜBERSICHT SICHERHEIT & DATENSCHUTZ INSTALLATION MODELLGUIDE PREISE & TCO