Cómo autoalojar Wallabag en 2026: importaciones, base de datos y tareas en segundo plano

La demostración más sencilla de Wallabag solo prueba que un proceso escucha en el puerto 80. En producción se necesitan pruebas más sólidas. El sistema debe superar este escenario incluso después de sustituir el contenedor: guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado.

Wallabag se despliega con un objetivo claro: crear un archivo de tipo read-it-later que elimine el ruido de las páginas. El error de despliegue más habitual es que los assets o las redirecciones de inicio de sesión usen HTTP porque la variable de dominio es incorrecta, por lo que el tratamiento de la URL pública y el estado persistente requieren la misma atención que el arranque de la imagen.

Convierte el comando local en un servicio inspeccionable

El siguiente comando hace visible el límite del contenedor sin fingir que aprovisiona todos los servicios externos.

docker run -d \
  --name wallabag \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallabag-data:/var/www/wallabag/data \
  -e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
  wallabag/wallabag:latest

Antes de abrir el ingress, inspecciona el entorno resuelto, los mounts y el listener. Añade la configuración de conexión revisada para Postgres o MariaDB, Redis y los workers de importación programados; usa nombres privados para los servicios privados. Un arranque correcto termina cuando puedes guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado, no cuando docker ps muestra Up.

De qué depende Wallabag

Dibuja tres límites alrededor de Wallabag: ingress al puerto 80, estado persistente y requisitos auxiliares. El contenedor se puede reemplazar, pero los otros dos elementos necesitan responsables explícitos. El contrato de red de Wallabag incluye Postgres o MariaDB, Redis y workers de importación programados. Mantén los endpoints privados en el DNS interno, permite solo las llamadas salientes necesarias y proporciona a Wallabag una credencial de servicio con permisos limitados.

El diagrama está completo cuando un cliente limpio puede guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado. Recopila datos de tiempos y recursos para la descarga de páginas, el trabajo del parser, las descargas de imágenes, las colas y el crecimiento de la base de datos. Si la transacción falla, el primer límite que no se comporta como está documentado indica si debes investigar el routing, la capacidad local o un servicio auxiliar.

Refuerza la seguridad de Wallabag después del bootstrap

No heredes las suposiciones de seguridad de un tutorial local. El riesgo específico de Wallabag es mantener las credenciales predeterminadas o no configurar el proxy de confianza. Por tanto, en producción debes eliminar las credenciales predeterminadas, proteger los tokens de importación y configurar los proxies de confianza antes de exponer el lector.

SYMFONY__ENV__DOMAIN_NAME es configuración, no un secreto; mantén su valor explícito y protege las credenciales independientes que usa Wallabag. Limita el acceso al sistema de archivos y a la red, protege los endpoints de configuración y define límites de upload, requests o ejecución alrededor de la descarga de páginas, el trabajo del parser, las descargas de imágenes, las colas y el crecimiento de la base de datos.

Haz inequívoco el origen público

Expón un único hostname HTTPS para Wallabag y mantén el puerto 80 sin acceso público. Configura el nombre de dominio con la URL HTTPS final. Así evitarás que los navegadores y los clientes de API descubran dos direcciones que compiten entre sí.

Desde un cliente limpio, ejecuta la transacción conocida como correcta e inspecciona la primera request que falle. Usa la guía de dominios personalizados cuando el DNS o TLS no sean correctos. Trata “los assets o las redirecciones de inicio de sesión usan HTTP porque la variable de dominio es incorrecta” como un diagnóstico independiente de la aplicación una vez que la ruta esté validada.

Separa los contenedores reemplazables de los datos persistentes

El conjunto de recuperación persistente incluye la base de datos, las imágenes, el contenido importado y la configuración. Monta /var/www/wallabag/data antes del bootstrap, escribe datos de ejemplo sin riesgo y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Un volume protege los datos frente a la sustitución del contenedor, pero no frente a la pérdida del host, el borrado accidental o la corrupción a nivel de aplicación.

Realiza copias de seguridad que entiendan el origen de los datos: usa logical dumps para bases de datos activas cuando sea necesario y copia los archivos solo desde un estado consistente. Conserva una copia cifrada fuera del host de Wallabag. El criterio de aceptación de una restauración es específico: deben volver los artículos, las etiquetas, las anotaciones, los usuarios y los tokens de API, y el cliente móvil debe sincronizarse. La guía sobre copias de seguridad restauradas explica por qué el éxito de un job, por sí solo, no es suficiente.

Recopila evidencias antes de poner Wallabag en producción

Para Wallabag, define una transacción conocida como correcta antes del lanzamiento: guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado. Guarda sus requisitos previos, la respuesta esperada y los pasos de limpieza en el control de versiones, sin valores secretos. Fija la imagen utilizada para establecer esa referencia.

Usa la transacción para validar una sustitución y una restauración independiente. El servicio restaurado solo es aceptable cuando vuelven los artículos, las etiquetas, las anotaciones, los usuarios y los tokens de API, y el cliente móvil se sincroniza. Al mismo tiempo, observa la descarga de páginas, el trabajo del parser, las descargas de imágenes, las colas y el crecimiento de la base de datos, y convierte la parte más lenta o limitada en una alerta de nivel de servicio.

El gate también necesita un caso negativo: deniega temporalmente a la identidad de prueba el acceso a Postgres o MariaDB, Redis y los workers de importación programados. Confirma que Wallabag genera un error accionable mientras conserva los datos, restaura la condición válida y repite la transacción conocida como correcta. Conservar ambos resultados evita que un endpoint de health superficial se convierta en la única evidencia de producción.

Opera Wallabag en torno a su cuello de botella real

Crea dashboards centrados en la descarga de páginas, el trabajo del parser, las descargas de imágenes, las colas y el crecimiento de la base de datos. Un gráfico de CPU sin el contexto de esa carga no puede explicar por qué Wallabag funciona lentamente. Añade una comprobación sintética o programada que intente guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado usando datos de prueba sin riesgo.

Antes de actualizar, ten en cuenta este riesgo específico de la aplicación: las migraciones de Wallabag, el comportamiento del parser y la configuración de los workers deben probarse con páginas guardadas representativas. Restaura una copia de seguridad reciente en un despliegue aislado, ejecuta allí las migraciones y compara el comportamiento. Si los assets o las redirecciones de inicio de sesión usan HTTP porque la variable de dominio es incorrecta, inspecciona el límite implicado —origen público, almacenamiento o dependencia— antes de modificar ajustes no relacionados.

Usa Dockup para la capa de plataforma

Para Wallabag, Dockup puede crear la ruta y el certificado TLS, conservar los mounts, entregar secretos y colocar Postgres o MariaDB, Redis y los workers de importación programados en una red privada, tanto al desplegar en Dockup como en servidores conectados.

El gate de release sigue siendo la transacción concreta de Wallabag: guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado. Verifica también la condición de restauración: deben volver los artículos, las etiquetas, las anotaciones, los usuarios y los tokens de API, y el cliente móvil debe sincronizarse. Estas dos comprobaciones muestran si el despliegue funciona y si puede recuperarse.

Preguntas frecuentes

¿Qué necesita Wallabag para un despliegue en producción?

Enruta el contenedor de Wallabag en el puerto 80 a través de un único origen HTTPS. El requisito de red auxiliar incluye Postgres o MariaDB, Redis y workers de importación programados. No consideres Wallabag listo hasta que puedas guardar un artículo normal y una página difícil, ejecutar la recuperación en segundo plano, sincronizar un cliente móvil y buscar contenido archivado.

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

Haz persistir /var/www/wallabag/data e incluye la base de datos, las imágenes, el contenido importado y la configuración en el mismo manifiesto de recuperación. Una restauración limpia de Wallabag solo es válida cuando vuelven los artículos, las etiquetas, las anotaciones, los usuarios y los tokens de API, y el cliente móvil se sincroniza.

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

Usa HTTPS para el origen público de Wallabag y mantén el puerto 80 en la ruta interna. Aplica correctamente el ajuste de Wallabag: configura el nombre de dominio con la URL HTTPS final. En Wallabag, 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 debe probarse una actualización de Wallabag?

Restaura el estado actual de Wallabag 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 Wallabag, el comportamiento del parser y la configuración de los workers deben probarse con páginas guardadas representativas. Conserva la imagen anterior de Wallabag hasta comprender los límites de migración de datos y rollback.