OpenFactory-Dokumentation
OpenFactory bietet browserbasierte Linux-Evaluierung, Rezepte und Builds für eigene Images, Artefakt-Inspektion, VM-Tests und zugehörige Deployment-Workflows. Welche Funktionen genau für ein Konto oder eine selbst gehostete Konsole verfügbar sind, hängt von der ausgerollten Version, dem Tarif, Feature-Flags und der angebundenen Infrastruktur ab.
Mit einer Aufgabe starten
| Ziel | Dokumentationspfad |
|---|---|
| Ein eigenes Image erstellen und prüfen | Ihr erster Build |
| Normalisiertes Rezept-JSON verstehen | Rezept-Schema |
| Build-Features konfigurieren | Betriebssysteme bauen |
| VM starten und inspizieren | VM-Verwaltung |
| Nachweis nach dem Build definieren | Testing |
| MCP-Client anbinden | MCP-Integration |
| Lokale KVM-Konsole evaluieren | Selbst gehostete VM-Konsole |
| Zusammenarbeitsumfang verstehen | Rollen und Berechtigungsumfang |
Evidenzmodell
OpenFactory unterscheidet mehrere Zustände, die nicht zu einem einzigen Label „Erfolg“ zusammengefasst werden sollten:
- Rezeptvalidierung prüft die erkannte Konfigurationsform und die Abdeckung expliziter Anforderungen.
- Build-Abschluss bedeutet, dass ein Image-Artefakt seinen Finalisierungspfad erreicht hat.
- Test-Abschluss protokolliert das Ergebnis ausgewählter Gast-Assertions.
- Zertifizierungs- oder Policy-Status, sofern vorhanden, gilt nur für den benannten Evidenzvertrag.
- Physische oder produktive Qualifikation bleibt eine separate Aktivität, sofern nicht exakt die Hardware, Topologie, Fehlermodi und das Release getestet wurden.
Formulieren Sie die engste unterstützte Aussage. Ein Paket im Rezept ist kein Nachweis für die Installation; ein installiertes Paket ist kein Nachweis für einen gesunden Dienst; ein VM-Boot ist kein Nachweis dafür, dass ein Installer oder ein physisches Gerät funktioniert.
Grenzen: gehostet und selbst gehostet
Der gehostete Dienst enthält Image-Build- und Konversations-Workflows. Die eingecheckte selbst gehostete Compose-Bereitstellung ist eine privilegierte Single-Host-KVM-Konsole zur Evaluierung. Sie deaktiviert gehostete Builds, Konversationen, Scheduling und Policy-Dokument-Workflows und begründet allein weder Produktivbetrieb noch Air-Gap-Betrieb.
Für private Produktivbereitstellung nutzen Sie release-spezifische Architektur-, Identitäts-, Persistenz-, Backup-, Upgrade- und Support-Dokumentation, die mit OpenFactory vereinbart ist. Ersetzen Sie kein Marketing-Fähigkeitenverzeichnis oder die Evaluierungs-Compose-Datei durch dieses Runbook.
So lesen Sie diese Docs
- Befehle nennen, wo sinnvoll, Arbeitskontext und erwartetes Ergebnis.
- Sicherheits-, Compliance-, Verfügbarkeits- und Kompatibilitätsaussagen nennen ihre Evidenzgrenze.
- Wenn UI und statische Seite widersprechen, bewahren Sie Build- oder Run-ID und prüfen Sie API/Zustand, bevor Sie eine destruktive Aktion wiederholen.
- Melden Sie veraltete Dokumentation mit Seiten-URL, Produkt-Release oder Commit, Zeitstempel und beobachtetem Ergebnis.
Weiter mit Erste Schritte.