Generado a partir del release v0.32.8 de Techstack (fuente
4c7d219a5d56). Para una versión instalada, techstack api <command> --help es la fuente autorizada.techstack api stacks create
Crea un despliegue de StackKit en el Homelab del propietario. Crea un despliegue interno de StackKit bajo el Homelab único del propietario B2C autenticado a partir de la carga útil canónica de stack-spec de StackKits indicada comostack_spec. La ruta heredada /stacks y el campo de respuesta stack_id identifican ese despliegue; no crean ni seleccionan un segundo producto Homelab. Una instancia de TechStack puede servir a muchos propietarios, cada uno con su propio Homelab. Las cargas útiles heredadas user_config/kombination se siguen aceptando en este límite de compatibilidad. Los clientes del asistente deben enviar un X-Idempotency-Key estable; los reintentos con la misma clave y la misma carga útil devuelven el despliegue, el servidor planificado y el trabajo de aprovisionamiento originales.
techstack api stacks deploy
Implanta un despliegue de StackKit (unify + IaC + tofu apply).techstack api stacks destroy
Da de baja un despliegue de StackKit y su infraestructura.techstack api stacks drift check
Lanza una comprobación de deriva. Limitado a una vez cada 5 minutos (salvo con force=true)techstack api stacks drift details
Obtiene información detallada de la deriva con los recursos afectados.techstack api stacks drift resolve
Lanza la resolución de la deriva (volver a aplicar). Condición previa: el stack debe tener el estado “drifted”techstack api stacks drift status
Obtiene el estado actual de la deriva.techstack api stacks export
Exporta el stack como stack-spec.yaml. Devuelve el stack-spec de StackKits en YAML o JSON según el encabezado Accepttechstack api stacks import
Importa stack-spec.yaml como despliegue de StackKit. Importa YAML o JSON como despliegue bajo el Homelab del propietario autenticado.techstack api stacks intent
Obtiene el kombination.yaml persistido (byte a byte, base64).techstack api stacks list
Lista los despliegues de StackKit del propietario. Devuelve todos los despliegues de StackKit bajo el Homelab B2C único del propietario autenticado.kit_deployment_id, homelab_id y stackkit_id son las identidades del producto; los identificadores heredados siguen siendo alias de compatibilidad en esta ruta mientras los consumidores migran.
techstack api stacks managed-runtimes add
Añade un Node gestionado mediante el control nativo del proveedor. Crea o reanuda un trabajo determinista de Add-Server para el despliegue de StackKit propio exacto. ElIdempotency-Key estándar es obligatorio. Repetir la misma clave con la misma solicitud canónica devuelve las correlaciones originales de trabajo, arrendamiento, servidor de runtime, generación de recursos y operación del proveedor; reutilizarla con otra intención falla con 409.
La clave sin procesar nunca se persiste ni se devuelve. Una respuesta perdida o un resultado incierto de la admisión nativa solo se puede reanudar con la misma clave. La aceptación HTTP significa que la admisión nativa es duradera y la reconciliación con el proveedor está pendiente; nunca afirma que la VM ya esté aprovisionada o sana. Una admisión nueva reserva de forma atómica la ranura de capacidad del tenant/propietario autenticado junto con la generación del arrendamiento y la operación del proveedor. Cuando la admisión nativa autorizada encuentra llena esa capacidad acotada, persiste un resultado 403 no reintentable, y repetir ese trabajo denegado devuelve el mismo resultado. Las repeticiones exactas de una admisión ya confirmada reutilizan su reserva existente. Esta versión no libera reservas automáticamente: un estado terminal o de baja local por sí solo no libera una ranura. El inventario de arrendamientos y los flags de entrega de funciones nunca autorizan ni deniegan capacidad. En el modo alojado, una admisión nueva también requiere los derechos comerciales de runtime y de proveedor firmados con v2, además de la decisión firmada de modo y límite cloud.runtime.credits managed_servers; los feature flags por sí solos nunca conceden capacidad del proveedor. El OSS autoalojado usa en su lugar su política estática de manifiesto de release, fijada en la construcción, sin depender de un derecho SaaS.
techstack api stacks operations
Obtiene el modelo de lectura de operaciones posteriores a la configuración de un despliegue de StackKit propio. Devuelve exactamente el modelo de lectura limitado al propietario y al tenant que usa el panel de operaciones de TechStack.approved_servers registra la aprobación del operador; connected_servers es más estricto y cuenta solo los Node asignados y aprobados con evidencia canónica de heartbeat, conexión y salud de Guard con indicación de actualidad. La operación es de solo lectura y nunca inicia una implantación, un aprovisionamiento ni trabajo del proveedor.
techstack api stacks owner-spec
Obtiene la especificación de arranque del propietario para un despliegue de StackKit. Endpoint de arranque de administración de StackKit para obtener los campos del propietario local y el hash de la frase de recuperación. Esta ruta solo acepta el token Bearer de arranque de corta duración que devuelvecreateStack; no usa el token Bearer normal de navegador o de sesión.
techstack api stacks pipeline-status
Obtiene el estado completo del pipeline para todas las fases de la especificación.techstack api stacks provision
Inicia el aprovisionamiento de un despliegue de StackKit existente.techstack api stacks prune-orphans
Revisa o aplica la limpieza de residuos de pruebas limitada al propietario. Limpieza en dos fases solo para proyecciones del plano de control. Undry_run devuelve exactamente los candidatos E2E/runtime-cloud del propietario autenticado y un digest estable ligado a la revisión. apply vuelve a calcular el plan y solo acepta ese digest exacto. Esta ruta nunca da de baja un arrendamiento, llama a un proveedor, destruye infraestructura ni pone en cola trabajo del ciclo de vida.
techstack api stacks requirements
Obtiene la especificación de requisitos (salida de la fase 1).techstack api stacks resume-enrollment
Reanuda una espera vencida de un Node gestionado en su VM exacta existente. Recuperación autenticada e idempotente de un trabajo persistido enwaiting_enrollment, waiting_provider_provision o waiting_canonical_guard cuyo next_resume_at lleva vencido más allá del periodo de gracia acotado. El servidor valida el despliegue de StackKit propio, el trabajo de origen, el motivo de la espera, el arrendamiento exacto, el rol foundation activo y el Node canónico como una sola operación. Retira de forma atómica la espera de origen exacta, crea o rehidrata un único despliegue de sustitución determinista ligado al mismo arrendamiento y Node, y reproduce ese trabajo en llamadas posteriores. Antes de entrar en el handler, los workers de la cola adquieren de forma atómica la reclamación duradera de ejecución de compatibilidad tenant/stack; esto serializa distintos trabajos del mismo despliegue de StackKit entre réplicas de Techstack. La reclamación sigue en running de forma duradera hasta que el handler termina, también durante una cancelación. Este endpoint nunca invoca la creación de VM en el proveedor ni selecciona una VM más nueva. Una sustitución que se encuentra en running duradero tras un fallo sigue cerrada ante fallos, se informa como el mismo trabajo y nunca se duplica automáticamente; la reconciliación de acciones de runtime sigue siendo una tarea aparte del operador.
techstack api stacks retry-rollout
Reintenta una implantación fallida de un despliegue de StackKit en su VM gestionada exacta existente. Valida el despliegue fallido propio, su arrendamiento foundation activo exacto y el Node canónico en una sola operación del lado del servidor. La sustitución duradera determinista omite la creación de VM en el proveedor, obtiene una reclamación duradera de ejecución de compatibilidadtenant/stack antes de entrar en el handler y se reproduce en las llamadas repetidas a esta operación. La reclamación serializa distintos trabajos del mismo despliegue de StackKit entre réplicas y sigue cerrada ante fallos como running tras la caída de un proceso hasta la reconciliación del operador.
techstack api stacks routing ensure
Garantiza la capa de enrutamiento deseada para un despliegue de StackKit y un Node exactos. Persiste de forma atómica una capa de enrutamiento idempotente y con revisiones sin modificar la intención inmutable del usuario. server_id siempre es exacto y obligatorio. lease_id es obligatorio para los runtimes gestionados y se omite para un runtime local/Basement, que no tiene arrendamiento. Para un destino gestionado, una solicitud con ensure_rollout en true despacha el pipeline de despliegue existente solo después de demostrar que su arrendamiento foundation activo seleccionado y su Node canónico coinciden con este destino exacto. La API nunca informa del trabajo resultante como ya aplicado. La capa solo se consume al derivar los artefactos de StackKits, y esta ruta nunca crea ni selecciona una VM de sustitución.techstack api stacks routing get
Lee el estado de enrutamiento deseado y observado de un despliegue de StackKit. Devuelve la capa de enrutamiento ligada al tenant y al propietario para el despliegue de StackKit exacto. El estado deseado y el estado observado/aplicado se informan por separado para que los clientes nunca deduzcan un DNS, un TLS o una implantación de StackKit correctos solo a partir de la persistencia.techstack api stacks routing targets
Lista los destinos de enrutamiento principales explícitos de un despliegue de StackKit. Descubrimiento de solo lectura respaldado por la autoridad activa de RuntimeLease. Devuelve todos los destinos foundation/control-plane visibles para el propietario y nunca selecciona uno, crea una proyección de Node canónico (ServerRuntime) ni modifica el despliegue de StackKit. Quienes llaman deben enviar la tupla completa de server_id y lease_id a una mutación de enrutamiento.