Self-Hosting
Sie kontrollieren, wo Control Plane und Ausführungsumgebungen laufen. Ausgehende Routen zu Modell-APIs, Git-Anbietern und Registries können weiterhin bestehen und müssen erfasst werden. Self-Hosting-Leitfaden.
BEREITSTELLUNGSSZENARIO · GEPRÜFT 2026-08-05
Air-Gapped-KI-Coding: Was Isolation tatsächlich erfordert.
Die öffentliche Dokumentation von MonkeyCode beschreibt private und Offline-Bereitstellung. Ein wirklich air-gapped Betrieb – ganz ohne ausgehenden Pfad – ist erreichbar, verschiebt aber jede Netzwerkabhängigkeit in Ihre Grenze: Modell-Inferenz, Paketquellen, Images und Updates. Diese Seite zeigt, was dokumentiert ist, was Sie bereitstellen müssen und wie Sie die behauptete Isolation verifizieren.
Zuerst die Definition
Air-Gapped bedeutet Null-Egress, nicht nur Self-Hosting.
Eine Plattform kann vollständig auf Ihren Servern liegen und dennoch für Modell-Inferenz, Abhängigkeits-Downloads oder Telemetrie nach außen rufen. Der nützliche Test ist nicht „Wo ist sie installiert?“, sondern „Verlässt irgendein Byte während des Betriebs die Grenze?“
Egress-kontrolliert
Ausgehender Verkehr ist auf eine genehmigte Allowlist beschränkt – Modell-Endpunkte und Mirrors, die Sie gewählt haben. Die meisten regulierten Bereitstellungen landen hier. Egress-Kontrolle.
Air-Gapped
Es existiert kein ausgehender Pfad. Modelle, Pakete, Images und Updates werden alle innerhalb der Grenze bereitgestellt. Air-Gap-Bereitstellung und die direkte Antwort zum Air-Gapped-Betrieb.
Was Sie bereitstellen müssen
Isolation verlagert fünf Verantwortlichkeiten in Ihre Grenze.
Das sind Betriebsanforderungen jeder Air-Gapped-Plattform, keine undokumentierten Produktbehauptungen.
01 · Modell-Inferenz
Ein lokal bereitgestellter Modell-Endpunkt mit der nötigen Hardware. Welche Familien Ihrer Qualitäts- und Kostenmesslatte entsprechen, ist eine Bewertungsfrage – unterstützte Modelle und lokale Modelle.
02 · Paket- und Image-Mirrors
Interne Mirrors für jedes Paket-Registry und jedes Container-Image, aus denen die Plattform und Ihre Builds beziehen, durch einen kontrollierten Prozess aktuell gehalten.
03 · Update-Pfad
Ein wiederholbares Offline-Upgrade-Verfahren – herunterladen, verifizieren, übertragen, anwenden, zurückrollen –, da sich innerhalb der Grenze nichts selbst aktualisiert.
04 · Quellcodeverwaltung und Anmeldedaten
Git-Hosting innerhalb der Grenze mit pro Aufgabe begrenzten Anmeldedaten. Isolation ersetzt kein Least Privilege.
05 · Nachweise
Egress-Überwachung an der Grenze, die pro Aufgabenlauf belegen kann, dass nichts nach außen gelangt ist. „Air-Gapped“ ist eine Messung, kein Etikett.
Verifizierungsablauf
Beweisen Sie die Isolation, bevor Sie ihr vertrauen.
- 01Offline installieren
Führen Sie die dokumentierte Installation bei bereits geschlossener Netzwerkgrenze durch; notieren Sie jede Abhängigkeit, die manuell bereitgestellt werden musste.
- 02Repräsentative Aufgaben ausführen
Führen Sie reale Build-, Test- und Agent-Workflows mit nicht sensiblen Code aus und erfassen Sie dabei den gesamten Verkehr an der Grenze.
- 03Egress auditieren
Null ausgehende Verbindungen während Installation, Aufgabenausführung und Upgrade sind das Abnahmekriterium – untersuchen Sie alles andere.
- 04Das Update proben
Führen Sie einen vollständigen Offline-Upgrade-Zyklus einschließlich Rollback aus, bevor die Bereitstellung Produktionsarbeit übernimmt.
Häufige Fragen
Air-Gapped-Betrieb, beantwortet.
Verwandt: Air-Gapped-Plattformleitfaden, Sicherheitsgrenzen, Architektur und Vertrauensgrenzen, Kapazitätsrechner.
Kann MonkeyCode air-gapped betrieben werden?
Die öffentliche Bereitstellungsdokumentation von MonkeyCode beschreibt private und Offline-Bereitstellung. Der Air-Gapped-Betrieb – ohne ausgehenden Internetpfad – ist daher eine dokumentierte Richtung, aber jede Abhängigkeit, die die Plattform normalerweise über das Netzwerk erreicht (Modell-Endpunkte, Paketquellen, Images, Updates), muss innerhalb Ihrer Grenze bereitgestellt und im bereitgestellten Release verifiziert werden.
Was ist der Unterschied zwischen Self-Hosting und Air-Gapped?
Self-Hosting bedeutet, dass die Plattform auf von Ihnen kontrollierter Infrastruktur läuft; sie kann weiterhin ausgehende Verbindungen für Modell-Inferenz, Pakete oder Updates öffnen. Air-Gapped fügt die strengere Einschränkung hinzu, dass gar kein Verkehr die Grenze verlässt, wodurch die Verantwortung für Modelle, Mirrors und Updates vollständig auf Ihre Umgebung übergeht.
Welche Modelle kann eine Air-Gapped-Bereitstellung nutzen?
Nur Modell-Endpunkte, die innerhalb Ihres Netzwerks erreichbar sind – typischerweise lokal gehostete Open-Weight-Modelle. Öffentliche README-Materialien nennen mehrere Modellfamilien; welche davon Sie lokal betreiben können und zu welchen Hardwarekosten, ist eine Infrastrukturentscheidung, die vor der vollständigen Isolation validiert werden muss.
Wie verifiziere ich, dass eine Bereitstellung tatsächlich air-gapped ist?
Testen Sie es: Führen Sie repräsentative Aufgaben aus und überwachen Sie dabei den ausgehenden Verkehr an der Netzwerkgrenze. Eine Bereitstellung ist nur dann air-gapped, wenn die Überwachung während Installation, Aufgabenausführung und Upgrades null ausgehende Verbindungen zeigt – nicht weil ein Diagramm es behauptet.
Macht Air-Gapped-Betrieb die Bereitstellung von selbst sicher?
Nein. Isolation beseitigt Exfiltrationspfade, aber keine Prompt-Injection, übermäßig berechtigte Anmeldedaten oder fehlende Review-Gates. Diese Kontrollen müssen innerhalb der Grenze weiterhin konfiguriert und getestet werden.
BEREITSTELLUNG PLANEN