La estabilidad es un principio del producto, no una idea posterior. AiHummer sigue SemVer, se aplica migraciones de base de datos seguras hacia adelante automáticamente, y puede autoactualización desde un CDN, por lo que las actualizaciones son rutinarias en lugar de arriesgadas.
Control de versiones (SemVer)
Las versiones se publican siguiendo la Versionado Semántico. La versión se informa por /healthz y por aihummer version, para que siempre puedas confirmar exactamente qué se está ejecutando antes y después de una actualización.
Las migraciones son seguras hacia adelante y automáticas
Al iniciar, la puerta de enlace aplica automáticamente las migraciones de base de datos pendientes. Dos propiedades mantienen esto seguro:
Seguro hacia adelante. Las migraciones se escriben para que un binario más nuevo funcione contra el
esquema al que migra, lo que hace que la aplicación automática y las actualizaciones continuas sean seguras.
Aplicador único mediante bloqueo consultivo. Las migraciones se ejecutan bajo una PostgreSQL
cerradura de advertencia, así que cuando varios gateways comienzan a la vez, solo uno los aplica
y el resto espera — nunca una migración doble.
[!NOTE]
Las migraciones siempre se ejecutan en el grupo de bases de datos del propietario. El rol RLS restringido
(AIHUMMER_DB_APP_URL) es para servir tráfico, no para cambios en el esquema.
Actualización
Las versiones nuevas se descargan del CDN de lanzamientos del proveedor. La forma admitida de actualizar es una sola orden en el servidor:
aihummer update --check # report whether a newer version is availableaihummer update # download and apply the update
--check no escribe nada y por eso no necesita root. Aplicar la actualización reescribe la raíz de instalación y reinicia el servicio, así que ejecútala con sudo.
Resultado esperado:--check imprime la versión actual y la disponible y termina sin cambiar nada. aihummer update descarga el artefacto, verifica su suma de comprobación sha256 y su firma cosign, sustituye el binario y reinicia el servicio; después aihummer version muestra la versión nueva. Si la verificación no cuadra, la actualización se aborta antes de la sustitución: la versión en ejecución queda intacta.
[!NOTE]
La actualización automática la habilita el proveedor, no tú. El modo y la
periodicidad del autoactualizado forman parte del mantenimiento del lanzamiento y se
fijan mediante una directiva firmada del proveedor. No existen interruptores para ello
ni en la interfaz web ni en aihummer settings, y las variables de autoactualización
escritas en gateway.envno las lee la puerta de enlace: si las ves ahí, no
surten efecto. Para actualizar según tu propio calendario, usa la orden
aihummer update de arriba.
Reversión
Qué se revierte, punto por punto:
Binario — se puede volver a la versión anterior (los artefactos de lanzamientos
previos permanecen en el CDN; reinstala la versión que quieras).
Esquema de la base de datos — las migraciones son seguras hacia adelante, así que
el binario anterior funciona con el esquema más nuevo; no hay una reversión de esquema
aparte.
Plugins — las versiones se gestionan por instalación; si hace falta, devuelve un
plugin a su versión previa desde el catálogo.
Configuración — una actualización no la toca; restáurala desde una copia de
seguridad cuando sea necesario.
Despliegues sin tiempo de inactividad
AiHummer está diseñado para actualizarse sin interrupciones:
Ejecute 2+ puertas de enlace detrás de un proxy. Enróllalos uno a la vez; la sonda de preparación
(/readyz) mantiene un nodo que se está reiniciando fuera de rotación hasta que esté en funcionamiento.
El programador es de líder único. La programación en segundo plano elige un único líder
a través de un bloqueo consultivo de PostgreSQL, por lo que ejecutar múltiples gateways no duplica
trabajo programado.
La entrega es idempotente. La entrega confiable más las claves de idempotencia significan un
la respuesta nunca se envía dos veces a través de un reinicio, lo que es lo que hace que un rodamiento
reinicia de manera segura a través de tus puertas de enlace.
La estabilidad es un principio del producto, no una idea posterior. AiHummer sigue **SemVer**, se aplica **migraciones de base de datos seguras hacia adelante automáticamente**, y puede **autoactualización** desde un CDN, por lo que las actualizaciones son rutinarias en lugar de arriesgadas.
## Control de versiones (SemVer)
Las versiones se publican siguiendo la Versionado Semántico. La versión se informa por `/healthz` y por `aihummer version`, para que siempre puedas confirmar exactamente qué se está ejecutando antes y después de una actualización.
## Las migraciones son seguras hacia adelante y automáticas
Al iniciar, la puerta de enlace aplica automáticamente las migraciones de base de datos pendientes. Dos propiedades mantienen esto seguro:
- **Seguro hacia adelante.** Las migraciones se escriben para que un binario más nuevo funcione contra el
esquema al que migra, lo que hace que la aplicación automática y las actualizaciones continuas sean seguras.
- **Aplicador único mediante bloqueo consultivo.** Las migraciones se ejecutan bajo una **PostgreSQL
cerradura de advertencia**, así que cuando varios gateways comienzan a la vez, solo uno los aplica
y el resto espera — nunca una migración doble.
> [!NOTE]
> Las migraciones siempre se ejecutan en el grupo de bases de datos del propietario. El rol RLS restringido
> (`AIHUMMER_DB_APP_URL`) es para servir tráfico, no para cambios en el esquema.
## Actualización
Las versiones nuevas se descargan del CDN de lanzamientos del proveedor. La forma admitida de actualizar es una sola orden en el servidor:
```bash
aihummer update --check # report whether a newer version is available
aihummer update # download and apply the update
```
`--check` no escribe nada y por eso **no necesita root**. Aplicar la actualización reescribe la raíz de instalación y reinicia el servicio, así que ejecútala con `sudo`.
**Resultado esperado:** `--check` imprime la versión actual y la disponible y termina sin cambiar nada. `aihummer update` descarga el artefacto, verifica su suma de comprobación sha256 y su firma cosign, sustituye el binario y reinicia el servicio; después `aihummer version` muestra la versión nueva. Si la verificación no cuadra, la actualización se aborta **antes** de la sustitución: la versión en ejecución queda intacta.
> [!NOTE]
> **La actualización automática la habilita el proveedor, no tú.** El modo y la
> periodicidad del autoactualizado forman parte del mantenimiento del lanzamiento y se
> fijan mediante una directiva firmada del proveedor. No existen interruptores para ello
> ni en la interfaz web ni en `aihummer settings`, y las variables de autoactualización
> escritas en `gateway.env` **no las lee** la puerta de enlace: si las ves ahí, no
> surten efecto. Para actualizar según tu propio calendario, usa la orden
> `aihummer update` de arriba.
### Reversión
Qué se revierte, punto por punto:
- **Binario** — se puede volver a la versión anterior (los artefactos de lanzamientos
previos permanecen en el CDN; reinstala la versión que quieras).
- **Esquema de la base de datos** — las migraciones son seguras hacia adelante, así que
el binario anterior funciona con el esquema más nuevo; no hay una reversión de esquema
aparte.
- **Plugins** — las versiones se gestionan por instalación; si hace falta, devuelve un
plugin a su versión previa desde el catálogo.
- **Configuración** — una actualización no la toca; restáurala desde una copia de
seguridad cuando sea necesario.
## Despliegues sin tiempo de inactividad
AiHummer está diseñado para actualizarse sin interrupciones:
- **Ejecute 2+ puertas de enlace detrás de un proxy.** Enróllalos uno a la vez; la sonda de preparación
(`/readyz`) mantiene un nodo que se está reiniciando fuera de rotación hasta que esté en funcionamiento.
- **El programador es de líder único.** La programación en segundo plano elige un único líder
a través de un bloqueo consultivo de PostgreSQL, por lo que ejecutar múltiples gateways no duplica
trabajo programado.
- **La entrega es idempotente.** La entrega confiable más las claves de idempotencia significan un
la respuesta nunca se envía dos veces a través de un reinicio, lo que es lo que hace que un rodamiento
reinicia de manera segura a través de tus puertas de enlace.
## ¿A dónde vamos ahora?
- Sondas que controlan un reinicio en cascada:
[systemd y controles de salud](/es/v1.0/operations/systemd-health).
- Realice una copia de seguridad antes de una actualización importante:
[Copias de seguridad y recuperación ante desastres](/es/v1.0/operations/backups-dr).
- Mira el despliegue:
[Observabilidad](/es/v1.0/operations/observability).
