Warum Vigo
Einfachheit, Sicherheit, Zuverlässigkeit, Skalierbarkeit und Preis — wo Vigo sich von jedem anderen Konfigurationsmanagement-System unterscheidet.
Eine Ressource. Eine Datei.
Einen Benutzer mit passwortlosem Sudo und einem SSH-Schlüssel anlegen — eine Aufgabe, die jedes Team erledigt. In Vigo ist das eine einzige Ressource in einer einzigen Datei, mit integrierten SSH-Schlüsseln, Sudo und Secrets.
name: os-users resources: - name: alice type: user username: alice comment: Alice Nguyen shell: /bin/bash groups: sudo, adm state: present password: secret:vigo/os-users/alice sudo_nopasswd: true authorized_keys: | ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJqR... alice@laptop
📄 Einfachheit
Ein Server bei jeder Skalierung
Keine Compile-Master, keine Worker-Pools, keine Datenbankcluster, keine Load-Balancer. Ein Prozess, eine SQLite-Datei, ein Konfigurationsverzeichnis. Die Architektur ändert sich nicht, unabhängig davon, ob Sie 10 oder 100.000 Knoten verwalten.
~8 MiB statische Agent-Binary
Kein Ruby, kein Python, keine JVM, kein Paketmanager-Ökosystem auf verwalteten Knoten. Kopieren Sie die Binary, führen Sie sie aus. Null Laufzeitabhängigkeiten.
Ein Konfigurationsformat, ein Konfigurationspfad
Es gibt genau einen Weg, Vigo zu konfigurieren: YAML-Dateien bearbeiten und veröffentlichen. Keine API-Schreibvorgänge, keine Datenbankkonfiguration, keine UI-Mutationen. Eine einzige Quelle der Wahrheit, ein Format, ein Werkzeug.
Keine DSL
Die Konfigurationssprache ist YAML. Go-Templates erscheinen nur innerhalb von content:-Attributen. Keine eigene Sprache zu erlernen, kein Compiler, keine Parser-Eigenheiten.
Bootstrap mit einem Befehl
curl | sudo sh lädt die Binary herunter, generiert TLS-Zertifikate, registriert sich beim Server, installiert den Dienst und verifiziert die Verbindung. In 30 Sekunden unter Verwaltung.
Sieben BS-Familien aus einer Codebasis
Linux, macOS, FreeBSD, OpenBSD, NetBSD, illumos und Windows. Schreiben Sie type: service und es leitet an systemd, launchctl, rc.d, rcctl, SMF oder sc.exe weiter.
Bedingte Ressourcen ohne if-DSL
when: "os_family('debian')" auf jeder Ressource oder jedem configcrate. Boolesche Logik, integrierte Funktionen wie has_command, arch, version_ge. Der Server wertet aus, was möglich ist, übergibt den Rest an den Agent. Keine DSL, keine Plugins.
Transparenz — jede Entscheidung bis zur Quelle zurückverfolgen
Ein Befehl — vigocli config trace danlap — zeigt die vollständige Auflösungskette für jeden Knoten. Jedes configcrate, jede Variable, jede Abhängigkeit, jedes Compliance-Tag, jede Ausnahme und jede Bedingung bis zur genauen Datei zurückverfolgt, die sie definiert hat.
when:-Ausdruck mit seiner Auswertungsseite. Serverseitige Bedingungen (wie changed) werden vor dem Versand aufgelöst; agentseitige Bedingungen (wie os_family und hour_range) werden auf dem verwalteten Knoten ausgeführt. Template-Variablen werden aufgelöst und unter dem ursprünglichen Ausdruck angezeigt.
🔒 Sicherheit
ED25519-Signaturen pro Anfrage
Jede Agent-Anfrage wird individuell signiert und gegen gespeicherte öffentliche Schlüssel verifiziert. Nicht nur TLS — tatsächlicher kryptografischer Identitätsnachweis bei jedem API-Aufruf. Replay- und Identitätswechsel-Angriffe erfordern den privaten Schlüssel, nicht nur ein gültiges Zertifikat.
Secrets werden nie materialisiert
Das secret:-Präfix wird beim Laden der Konfiguration durch einen pluggbaren Provider aufgelöst und vor der Übertragung entfernt. Secrets erscheinen nie in YAML-Dateien, Umgebungsvariablen, Logs, Datenbankzeilen, gRPC-Payloads oder Ausführungsergebnisberichten.
Kein Klartextmodus
mTLS ist der einzige Transport. Es gibt kein --no-ssl-Flag, keinen Klartextfallback, keinen „Entwicklungsmodus", der die Verschlüsselung überspringt. Der unsichere Pfad existiert nicht im Quellcode.
Einmalige Registrierungstoken
Token werden bcrypt-gehasht im Ruhezustand gespeichert und an Hostname-Glob-Muster gebunden. Ein Token, das zu *.web.prod passt, kann keinen Rechner namens db01.staging registrieren. Einmal verwendet, dann dauerhaft ungültig gemacht.
Selbstschutz-Absicherungen
Die Validierungspipeline blockiert jede Ressource, die auf die Agent-Binary, die Server-Binary, das Konfigurationsverzeichnis oder die Serviceunit abzielt. Selbst der --dangerous-Modus kann diese Prüfungen nicht umgehen. Das System kann nicht dazu verwendet werden, sich selbst zu zerstören.
Verifizierte Agent-Binary
Die Agent-Binary wird mit ED25519-Signaturen und SHA-256-Prüfsummen verteilt, die beim Bootstrap verifiziert werden. Binary-Härtung umfasst PIE, vollständiges RELRO, Stack-Schutz, entfernte Symbole und LTO.
⚡ Zuverlässigkeit
Idempotenz beim Veröffentlichen erzwungen
Die meisten CM-Tools behandeln Idempotenz als eine Disziplin, die der Operator aufrechterhalten muss. Vigo macht sie zu einer Invariante beim Veröffentlichen: config publish validiert Idempotenz zusammen mit der Syntax, sodass nicht-idempotente Konfigurationen beim Veröffentlichen fehlschlagen, anstatt in die Flotte zu gelangen. Sie gilt, weil jeder Executor nach dem Prinzip „prüfen vor dem Handeln" vorgeht — file: vergleicht einen SHA-256, package: prüft die installierte Version, service: prüft is-active/is-enabled, bevor etwas unternommen wird. Eine Ressource 86.400 Mal täglich im Sekundentakt neu zu bewerten führt zu null Änderungen und null Audit-Rauschen, bis etwas tatsächlich driftet.
Signierte Policy-Bundles mit Offline-Konvergenz
Der Server signiert Bundles mit ED25519. Der Agent verifiziert, cached in LMDB und konvergiert unbegrenzt weiter, wenn der Server verschwindet. Ausstehende Ergebnisse werden in eine Warteschlange gestellt und bei Wiederverbindung geleert.
Adaptive Stream-Promotion
Agents verwenden standardmäßig leichtes zustandsloses Polling. Persistente Streams werden nur gefördert, wenn der Server Arbeit zu verteilen hat, und dann freigegeben. Idle-Agents verbrauchen null Stream-Ressourcen.
Auswertungsausfallsicherheit
Ein Template-Render-Fehler oder ein when:-Parse-Fehler in einer Ressource überspringt diese Ressource und fährt mit dem Rest der Konvergenzausführung fort. Eine einzelne fehlerhafte Ressource bricht nicht die gesamte Policy ab.
Null Datenbankoperationen auf dem Hot Path
Der FleetIndex ist ein vollständig In-Memory-Index mit asynchronem Dirty-Set-Flushing. Ein Agent-Prüfintervall — Lookup, Policy-Kompilierung und Antwort — berührt null Datenbankabfragen.
Der Agent beendet sich nie bei vorübergehenden Fehlern
Server nicht erreichbar, TLS-Handshake-Fehler, fehlerhafte Antwort, Policy-Auswertungsabsturz — alles wird mit Backoff und Wiederholung behandelt. Die Agent-Binary, einmal gestartet, läuft bis zum expliziten Stopp.
Reload mit graceful Fallback
Konfigurations-Publish validiert, synchronisiert und lädt neu. Wenn die neue Konfiguration die Validierung nicht besteht, behält der Server die vorherige funktionierende Konfiguration. Keine Ausfallzeit, kein Teilzustand.
Browser- und CLI-Fernzugriff (Scrier)
SSH-Terminals, RDP-Desktops und Live-Sitzungsüberwachung über die Web-UI — oder vigocli scrier ssh von Ihrem Terminal über denselben Tunnel. Kein VPN, kein Bastion, keine Port-Weiterleitung. Tunnelt über die bestehende mTLS-Verbindung des Agents. Ephemere Schlüssel pro Sitzung. Shadow/Assist-Modus ermöglicht dem Helpdesk, den Live-Desktop eines Benutzers mit Einwilligung zu sehen und zu steuern.
Beobachtungsmodus für sichere Migration
Betreiben Sie Vigo neben bestehendem CM. Agents melden, was sie ändern würden, ohne irgendetwas anzuwenden. Wechseln Sie, wenn Sie sicher sind. Pro Knoten oder flottenweite.
📈 Skalierbarkeit
Zehntausende envoys pro Server
Auf einem einzigen 8 vCPU / 32 GB-Rechner, live gemessen — ~7.450 envoys beim Standardintervall von einer Sekunde, ~30.000 bei größerem Intervall. Sie bestimmen das Intervall; die Kapazität skaliert linear mit Kernen und RAM. Keine Compile-Master, keine Worker-Pools, keine Datenbankcluster. Analyse ansehen →
Mikrosekunden-Hot-Path
Die Pro-Prüfintervall-Hauptarbeit ist eine ~53 µs ED25519-Signaturverifizierung (benchmarked); die Zeitstempel-Prüfung, der Index-Lookup und der Hash-Vergleich sind jeweils Sub-Mikrosekunden. Keine Katalogkompilierung, keine Ruby-Interpretation, null Datenbankabfragen auf dem Hot Path — weshalb ein Intervall von einer Sekunde zuerst die CPU bindet und ein größeres den Arbeitsspeicher.
Linearer, gemessener Speicherbedarf
~220 KB pro verbundenem envoy für den gehaltenen Stream, ~623 KB insgesamt, sobald sein Inventar zwischengespeichert ist — live gemessen, exakt linear mit dem RAM. Kleine Flotten laufen komfortabel auf einem Raspberry Pi.
Keine externe Datenbank
SQLite im WAL-Modus. Kein PostgreSQL-Cluster zu provisionieren, zu tunen, zu sichern, zu aktualisieren oder um 3 Uhr morgens am Leben zu erhalten. Die Datenbank ist eine einzelne Datei, die Sie mit cp kopieren können.
Delta-Streaming-Protokoll
Nach dem ersten Prüfintervall senden Agents nur das Geänderte — Trait-Deltas, Ausführungsabschlüsse, Heartbeats. Keine redundanten vollständigen Zustandsübertragungen bei jedem Zyklus.
Peer-Federation (Spanner) für mehrere Regionen
Wenn ein Server nicht ausreicht, verteilt Spanner Registrierung, Abfragen und Aufgaben auf schreibgleiche Peer-Server. Jeder Peer verwaltet seine eigene Partition der Flotte und aggregiert Ergebnisse von den anderen. Keine gemeinsame Datenbank.
💰 Preis
Kostenlos für 100 Knoten. Kein Zeitlimit.*
Keine Kreditkarte, keine Funktionsbeschränkungen. Jede Fähigkeit — Orchestrierung, Workflows, Abfragen, native Integrationen, Compliance-Export, KI-Assistent — ist in jeder Stufe enthalten.
Keine exklusiven Enterprise-Funktionen
Es gibt keine „Enterprise Edition" mit zurückgehaltenen kritischen Funktionen. RBAC, OIDC, API-Token, Compliance-Export, Spanner — alles enthalten. Die kostenlose Stufe ist das vollständige Produkt.
Infrastrukturkosten: nahezu null
Ein Prozess, eine SQLite-Datei, ~6 GB RAM bei 10.000 envoys. Kein PostgreSQL-Cluster, kein Redis, keine Nachrichtenwarteschlange, keine Compile-Master-Flotte. Der Server, auf dem Ihr Monitoring läuft, kann auch Vigo betreiben.
Keine Pro-Knoten-Agent-Lizenzierung
Die Agent-Binary ist frei verteilbar. Sie zahlen für die serverseitige Knotenanzahl, nicht pro Agent-Installation. Außer Betrieb nehmen und neu registrieren ohne Lizenz-Wechsel.
Einfache Pro-Knoten-Preisgestaltung
$144/Knoten/Jahr ab 101 Knoten, sinkend auf $96/Knoten/Jahr im großen Maßstab. Mengenrabatte sind automatisch. Kein Verkaufsgespräch erforderlich bis 5.000+ Knoten.
Niedrigste Gesamtbetriebskosten
Die Lizenz ist die einzige bedeutende Koste. Keine Compile-Master, kein PostgreSQL-DBA, keine dedizierten CM-Ingenieure — der Server, auf dem Ihr Monitoring läuft, kann auch Vigo betreiben.
Sehen Sie, wie es im Vergleich abschneidet
Ein detaillierter Vergleich mit den etablierten Konfigurationsmanagement-Tools und Leitfäden für den Umstieg.
* Die kostenlose Stufe wird OHNE MÄNGELGEWÄHR und ohne Supportverpflichtung bereitgestellt. Siehe Kommerzielle Bedingungen.