Skip to main content
Generado a partir del release v0.39.0 de Techstack (fuente 49677b729cb9). Para una versión instalada, techstack api <command> --help es la fuente autorizada.

​
techstack api servers detach

Revoca y desvincula un servidor BYO exacto operado por el cliente. Conserva el recibo terminal del servidor canónico y no realiza ninguna llamada a la API del proveedor.
Requiere confirmación. Esta operación revoca las credenciales del servidor y lo retira de la gestión sin tocar la máquina. Pasa --yes o responde a la pregunta; una ejecución no interactiva sin --yes se detiene antes de cualquier solicitud con el código de salida 9.

​
techstack api servers get

Obtiene el ciclo de vida, la conexión, la salud y los canales canónicos del servidor.

​
techstack api servers list

Lista el estado canónico del runtime de los Node. Devuelve los Node limitados al propietario con las identidades canónicas node_id y kit_deployment_id.

​
techstack api servers maintenance get

Lee un trabajo de mantenimiento de un servidor propio. Con el mismo ámbito que el POST: el derecho techstack.servers.maintenance firmado por el Edge, el tenant, la propiedad del servidor y un trabajo que pertenece a este servidor y que solicitó quien llama. Cualquier otra cosa devuelve 404. Los trabajos de mantenimiento tienen su propio registro y no se sirven mediante /api/v1/jobs/&#123;id&#125;. No hay endpoint de logs: el trabajo lleva su resultado y un fallo lleva su código estable con indicaciones para el usuario.

​
techstack api servers maintenance run

Pone en cola un plan de actualización del sistema operativo, una actualización o un reinicio de un servidor propio. Requiere el entitlement techstack.servers.maintenance firmado por Edge, la propiedad del servidor en el tenant y autoridad permanente vigente vinculada al servidor para las llamadas MCP nativas delegadas. Estas tres acciones ordinarias no requieren MFA reciente ni una afirmación owner_approved separada. El cuerpo se decodifica de forma estricta: claves exactas en minúsculas, sin duplicados ni campos desconocidos. Una repetición con la misma Idempotency-Key devuelve el recibo almacenado antes de validar el destino. Puede estar activo un reinicio o actualización y, por separado, un plan de actualización por servidor; un job que no termina dentro de su plazo falla con deadline_exceeded y libera su slot. La acción solo se ofrece en allowed_actions cuando el agente anuncia stackkit.host-maintenance.v1, y reboot solo cuando el servidor también informa host_boot_id. Los rechazos son documentos client-error-envelope/v1; el reason_code 409 es 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 o idempotency_key_reused; 403 incluye entitlement_required o maintenance_origin_authority_denied.

​
techstack api servers network get

Consulta los datos de red del servidor y cualquier traslado de red doméstica registrado. La red que kombify Guard observó por última vez en el servidor (dirección, gateway, subred, interfaz, red WiFi), el registro network_move que kombify creó cuando el servidor apareció en otra red y el estado de la revinculación posterior. Un servidor trasladado se revincula automáticamente; can_rebind indica si el propietario puede iniciar una revinculación ahora.

​
techstack api servers network rebind

Revincula un servidor trasladado a la red en la que se encuentra ahora. Ejecuta stackkit network rebind en el servidor mediante kombify Guard: el nodo vuelve a detectar su dirección LAN, emite de nuevo el registro firmado de custodia DNS LAN y regenera y aplica el workspace. La solicitud no tiene cuerpo. Requiere al propietario, el permiso operate de Inventory, el entitlement techstack.servers.maintenance y un Guard conectado (en caso contrario, 409 server_network_not_ready). Si ya hay una revinculación en cola o en ejecución, devuelve su job en lugar de poner otra en cola.
Requiere confirmación. Esta operación vuelve a detectar la dirección del servidor en su red actual, emite de nuevo su registro DNS local firmado y vuelve a aplicar su workspace. Pasa --yes o responde a la pregunta; una ejecución no interactiva sin --yes se detiene antes de cualquier solicitud con el código de salida 9.

​
techstack api servers ports

Obtiene el inventario de puertos del propietario autenticado para un servidor canónico. Proyección de la UI de detalle del servidor sobre la misma autoridad central de puertos que la superficie de Inventory/MCP, autorizada a través del límite canónico de lectura de servidores limitado al propietario.

​
techstack api servers reach set

Publica el servidor en una dirección kombify.me o deja de publicarlo. Por defecto no se publica nada: un servidor emparejado no tiene ruta pública y el relay no transporta tráfico. El propietario lo activa por servidor con un nombre service y un target_port explícitos (el origen siempre es el loopback del host del Guard, nunca otra máquina) y puede retirarlo en cualquier momento. El relay autentica al Guard, no al visitante, por lo que el servicio de ese puerto debe protegerse por sí mismo. La activación requiere al propietario, el entitlement techstack.servers.maintenance y un inicio de sesión multifactor reciente (motivo server_reach_step_up_required); la retirada nunca queda bloqueada por este requisito. Responde con la sección reach del modelo de lectura del servidor; después el reconciliador crea o retira la ruta.
Requiere confirmación. Esta operación publica un servicio del servidor en una dirección kombify.me pública que cualquiera en Internet puede abrir. Pasa --yes o responde a la pregunta; una ejecución no interactiva sin --yes se detiene antes de cualquier solicitud con el código de salida 9.

​
techstack api servers security auto-repair get

Consulta la aprobación del propietario para la reparación automática de seguridad. Un servidor sin aprobación, o con una aprobación caducada, solo se observa.

​
techstack api servers security auto-repair set

Aprueba o retira la reparación automática de un pequeño conjunto seguro de controles. Desactivada por defecto. Una aprobación identifica controles del conjunto seguro (allowed_controls: protección contra fuerza bruta, política del firewall, parámetros del kernel y actualizaciones automáticas de seguridad; nunca los controles SSH), caduca en un máximo de 90 días y no se renueva sola. Mientras está vigente, el plano de control repara un control identificado cuya evidencia reciente indica deriva, dentro de los mismos límites que una reparación del operador. Requiere al propietario, el entitlement techstack.servers.maintenance y un inicio de sesión multifactor reciente. enabled: false retira la aprobación.
Requiere confirmación. Esta operación permite que kombify Guard repare los controles de seguridad del host identificados sin preguntar cada vez, hasta que caduque la aprobación. Pasa --yes o responde a la pregunta; una ejecución no interactiva sin --yes se detiene antes de cualquier solicitud con el código de salida 9.

​
techstack api servers security findings

Lista los hallazgos abiertos y el historial reciente de hallazgos de un servidor. El registro de hallazgos que sustenta security, recovery y las alertas del Guard del servidor. Cada hallazgo representa un episodio: se abre al observar por primera vez un hecho incorrecto y se resuelve cuando vuelve a observarse correcto, con como máximo una alerta (alerted_at) y una resolución. El historial se conserva durante 90 días.

​
techstack api servers security repairs list

Lista las reparaciones de seguridad recientes de un servidor.

​
techstack api servers security repairs request

Repara los controles de seguridad del host identificados que presentan deriva. Solicita una reparación limitada de los controles que la evidencia reciente de seguridad del host identifica como desviados y reparables automáticamente. Requiere al propietario del servidor, el entitlement techstack.servers.maintenance firmado por Edge y un inicio de sesión multifactor reciente (de como máximo 300 segundos). La reparación viaja como un comando tipado y registrado del Guard que ejecuta stackkit host security repair --apply exactamente para los controles identificados; StackKits rechaza, antes de cambiar nada, cualquier cambio que corte la vía de administración o deje al propietario sin acceso. Límites: una reparación por servidor a la vez (409 repair_in_progress), una espera por control (429 repair_cooldown), un presupuesto diario de intentos por control (429 repair_attempts_exhausted) y un cortacircuitos tras fallos consecutivos (429 repair_circuit_open); las respuestas 429 incluyen retry_after. Se rechaza un control conforme (409 control_not_drifted), con una excepción aprobada (control_has_exception), manual (control_not_repairable), bloqueado por falta de una clave SSH autorizada (needs_authorized_key) o no observado. El cuerpo se decodifica de forma estricta.
Requiere confirmación. Esta operación restaura en el servidor los controles de seguridad del host identificados (firewall, SSH, protección contra fuerza bruta y actualizaciones automáticas) mediante kombify Guard. Pasa --yes o responde a la pregunta; una ejecución no interactiva sin --yes se detiene antes de cualquier solicitud con el código de salida 9.

​
techstack api servers security verify

Pide a kombify Guard una observación reciente de la seguridad del host. Registra que se desea una observación reciente de la baseline del host. El Guard responde en su siguiente check-in (aproximadamente en un minuto) con un nuevo informe; no cambia nada en el host. El modelo de lectura security del servidor solo se actualiza mediante ese informe, nunca mediante esta solicitud. Un servidor de otro tenant o propietario devuelve 404; uno sin Guard devuelve 409 guard_not_connected.

​
techstack api servers summary

Lee el resumen de presencia de servidores del propietario autenticado. Devuelve solo un recuento y un indicador de presencia bajo el mismo ámbito de política de tenant y propietario que la lista canónica del inventario. La consulta opcional de tenant existe por compatibilidad con el Gateway y debe coincidir exactamente con el tenant de la identidad autenticada; una discrepancia se rechaza antes de cualquier lectura del almacén. No se devuelven identificadores de servidor, tenant ni sujeto.

​
techstack api servers transitions

Lista la línea temporal persistida del estado del servidor.