Generiert aus dem Techstack-Release v0.39.0 (Quelle
49677b729cb9). Für eine installierte Version ist techstack api <command> --help maßgeblich.techstack api servers detach
Genau einen vom Kunden betriebenen BYO-Server widerrufen und abkoppeln. Behält den terminalen kanonischen Server-Beleg und führt keinen Aufruf der Anbieter-API aus.techstack api servers get
Kanonischen Lebenszyklus, Verbindung, Health-Status und Kanäle eines Servers abrufen.techstack api servers list
Kanonischen Node-Runtime-Zustand auflisten. Gibt Owner-bezogene Nodes mit den kanonischen Identitätennode_id und kit_deployment_id zurück.
techstack api servers maintenance get
Einen Wartungs-Job eines eigenen Servers lesen. Gleich begrenzt wie der POST: das Edge-signierte Entitlementtechstack.servers.maintenance, der Tenant, die Ownership des Servers und ein Job, der zu diesem Server gehört und vom Aufrufer angefordert wurde. Alles andere liefert 404. Wartungs-Jobs haben ein eigenes Ledger und werden nicht über /api/v1/jobs/{id} ausgeliefert. Es gibt keinen Log-Endpoint: Der Job trägt sein Ergebnis, und ein Fehlschlag trägt seinen stabilen Code mit Hinweisen für den Benutzer.
techstack api servers maintenance run
Für einen eigenen Server einen OS-Update-Plan, ein OS-Update oder einen Neustart einreihen. Erfordert das Edge-signierte Entitlementtechstack.servers.maintenance, die Ownership des Servers im Tenant und für delegierte native MCP-Aufrufe eine aktuelle, an den Server gebundene dauerhafte Autorisierung. Diese drei gewöhnlichen Aktionen erfordern weder eine frische MFA noch eine separate owner_approved-Bestätigung. Der Body wird strikt dekodiert: exakte Schlüssel in Kleinbuchstaben, keine Duplikate, keine unbekannten Felder. Eine Wiederholung mit demselben Idempotency-Key gibt den gespeicherten Beleg vor der Zielvalidierung zurück. Pro Server darf ein Neustart oder OS-Update und getrennt davon ein Update-Plan aktiv sein; ein Job, der bis zu seiner Frist nicht fertig ist, schlägt mit deadline_exceeded fehl und gibt seinen Slot frei. Die Aktion wird in allowed_actions nur angeboten, wenn der Server-Agent stackkit.host-maintenance.v1 ankündigt, und reboot nur, wenn der Server außerdem host_boot_id meldet. Ablehnungen sind client-error-envelope/v1-Dokumente; der 409-reason_code ist einer von control_plane_host, substrate_node, protected_demo_server, service_locked, maintenance_active, node_operation_active, plan_stale, agent_capability_missing, boot_id_unknown, agent_not_connected, heartbeat_stale, inventory_revision_stale oder idempotency_key_reused; 403 trägt entitlement_required oder maintenance_origin_authority_denied.
techstack api servers network get
Die Netzwerkdaten des Servers und einen aufgezeichneten Heimnetzwechsel lesen. Das zuletzt von kombify Guard beobachtete Netzwerk des Servers (Adresse, Gateway, Subnetz, Schnittstelle, WLAN), der von kombify angelegtenetwork_move-Datensatz, als der Server in einem anderen Netzwerk erschien, und der Zustand der anschließenden erneuten Bindung. Ein versetzter Server bindet sich automatisch neu; can_rebind zeigt an, ob der Owner jetzt eine erneute Bindung starten kann.
techstack api servers network rebind
Einen versetzten Server an sein aktuelles Netzwerk neu binden. Führtstackkit network rebind über kombify Guard auf dem Server aus: Der Node erkennt seine LAN-Adresse erneut, stellt den signierten LAN-DNS-Verwahrungseintrag erneut aus und generiert und wendet den Workspace erneut an. Die Anfrage hat keinen Body. Erforderlich sind der Owner, die Inventory-Berechtigung operate, das Entitlement techstack.servers.maintenance und ein verbundener Guard (andernfalls 409 server_network_not_ready). Ist bereits eine erneute Bindung eingereiht oder aktiv, wird deren Job zurückgegeben, statt einen weiteren einzureihen.
techstack api servers ports
Das Port-Inventory des authentifizierten Owners für einen kanonischen Server abrufen. Projektion für die Server-Detail-UI über dieselbe zentrale Port-Autorität wie die Inventory-/MCP-Schnittstelle, autorisiert über die kanonische, Owner-bezogene Server-Lesegrenze.techstack api servers reach set
Den Server unter einer kombify.me-Adresse veröffentlichen oder die Veröffentlichung beenden. Standardmäßig wird nichts veröffentlicht: Ein gekoppelter Server hat keine öffentliche Route und das Relay überträgt keinen Verkehr. Der Owner aktiviert dies pro Server mit einem ausdrücklichenservice-Namen und target_port (der Ursprung ist immer die Loopback-Adresse des Guard-Hosts, niemals eine andere Maschine) und kann es jederzeit zurücknehmen. Das Relay authentifiziert den Guard, nicht den Besucher; der Dienst auf diesem Port muss sich deshalb selbst schützen. Die Aktivierung erfordert den Owner, das Entitlement techstack.servers.maintenance und eine frische Multi-Faktor-Anmeldung (Grund server_reach_step_up_required); die Rücknahme wird niemals dadurch blockiert. Die Antwort enthält den reach-Abschnitt des Server-Lesemodells; der Reconciler erstellt oder entfernt anschließend die Route.
techstack api servers security auto-repair get
Die Freigabe des Owners für automatische Sicherheitsreparaturen lesen. Ein Server ohne Freigabe oder mit einer abgelaufenen Freigabe wird nur beobachtet.techstack api servers security auto-repair set
Automatische Reparaturen einer kleinen, sicheren Auswahl von Kontrollelementen freigeben oder zurücknehmen. Standardmäßig deaktiviert. Eine Freigabe benennt Kontrollelemente aus der sicheren Auswahl (allowed_controls: Brute-Force-Schutz, Firewall-Richtlinie, Kernel-Parameter und automatische Sicherheitsupdates; niemals die SSH-Kontrollelemente), läuft innerhalb von 90 Tagen ab und erneuert sich nicht selbst. Solange sie gilt, repariert die Steuerungsebene ein benanntes Kontrollelement, für das frische Nachweise eine Abweichung zeigen, innerhalb derselben Grenzen wie bei einer Operator-Reparatur. Erforderlich sind der Owner, das Entitlement techstack.servers.maintenance und eine frische Multi-Faktor-Anmeldung. enabled: false nimmt die Freigabe zurück.
techstack api servers security findings
Die offenen Befunde und die jüngste Befundhistorie eines Servers auflisten. Das Befund-Ledger hintersecurity, recovery und den Guard-Meldungen des Servers. Ein Befund ist eine Episode: Er wird geöffnet, wenn eine Tatsache erstmals als falsch beobachtet wird, und aufgelöst, wenn sie wieder als richtig beobachtet wird, mit höchstens einer Meldung (alerted_at) und einer Auflösung. Die Historie bleibt 90 Tage erhalten.
techstack api servers security repairs list
Die jüngsten Sicherheitsreparaturen eines Servers auflisten.techstack api servers security repairs request
Benannte abweichende Host-Sicherheitskontrollelemente reparieren. Fordert eine begrenzte Reparatur von Kontrollelementen an, die frische Host-Sicherheitsnachweise als abweichend und automatisch reparierbar ausweisen. Erforderlich sind der Server-Owner, das Edge-signierte Entitlementtechstack.servers.maintenance und eine frische Multi-Faktor-Anmeldung (höchstens 300 Sekunden alt). Die Reparatur wird als typisierter, journalisierter Guard-Befehl übertragen, der stackkit host security repair --apply für genau die benannten Kontrollelemente ausführt. StackKits lehnt vor jeder Änderung eine Änderung ab, die den Verwaltungsweg unterbrechen oder den Owner aussperren würde. Grenzen: jeweils eine Reparatur pro Server (409 repair_in_progress), eine Wartezeit pro Kontrollelement (429 repair_cooldown), ein tägliches Versuchslimit pro Kontrollelement (429 repair_attempts_exhausted) und eine Sicherung nach aufeinanderfolgenden Fehlern (429 repair_circuit_open); die 429-Antworten enthalten retry_after. Ein konformes Kontrollelement (409 control_not_drifted), eines mit genehmigter Ausnahme (control_has_exception), ein manuelles (control_not_repairable), eines ohne erforderlichen autorisierten SSH-Schlüssel (needs_authorized_key) oder ein nicht beobachtetes wird abgelehnt. Der Body wird strikt dekodiert.
techstack api servers security verify
kombify Guard um eine frische Beobachtung der Host-Sicherheit bitten. Hält fest, dass eine frische Beobachtung der Host-Baseline angefordert ist. Der Guard antwortet beim nächsten Check-in (innerhalb etwa einer Minute) mit einem neuen Bericht; auf dem Host wird nichts verändert. Dassecurity-Lesemodell des Servers wird ausschließlich durch diesen Bericht aktualisiert, nie durch diese Anfrage. Ein Server eines anderen Tenants oder Owners liefert 404; ein Server ohne Guard liefert 409 guard_not_connected.