Operación

Instalar

Instalar Styx con un comando sobre el runtime que tengas, y cómo se instala hoy desde el repositorio.

EspecificadoNo implementado
track/docstrack/byte-runtimetrack/identitytrack/release-engineeringtrack/release-engineering/coolify-docstrack/release-engineering/coolify-tier1dec-0123dec-0117dec-0118dec-0120dec-0124track/docs:DC9track/release-engineering:RE3track/release-engineering:RE4track/release-engineering:RE6track/release-engineering:RE9track/release-engineering:RE10track/release-engineering:RE11track/release-engineering:RE12track/release-engineering:RE13track/release-engineering:RE15

Especificado. El camino de un comando es dec-0123 (LOCKED). install.sh y el CLI styx ya están en la rama de integración, pero sin verificar: el gate de track/release-engineering está entero open y aún no hay canal publicado. La sección Hoy, desde el repositorio es lo que funciona ahora. Esta página absorbe la documentación de instalación y operación de ese nodo (gate RE9).

Requisitos objetivo

Un Linux amd64 o arm64 con uno de estos runtimes. Nada más: ni clon del repositorio, ni Bun, ni Zig.

RuntimeNivel (probado en cada release)
systemd nativo (sin contenedores)Tier 1
Podman con QuadletTier 1
Docker Engine con Compose v2Tier 1
Coolify, con plantilla propia de StyxTier 1 (enmienda de dec-0123 del 2026-10-02)
Incus, Kubernetes (Helm)Tier 2
NixOS, TrueNAS, Unraid, SynologyTier 3: ficheros renderizados y validados, no probados en vivo
macOS, WindowsDiferido

El orden por defecto cuando hay varios lo fijará la evidencia de la campaña de medida de dec-0123; hasta entonces es provisional (systemd nativo, Quadlet, Compose). Cada servicio sigue siendo un proceso o contenedor independiente en cualquier runtime.

Postgres va por runtime: en systemd nativo, styx-postgres compilado por Styx; en los runtimes de contenedores, la imagen oficial fijada por digest. PGlite sólo se usa en tests, CI y demo.

El camino de un comando (objetivo)

curl -fsSL https://<base>/install.sh | sh                      # canal stable, runtime detectado
curl -fsSL https://<base>/install.sh | sh -s -- --channel nightly
curl -fsSL https://<base>/install.sh | sh -s -- --runtime podman

El script descarga styx, SHA256SUMS y su firma, verifica la suma (y la firma si hay cosign) y aborta si no son válidas: no hay --insecure. Hay una vía equivalente en tres comandos, sin pipe a shell. Luego styx install hace, de forma idempotente:

  1. comprobaciones previas (runtimes, cgroups v2, puertos 80/443, UDP 4433-4435 y TCP 4435, disco, reloj, arquitectura, GPU);
  2. elige el runtime y pregunta lo mínimo: dominio, correo ACME, carpetas de medios en sólo lectura, proveedor OIDC y canal;
  3. crea el layout (/opt/styx/releases/<tren>/ con el enlace current, /etc/styx/styx.toml, /etc/styx/secrets/, /var/lib/styx/), genera los secretos y los entrega a cada servicio como fichero;
  4. arranca en orden (infraestructura, streams del bus, migraciones, servicios, proxy);
  5. instala el cortafuegos como una unidad del sistema, no como un paso manual tras cada arranque;
  6. cierra con styx verify. Si falla, la instalación no se da por buena.

Para aplicarlo con tus propias herramientas, styx render --runtime <r> genera los ficheros sin instalar nada. Los ficheros de cada runtime se generan del manifiesto firmado styx-release.json y fijan las imágenes por digest, nunca :latest.

Hoy, desde el repositorio

Lo que existe en la rama de integración. Necesitas el repositorio, Bun, Zig 0.17.0 y Docker con Compose v2 (los prepara la puesta en marcha de un nodo). Los comandos, en el orden de deploy/README.md, que es la fuente de este camino:

sudo bun run deploy:secrets          # una vez: secretos en deploy/secrets/ (fuera de git)
bun run build:media-daemon           # binario estático ReleaseSafe del daemon
docker compose -f deploy/docker-compose.infra.yml -f deploy/docker-compose.infra.dev.yml up -d
NATS_URL=nats://localhost:4223 bun run bus:streams    # streams del bus, con la identidad de despliegue
sudo sh deploy/host-firewall.sh apply                 # cortafuegos del host, tras cada arranque
bun run check:deploy                 # guard estático del hardening
bun run check:infra-live             # la infraestructura que corre es la de estos compose

Limitaciones del camino actual (dec-0123 las resuelve):

  • Los pasos de secretos, daemon, streams y cortafuegos se repiten a mano tras arrancar.
  • No hay registro de imágenes: los compose de aplicaciones construyen desde el repositorio.
  • La web no tiene servicio en los compose de deploy/: su imagen sólo existe como imagen derivada del binario de release:build --oci.
  • bun run build:media-daemon sólo compila el daemon para amd64 (x86_64-linux-musl); bun run release:build -- --arch amd64,arm64 compila las dos arquitecturas.
  • En Coolify hay que usar Raw Compose Deployment: su modo por defecto reescribe las redes y anula el aislamiento de deploy/ (detalle en deploy/README.md).

La seguridad por diseño del despliegue (redes internas, contenedores sin privilegios, secretos de fichero, una base y dos roles por servicio, ACL del bus) la describe deploy/README.md y la comprueban check:deploy y check:infra-live.