Monitorizar el stack
Estas comprobaciones del ciclo de vida son la forma compatible de evaluar el propio stack. StackKits guarda localmente la evidencia de observación y verificación y no necesita ningún servicio de monitorización alojado. El módulo publicado de Uptime Kuma no lo selecciona la StackSpec v2 nativa inicial, así que un Basement o Cloud Kit nuevo no tiene una dirección de monitorización generada. Si ejecutas un monitor aparte, añade comprobaciones solo para las rutas que estés autorizado a monitorizar. Las rutas protegidas necesitan un endpoint de salud intencionado o una respuesta de autenticación esperada; debilitar la protección de una ruta para obtener HTTP 200 no es una configuración de monitor válida.Antes de un cambio
- Actualiza la StackSpec, no los artefactos generados.
- Ejecuta
stackkit validateystackkit generate. - Inspecciona
stackkit plan --jsony detente ante cualquier bloqueo de disposición. - Revisa la salida y obtén la aprobación del propietario local antes de un comando que modifique algo.
- Ejecuta
stackkit verify --http --jsondespués del cambio.
Añadir un workload a un workspace existente
Seleccionar un workload nuevo no requiere volver a ejecutarstackkit init ni reemplazar la StackSpec inicial. Edita el bloque workloads de la StackSpec existente y establece después la custodia de secretos antes de regenerar:
stackkit secrets materialize como paso explícito entre seleccionar un workload y ejecutar generate. Establece la custodia y después genera y aplica; no inventes valores de secretos.
Eliminar un workload aplicado
stackkit remove elimina un workload aplicado exacto con la aprobación del propietario local:
absent para el requisito, la instancia y el digest exactos del artefacto aplicado. La solicitud, el resultado y la evidencia terminal acotada se persisten bajo .stackkit/evidence/removal/.
Apunta a una ubicación concreta en un resultado multinodo
El resumen de apply verificado exponeplanHash, appliedRequestDigest y una lista appliedWorkloads sin secretos. Cada entrada es una identidad determinista y ligada por hash que vincula el workload, el propietario del runtime, las ubicaciones, el canal de ejecución y los digests de los artefactos referenciados. Úsala para identificar a qué debe apuntar una eliminación posterior; por sí sola no es una autorización de eliminación ni evidencia de ausencia.
Desde v0.21.12, cuando el resultado de apply colocó un workload en más de un Site o nodo, indica la ubicación exacta de la que se encarga esta eliminación. Toma los valores de la entrada de appliedWorkloads:
appliedRequestDigest compartido.
Añade --terminal-evidence-json cuando necesites un registro de eliminación legible por máquinas en stdout.
Flujos de trabajo habituales
Cambiar la intención de la StackSpec
Edita la intención publicada y regenera la salida gobernada.
Copia de seguridad y restauración
Crea un snapshot idempotente y practica la recuperación por etapas.
stackkit --help y la ayuda específica de cada comando para la versión instalada antes de realizar una copia de seguridad, una restauración, una actualización o una eliminación.
Para un flujo conectado a un agente, consulta el conector MCP.