Cómo autoalojar Wallos en 2026: renovaciones, notificaciones y SQLite

La mayoría de las notas de instalación de Wallos terminan cuando se carga la primera página. Es demasiado pronto: las fechas de renovación cambian porque TZ está configurada incorrectamente o porque el directorio de SQLite es de solo lectura. Una prueba de producción útil es más exigente: crea suscripciones con distintos ciclos de facturación, establece fechas de renovación, ejecuta el flujo de notificaciones y revisa los totales en la moneda seleccionada.

El papel de Wallos es sencillo: gestionar suscripciones con fechas de renovación y notificaciones. Sus límites operativos abarcan más que el proceso web, por lo que la dependencia, el estado almacenado y la ruta pública deben especificarse explícitamente antes de que lleguen datos reales.

Mapea Wallos antes de tocar Docker

Separa cuatro aspectos de Wallos: entrada, el listener en el puerto 80, el estado persistente y los servicios auxiliares o la capacidad local. El requisito del runtime local son los directorios persistentes de la base de datos y de carga de logotipos, además de la entrega de notificaciones. Dimensiona y supervisa ese recurso junto con el contenedor en lugar de exponer un servicio de red no relacionado.

Ejecuta la transacción validada —crea suscripciones con distintos ciclos de facturación, establece fechas de renovación, ejecuta el flujo de notificaciones y revisa los totales en la moneda seleccionada— antes de dar por completada esa separación. Mide el trabajo de notificaciones programadas, el almacenamiento de logotipos, las escrituras de SQLite y la corrección de la zona horaria, y conserva el resultado junto con el registro del despliegue. Esto proporciona tanto un criterio de aceptación como la primera referencia de capacidad.

Diagnostica un Wallos que parece saludable

En Wallos, supervisa una transacción en lugar de un proceso: crea suscripciones con distintos ciclos de facturación, establece fechas de renovación, ejecuta el flujo de notificaciones y revisa los totales en la moneda seleccionada. Combina su latencia y tasa de errores con el trabajo de notificaciones programadas, el almacenamiento de logotipos, las escrituras de SQLite y la corrección de la zona horaria para que una alerta identifique el componente limitado.

El ensayo de actualización debe cubrir que las migraciones de la base de datos de Wallos se prueben con datos de fechas y monedas antes de sustituir la imagen en ejecución. Restaura, migra y ejecuta la transacción antes de sustituirla en producción. Si las fechas de renovación cambian porque TZ está configurada incorrectamente o porque el directorio de SQLite es de solo lectura, no borres los datos para que el arranque aparezca como correcto; compara en este orden la versión, las variables, los mounts y la conectividad con las dependencias.

Convierte la smoke test de Wallos en una comprobación de release

El registro del release de Wallos necesita datos concretos, no un «parece correcto». Guarda el digest de la imagen seleccionada, el checksum de la configuración, el hostname público y un resultado con marca de tiempo para: crear suscripciones con distintos ciclos de facturación, establecer fechas de renovación, ejecutar el flujo de notificaciones y revisar los totales en la moneda seleccionada. Usa datos de ejemplo que no sean de producción para que la comprobación pueda ejecutarse después de cada despliegue.

Demuestra por separado dos eventos del ciclo de vida. La sustitución de un contenedor debe conservar el funcionamiento normal; una recuperación limpia debe demostrar que las suscripciones, las categorías, los logotipos y la configuración de notificaciones vuelven con las mismas fechas de renovación. Mientras se ejecutan las comprobaciones, mide el trabajo de notificaciones programadas, el almacenamiento de logotipos, las escrituras de SQLite y la corrección de la zona horaria, y conserva el resultado como el margen esperado para esta versión.

Prueba también una condición denegada o no válida: envía una entrada inocua cerca del límite de recursos o de formato asociado a este límite: las fechas de renovación cambian porque TZ está configurada incorrectamente o porque el directorio de SQLite es de solo lectura. Wallos debe fallar de forma diagnosticable y no debe sobrescribir el estado correcto. Restablece la condición válida, vuelve a ejecutar el ejemplo y adjunta los logs relevantes con la información sensible ocultada. Estos artefactos aportan pruebas concretas para una futura decisión de rollback.

Haz reproducible el arranque de Wallos

Un lanzamiento con una configuración similar a producción es intencionadamente aburrido: estado con nombre, puerto explícito y ningún secreto dentro de la imagen.

docker run -d \
  --name wallos \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallos-data:/var/www/html/db \
  -e TZ=UTC \
  bellamy/wallos:latest

El ejemplo es una base, no un stack auxiliar completo. Confirma el requisito local antes de exponerlo: directorios persistentes de la base de datos y de carga de logotipos, además de la entrega de notificaciones. Comprueba los mounts efectivos y el listener, y después intenta crear suscripciones con distintos ciclos de facturación, establecer fechas de renovación, ejecutar el flujo de notificaciones y revisar los totales en la moneda seleccionada. Fija la imagen que funciona antes del siguiente reinicio.

Encuentra todos los bytes persistentes de Wallos

Haz un inventario de todos los artefactos persistentes: la base de datos de suscripciones, los logotipos cargados y la configuración de notificaciones. Monta /var/www/html/db antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Incluye también la configuración que cambia la forma en que se interpretan los datos almacenados, no solo el directorio más grande.

Define la retención, copia las copias de seguridad fuera del host y ejecuta una restauración en un entorno limpio. El ejercicio de Wallos termina cuando las suscripciones, las categorías, los logotipos y la configuración de notificaciones vuelven con las mismas fechas de renovación. Si las snapshots forman parte del plan, usa la guía sobre PITR frente a snapshots para documentar qué puede recuperar cada mecanismo.

Dale a Wallos una dirección canónica

La emisión de TLS es solo la mitad de la ruta de Wallos. Sirve la aplicación mediante HTTPS y configura su zona horaria. Envía el tráfico internamente al puerto 80 y reenvía el esquema externo para que las URL generadas y las cookies seguras sigan siendo coherentes.

Usa el escenario completo de Wallos desde una red limpia, no solo la página raíz. Un error 502 o del certificado se puede aislar con la configuración automática del dominio y TLS. Si el tráfico llega al proceso y las fechas de renovación cambian porque TZ está configurada incorrectamente o porque el directorio de SQLite es de solo lectura, diagnostica esa condición en el punto donde se produce en lugar de encadenar redirecciones.

Protege la parte valiosa de Wallos

Después del primer inicio de sesión, revisa qué puede hacer un visitante anónimo, un usuario normal y un administrador. El fallo de Wallos que debes evitar es dejar desprotegida la primera cuenta en una instancia expuesta a Internet. La política prevista es proteger la cuenta, mantener privados los tokens de notificación y establecer TZ explícitamente para que las renovaciones no cambien.

TZ controla el comportamiento, no la confidencialidad; valida su tipo y valor, y almacena las credenciales reales de Wallos por separado. Mantén separadas las cuentas de las dependencias y las cuentas humanas, deniega el tráfico de salida que no se use siempre que sea posible y limita el trabajo condicionado por las notificaciones programadas, el almacenamiento de logotipos, las escrituras de SQLite y la corrección de la zona horaria.

Cómo Dockup reduce el trabajo con Wallos

Una plantilla de Dockup debería definir la imagen, el puerto 80, los mounts, los tiempos de health check, el dominio, TLS y la entrega de secretos. Dockup debe conservar la configuración del runtime de Wallos mientras el operador confirma este requisito local: directorios persistentes de la base de datos y de carga de logotipos, además de la entrega de notificaciones. El mismo despliegue puede dirigirse a servidores de Dockup o a capacidad asociada por el cliente.

Cuando la ruta esté activa, aplica la configuración pública e intenta crear suscripciones con distintos ciclos de facturación, establecer fechas de renovación, ejecutar el flujo de notificaciones y revisar los totales en la moneda seleccionada. Haz copias de seguridad de la base de datos de suscripciones, los logotipos cargados y la configuración de notificaciones, y mantén el ejercicio de restauración en el plan operativo; esas son responsabilidades de Wallos que siguen siendo visibles después del aprovisionamiento de la infraestructura.

Preguntas frecuentes

¿Qué necesita Wallos para un despliegue de producción?

Dirige el contenedor de Wallos en el puerto 80 a través de un único origen HTTPS. El requisito del runtime local son los directorios persistentes de la base de datos y de carga de logotipos, además de la entrega de notificaciones. No consideres Wallos listo hasta que puedas crear suscripciones con distintos ciclos de facturación, establecer fechas de renovación, ejecutar el flujo de notificaciones y revisar los totales en la moneda seleccionada.

¿Qué datos de Wallos deben incluirse en una copia de seguridad?

Haz persistir /var/www/html/db e incluye la base de datos de suscripciones, los logotipos cargados y la configuración de notificaciones en el mismo manifiesto de recuperación. Una restauración limpia de Wallos solo es válida cuando las suscripciones, las categorías, los logotipos y la configuración de notificaciones vuelven con las mismas fechas de renovación.

¿Wallos necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Wallos y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de Wallos: sirve la aplicación mediante HTTPS y establece su zona horaria. En Wallos, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar una actualización de Wallos?

Restaura el estado actual de Wallos en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de la base de datos de Wallos deben probarse con datos de fechas y monedas antes de sustituir la imagen en ejecución. Conserva la imagen anterior de Wallos hasta comprender los límites de migración de datos y rollback.