Werkstatt · In Release-Prüfung
fc-ctl ist eine selbst betreibbare Runtime für asynchrone Jobs in isolierten Firecracker-MicroVMs. Geprüfte OCI-Images laufen ohne Kubernetes mit klaren Grenzen für Laufzeit, Ressourcen, Netzwerk und Ausgabe.
Wie können SaaS-Produkte begrenzte Hintergrundjobs in der eigenen Infrastruktur ausführen, ohne ihnen Zugriff auf den Anwendungshost oder andere Workloads zu geben und ohne eine vollständige Cluster-Plattform zu betreiben?
01
Öffentliche Serverless-Angebote passen nicht immer zu den Anforderungen an Datenhoheit und Regulierung. Container teilen den Kernel ihres Hosts, vollständige Cluster-Plattformen sind für begrenzte Jobs oft zu aufwendig und kommerzielle Alternativen bringen Lizenzkosten oder Anbieterbindung mit sich.
02
Ein Controller verwaltet Jobs, Worker und Ergebnisse dauerhaft in SQLite; die Worker holen Arbeit selbstständig ab und benötigen keine eingehenden Verbindungen. Freigegebene OCI-Images werden als unveränderliche RootFS-Artefakte über S3 verteilt und lokal zwischengespeichert. Jeder Job startet standardmäßig kalt in einer kurzlebigen Firecracker-MicroVM mit eigener Jailer-Identität, kontrolliertem Netzwerk und Kommunikation über vsock. Signierte Anfragen, versuchsspezifische Leases, erst zur Laufzeit injizierte Geheimnisse sowie Ressourcen- und Ausgabegrenzen sichern den Lebenszyklus ab. Warm-Pools und Snapshots bleiben optional.
03
Controller, Worker, CLI, PHP-SDK, Image-Pipeline, Security-Härtung, Recovery, Metriken und Runbooks sind umgesetzt. Reale Linux-Tests mit Firecracker decken beide Gastprofile, Ressourcen- und Netzwerkgrenzen, S3-Störungen, Neustarts sowie Backup und Restore ab. Nach den dabei entstandenen Korrekturen fehlt noch ein sauberer Gesamtlauf mit dem unveränderten Release-Kandidaten. Das optionale private Netzwerk mit WireGuard und CoreDNS wartet noch auf seine separate Zwei-Worker-Prüfung.
04
Der unveränderte Kandidat wird noch einmal vollständig auf einer frischen Linux-Umgebung geprüft. Danach folgen die Abnahme von Monitoring und Backups sowie bei Bedarf die Zwei-Worker-Prüfung. Zusätzlich ist eine MCP-Schnittstelle geplant, über die Agents vollständige Workloads in isolierten Firecracker-MicroVMs konfigurieren, starten, überwachen und verwalten können. Der erste Einsatz bleibt ein kontrollierter interner Pilot als Runtime für s3s.sh.
