Operación

Actualizar y versiones

Cómo se versiona Styx (tren global y versión por componente), los canales nightly y stable, y cómo se actualiza y se revierte.

EspecificadoNo implementado
track/docstrack/release-engineeringdec-0123dec-0124dec-0133track/docs:DC9track/release-engineering:RE1track/release-engineering:RE2track/release-engineering:RE5track/release-engineering:RE7track/release-engineering:RE8

Especificado (dec-0123, LOCKED). Hoy no hay tags de tren ni canal publicado. Las versiones de componente existen en el repositorio (package.json, build.zig.zon, deploy/VERSION) y las calcula bun run release:plan; cada binario de bun run release:build lleva la suya dentro (GET /version de los servicios, --version del daemon y de styx-upload), y fuera de un build de release los servicios dicen dev. Mientras no haya un release publicado, el campo since de las páginas es null. Cómo se corta una release está en docs/governance/release-engineering.md.

dec-0123 LOCKED (waxin, 2026-10-03) con su enmienda del 2026-10-02. Coolify es tier 1 con plantilla propia, junto a systemd nativo, Podman Quadlet y Docker Compose. El tren es 0.0.0 en estado alfa hasta que se corte el primer v0.y.z: los alfas son 0.0.0-alpha.N (dec-0133), las nightly son builds de desarrollo marcadas clean o dirty, sólo hay canales nightly y stable, y beta es un checkpoint opcional. El orden de trabajo lo dan los releases, que empiezan por la aplicación de Coolify del sitio de docs.

Tres ejes de versión

EjeEsquemaPara qué
Tren (global)SemVer 0.y.z, tag git v0.y.zLo que ves tú: "estoy en el tren 0.4.2"
ComponenteSemVer propio, por servicio, daemon, web, CLI…Lo que mira el operador en styx status
Cableenteros propios (frame de session-ipc, versión de cada contrato del bus, capacidades, conduit)Compatibilidad entre componentes: la comprueba el CLI

El tren no se calcula sumando componentes: v0.4.0 significa "este conjunto de versiones, probado junto". Un PATCH de tren siempre se puede aplicar sin pensar. Un MINOR puede traer migración o pasos de actualización y se anuncia.

Canales

  • nightly: automático desde la rama principal. Su versión lleva fecha y sha.
  • stable: un tag del tren tras pasar los gates de release.

El instalador nunca usa tags móviles: resuelve canal, manifiesto firmado y digests.

Actualizar

styx update --dry-run     # muestra el plan sin hacer nada
styx update

styx update es una transacción: verifica el manifiesto, calcula la ruta (con escalones si la versión de partida es muy antigua), muestra las notas "antes de actualizar", descarga todo antes de parar nada, hace una copia de seguridad automática, corre streams y migraciones, intercambia la versión activa, comprueba la salud (healthchecks, /version igual al manifiesto, conexión con el daemon, styx verify) y, si algo falla, revierte solo. Es reanudable tras un corte.

La actualización automática es opt-in (notify por defecto, patch o minor) y nunca salta versiones mínimas, nunca cambia de canal y nunca actualiza con reproducción activa.

Revertir y copias

  • styx rollback: rápido (cambio de enlace) si el tren sólo tuvo migraciones aditivas; con restauración de la copia previa si no, avisando de lo que se pierde.
  • styx backup create|list|restore|prune: pg_dump por base con el rol migrador, configuración, manifiesto y secretos cifrados con age a una clave de recuperación que se muestra una vez al instalar. Valkey no entra: es estado efímero.

Las migraciones son expand/contract: el código N-1 corre sobre el esquema N, lo que hace barato el rollback.