Generiert aus dem Techstack-Release v0.32.8 (Quelle
4c7d219a5d56). Für eine installierte Version ist techstack api <command> --help maßgeblich.techstack api stacks create
Ein StackKit-Deployment im Homelab des Owners erstellen. Erstellt ein internes StackKit-Deployment unter dem Singleton-Homelab des authentifizierten B2C-Owners aus dem kanonischen StackKits-stack-spec-Payload, der alsstack_spec übergeben wird. Die Legacy-Route /stacks und das Antwortfeld stack_id bezeichnen dieses Deployment; sie erstellen oder wählen kein zweites Homelab-Produkt. Eine TechStack-Instanz kann viele Owner bedienen, jeder mit seinem eigenen Homelab. Legacy-Payloads im Stil user_config/kombination werden an dieser Kompatibilitätsgrenze weiterhin akzeptiert. Wizard-Clients sollten einen stabilen X-Idempotency-Key senden; Wiederholungen mit demselben Key und Payload geben das ursprüngliche Deployment, den geplanten Server und den Bereitstellungs-Job zurück.
techstack api stacks deploy
Ein StackKit-Deployment ausrollen (unify + IaC + tofu apply).techstack api stacks destroy
Ein StackKit-Deployment und seine Infrastruktur stilllegen.techstack api stacks drift check
Drift-Prüfung auslösen. Auf einmal pro 5 Minuten begrenzt (außer bei force=true)techstack api stacks drift details
Detaillierte Drift-Informationen mit betroffenen Ressourcen abrufen.techstack api stacks drift resolve
Drift-Behebung auslösen (erneutes Anwenden). Vorbedingung — der Stack muss den Status “drifted” habentechstack api stacks drift status
Aktuellen Drift-Status abrufen.techstack api stacks export
Stack als stack-spec.yaml exportieren. Gibt je nach Accept-Header StackKits-stack-spec als YAML oder JSON zurücktechstack api stacks import
stack-spec.yaml als StackKit-Deployment importieren. Importiert YAML oder JSON als Deployment unter dem Homelab des authentifizierten Owners.techstack api stacks intent
Gespeicherte kombination.yaml abrufen (byte-genau, base64).techstack api stacks list
Die StackKit-Deployments des Owners auflisten. Gibt jedes StackKit-Deployment unter dem Singleton-B2C-Homelab des authentifizierten Owners zurück.kit_deployment_id, homelab_id und stackkit_id sind die Produktidentitäten; Legacy-Bezeichner bleiben auf dieser Route als Kompatibilitäts-Aliasse erhalten, während Consumer migrieren.
techstack api stacks managed-runtimes add
Einen verwalteten Node über native Provider Control hinzufügen. Erstellt oder setzt genau einen deterministischen Add-Server-Job für das exakte eigene StackKit-Deployment fort. Der Standard-Idempotency-Key ist Pflicht. Eine Wiederholung mit demselben Key und derselben kanonischen Anfrage gibt die ursprünglichen Korrelationen von Job, Lease, Runtime-Server, Ressourcengeneration und Anbieter-Operation zurück; die Wiederverwendung mit abweichendem Intent schlägt mit 409 fehl.
Der rohe Key wird nie gespeichert oder zurückgegeben. Eine verlorene Antwort oder ein unsicheres Ergebnis der nativen Zulassung bleibt nur mit demselben Key fortsetzbar. Eine HTTP-Annahme bedeutet, dass die native Zulassung dauerhaft gespeichert ist und die Reconciliation beim Anbieter aussteht; sie behauptet nie, dass die VM bereits bereitgestellt oder gesund ist. Eine neue Zulassung reserviert den Kapazitäts-Slot des authentifizierten Tenants/Owners atomar zusammen mit der Lease-Generation und der Anbieter-Operation. Stellt die maßgebliche native Zulassung fest, dass diese begrenzte Kapazität voll ist, speichert sie ein nicht wiederholbares 403-Ergebnis, und eine Wiederholung dieses abgelehnten Jobs gibt dasselbe Ergebnis zurück. Exakte Wiederholungen einer bereits festgeschriebenen Zulassung verwenden deren bestehende Reservierung weiter. Diese Version gibt Reservierungen nicht automatisch frei: Ein terminaler oder lokaler Stilllegungszustand allein gibt keinen Slot frei. Lease-Inventory und Feature-Delivery-Flags autorisieren oder verweigern nie Kapazität. Eine gehostete neue Zulassung erfordert außerdem die v2-signierten kommerziellen Runtime- und Anbieter-Entitlements sowie die signierte Modus-/Limit-Entscheidung cloud.runtime.credits managed_servers; Feature-Flags allein gewähren nie Anbieter-Kapazität. Self-Host-OSS verwendet statt einer SaaS-Entitlement-Abhängigkeit seine bei der Konstruktion festgelegte statische Release-Manifest-Richtlinie.
techstack api stacks operations
Das Operations-Lesemodell nach der Konfiguration für ein eigenes StackKit-Deployment abrufen. Gibt das exakte, auf Owner und Tenant begrenzte Lesemodell zurück, das das TechStack-Operations-Dashboard verwendet.approved_servers hält die Freigabe durch den Operator fest; connected_servers ist strenger und zählt nur zugewiesene, freigegebene Nodes mit aktuellen kanonischen Guard-Nachweisen zu Heartbeat, Verbindung und Health. Die Operation ist schreibgeschützt und startet nie einen Rollout, eine Bereitstellung oder Arbeit beim Anbieter.
techstack api stacks owner-spec
Die Owner-Bootstrap-Spezifikation für ein StackKit-Deployment abrufen. StackKit-Admin-Bootstrap-Endpoint zum Abrufen lokaler Owner-Felder und des Hashs der Wiederherstellungs-Passphrase. Diese Route akzeptiert nur das kurzlebige Bootstrap-Bearer-Token, dascreateStack zurückgibt; sie verwendet nicht das normale Browser-/Session-Bearer-Token.
techstack api stacks pipeline-status
Vollständigen Pipeline-Status für alle Spezifikationsphasen abrufen.techstack api stacks provision
Die Bereitstellung eines bestehenden StackKit-Deployments starten.techstack api stacks prune-orphans
Owner-bezogene Bereinigung von Testrückständen prüfen oder anwenden. Zweiphasige Bereinigung nur für Control-Plane-Projektionen. Eindry_run gibt die exakten E2E-/runtime-cloud-Kandidaten des authentifizierten Owners und einen stabilen, revisionsgebundenen Digest zurück. apply berechnet den Plan neu und akzeptiert nur genau diesen Digest. Diese Route legt nie eine Lease still, ruft nie einen Anbieter auf, zerstört keine Infrastruktur und reiht keine Lebenszyklus-Arbeit ein.
techstack api stacks requirements
Anforderungsspezifikation abrufen (Ausgabe von Phase 1).techstack api stacks resume-enrollment
Eine überfällige Wartephase eines verwalteten Node auf seiner exakten bestehenden VM fortsetzen. Authentifizierte, idempotente Wiederherstellung für einen gespeichertenwaiting_enrollment-, waiting_provider_provision- oder waiting_canonical_guard-Job, dessen next_resume_at über die begrenzte Kulanzzeit hinaus überfällig ist. Der Server validiert das eigene StackKit-Deployment, den Quell-Job, den Wartegrund, die exakte Lease, die aktive Foundation-Rolle und den kanonischen Node als eine Operation. Er beendet die exakte Quell-Wartephase atomar, erstellt oder rehydriert genau ein deterministisches Ersatz-Deploy, das an dieselbe Lease und denselben Node gebunden ist, und wiederholt diesen Job bei späteren Aufrufen. Vor dem Eintritt in den Handler erwerben Queue-Worker atomar den dauerhaften tenant/stack-Kompatibilitäts-Ausführungsanspruch; dadurch werden verschiedene Jobs für dasselbe StackKit-Deployment über Techstack-Replikas hinweg serialisiert. Der Anspruch bleibt dauerhaft running, bis der Handler endet, auch während eines Abbruchs. Dieser Endpoint löst nie die Erstellung einer VM beim Anbieter aus und wählt nie eine neuere VM. Ein Ersatz, der nach einem Absturz als dauerhaft running vorgefunden wird, bricht sicher ab, wird als derselbe Job gemeldet und nie automatisch dupliziert; die Reconciliation von Runtime-Aktionen bleibt eine separate Aufgabe des Operators.
techstack api stacks retry-rollout
Einen fehlgeschlagenen StackKit-Deployment-Rollout auf seiner exakten bestehenden verwalteten VM erneut versuchen. Validiert das eigene fehlgeschlagene Deploy, seine exakte aktive Foundation-Lease und den kanonischen Node in einer serverseitigen Operation. Der deterministische, dauerhafte Ersatz umgeht die Erstellung einer VM beim Anbieter, gewinnt vor dem Eintritt in den Handler einen dauerhaftentenant/stack-Kompatibilitäts-Ausführungsanspruch und wird bei wiederholten Aufrufen dieser Operation wiederholt. Der Anspruch serialisiert verschiedene Jobs für dasselbe StackKit-Deployment über Replikas hinweg und bleibt nach einem Prozessabsturz als running stehen, sodass die Ausführung sicher abbricht, bis ein Operator die Reconciliation durchführt.
techstack api stacks routing ensure
Das gewünschte Routing-Overlay für genau ein StackKit-Deployment und einen Node sicherstellen. Speichert atomar ein idempotentes, revisioniertes Routing-Overlay, ohne den unveränderlichen Intent des Benutzers zu ändern. server_id ist immer exakt und Pflicht. lease_id ist für verwaltete Runtimes Pflicht und entfällt für eine lokale/Basement-Runtime, die keine Lease hat. Bei einem verwalteten Ziel startet eine Anfrage mit ensure_rollout=true die bestehende Deploy-Pipeline erst, nachdem nachgewiesen ist, dass ihre gewählte aktive Foundation-Lease und ihr kanonischer Node genau diesem Ziel entsprechen. Die API meldet den resultierenden Job nie als bereits angewendet. Das Overlay wird nur beim Ableiten der StackKits-Artefakte verwendet, und dieser Pfad erstellt oder wählt nie eine Ersatz-VM.techstack api stacks routing get
Gewünschten und beobachteten Routing-Zustand für ein StackKit-Deployment lesen. Gibt das an Tenant und Owner gebundene Routing-Overlay für das exakte StackKit-Deployment zurück. Der gewünschte Zustand und der beobachtete/angewendete Zustand werden getrennt gemeldet, damit Clients aus der Speicherung allein nie auf einen erfolgreichen DNS-, TLS- oder StackKit-Rollout schließen.techstack api stacks routing targets
Ausdrückliche primäre Routing-Ziele für ein StackKit-Deployment auflisten. Schreibgeschützte Discovery auf Grundlage der aktiven RuntimeLease-Autorität. Gibt jedes für den Owner sichtbare Foundation-/Control-Plane-Ziel zurück und wählt nie eines aus, erstellt keine kanonische Node-Projektion (ServerRuntime) und ändert das StackKit-Deployment nicht. Aufrufer müssen das vollständige Tupel aus server_id und lease_id an eine Routing-Änderung senden.