Cómo autoalojar FreshRSS en 2026: actualización de feeds, API móvil y copias de seguridad

Un despliegue de FreshRSS con errores no siempre se cae. Puede mostrar una página de inicio de sesión mientras los feeds nunca se actualizan porque cron está desactivado o falla el DNS saliente. Empieza con una comprobación de extremo a extremo: añade feeds, ejecuta una actualización programada, marca un elemento como leído y sincroniza ese estado mediante la API móvil.

Esta comprobación coincide con el propósito catalogado de FreshRSS: un lector de RSS autoalojado con una API móvil compatible. También revela antes que una sonda de disponibilidad las dependencias que faltan, las suposiciones incorrectas sobre el proxy y los datos efímeros.

Analiza FreshRSS antes de tocar Docker

Separa cuatro aspectos de FreshRSS: la entrada, el listener en el puerto 80, el estado persistente y los servicios auxiliares o la capacidad local. El requisito externo de FreshRSS es la actualización programada de feeds y el acceso saliente a los hosts de los feeds. Prueba el DNS saliente, TLS y el comportamiento del proveedor sin publicar otro servicio entrante.

Ejecuta la transacción conocida —añadir feeds, ejecutar una actualización programada, marcar un elemento como leído y sincronizar ese estado mediante la API móvil— antes de dar por terminada esa separación. Mide el número de feeds, el intervalo de actualización, los publicadores lentos, las escrituras en la base de datos y los clientes de API simultáneos, y conserva el resultado junto con el registro del despliegue. Esto proporciona tanto un criterio de aceptación como la primera línea base de capacidad.

Haz copias del estado que FreshRSS no puede recrear

Crea un manifiesto de recuperación para FreshRSS: datos, extensiones y la base de datos seleccionada. Monta /var/www/FreshRSS/data antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Comprueba ahora la propiedad y el espacio libre, porque una ruta montada pero sin permisos de escritura se comporta como si no hubiera persistencia.

Haz copias de seguridad en un dominio de fallo separado del servidor en ejecución. Recrea FreshRSS a partir de su imagen fijada y verifica que vuelven las suscripciones, categorías, estado de lectura, filtros y extensiones, y que la actualización programada recupera un elemento nuevo. La guía de volúmenes persistentes ayuda a convertir este ejercicio en una política de snapshots y retención.

Elige el límite de confianza de FreshRSS

Haz un threat model de las acciones que realiza FreshRSS, no solo de su formulario de inicio de sesión. En este caso, el error de mayor riesgo es dejar la configuración inicial o el usuario predeterminado accesibles desde un host público. Implementa este límite: completa la configuración de forma privada, protege las contraseñas de la API y configura los proxies de confianza antes de habilitar la sincronización móvil.

CRON_MIN controla el comportamiento, no la confidencialidad; valida su tipo y valor, y almacena las credenciales reales de FreshRSS por separado. No soluciones un error de permisos ejecutando el contenedor como root o montando ampliamente el host. Los límites de recursos también forman parte del diseño de seguridad cuando los usuarios pueden provocar cambios en el número de feeds, el intervalo de actualización, los publicadores lentos, las escrituras en la base de datos y los clientes de API simultáneos.

Qué debe superar FreshRSS antes de recibir datos reales

Convierte la smoke test de FreshRSS en un comando de release repetible o en un runbook breve. Su salida debe demostrar este resultado: añadir feeds, ejecutar una actualización programada, marcar un elemento como leído y sincronizar ese estado mediante la API móvil. Registra la versión de la aplicación, el digest del contenedor, el hostname de la ruta y el identificador de los datos de prueba junto con el resultado.

Ejecuta la misma comprobación después de sustituir el contenedor como parte del mantenimiento habitual y después de restaurar los datos, las extensiones y la base de datos seleccionada en otro lugar. La restauración ha sido correcta cuando vuelven las suscripciones, categorías, estado de lectura, filtros y extensiones, y la actualización programada recupera un elemento nuevo. Compara los tiempos y el consumo relacionados con el número de feeds, el intervalo de actualización, los publicadores lentos, las escrituras en la base de datos y los clientes de API simultáneos; un cambio importante merece investigarse aunque la acción final siga superándose.

Después, prueba un fallo seguro: deniega temporalmente la ruta de prueba utilizada por la actualización programada de feeds y el acceso saliente a los hosts de los feeds. Confirma que FreshRSS muestra el fallo y vuelve a la normalidad sin ediciones manuales destructivas. Conserva únicamente el fragmento de log necesario y con la información sensible redactada. Este control en cuatro partes cubre el arranque, la persistencia, la recuperación y la gestión de fallos.

Una base de Docker para FreshRSS

Un lanzamiento con forma de producción es deliberadamente aburrido: estado con nombre, puerto explícito y ningún secreto dentro de la imagen.

docker run -d \
  --name freshrss \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v freshrss-data:/var/www/FreshRSS/data \
  -e CRON_MIN=15 \
  freshrss/freshrss:latest

El ejemplo es una base, no un stack auxiliar completo. Permite y verifica la ruta saliente o del lado del cliente necesaria para la actualización programada de feeds y el acceso saliente a los hosts de los feeds. Comprueba los montajes efectivos y el listener, y después intenta añadir feeds, ejecutar una actualización programada, marcar un elemento como leído y sincronizar ese estado mediante la API móvil. Fija la imagen que funciona antes del siguiente reinicio.

Evita que el éxito del proxy oculte un fallo de la aplicación

El navegador, el cliente de API y FreshRSS deben coincidir en un único origen. Para conseguirlo, declara los proxies de confianza y la base HTTPS canónica. Conserva el host y el protocolo originales, y mantén el puerto 80 fuera de disponibilidad como dirección pública alternativa.

La guía para solucionar problemas cuando el sitio está caído ayuda a distinguir una ruta inaccesible de una aplicación que responde. Esa distinción es importante aquí: los feeds nunca se actualizan porque cron está desactivado o falla el DNS saliente. Solo el primer caso se corrige con cambios en la entrada; el segundo requiere inspeccionar los logs, el estado o la carga de trabajo de FreshRSS.

Supervisa la carga de trabajo, no solo el contenedor

Observa el trabajo que realiza FreshRSS: número de feeds, intervalo de actualización, publicadores lentos, escrituras en la base de datos y clientes de API simultáneos. Establece límites con margen para ese trabajo y evita una sonda de liveness que compita con él. La comprobación operativa aún debe intentar añadir feeds, ejecutar una actualización programada, marcar un elemento como leído y sincronizar ese estado mediante la API móvil según un calendario.

Para las actualizaciones, recuerda que las extensiones, las migraciones de la base de datos y los cambios en el parser de feeds pueden afectar a las actualizaciones aunque el inicio de sesión siga funcionando. Despliega el candidato sobre una copia recuperada y repite la prueba conocida. Si los feeds nunca se actualizan porque cron está desactivado o falla el DNS saliente, utiliza los logs de runtime y la solicitud de red real para descubrir qué suposición ha cambiado.

Traslada el trabajo de infraestructura repetible a Dockup

El despliegue de FreshRSS con un clic de Dockup debería hacer que la sustitución sea segura: la ruta debe seguir apuntando al puerto 80, los secretos no deben estar integrados en la imagen y las rutas persistentes deben volver a estar disponibles en el nuevo contenedor. El mismo despliegue puede ejecutarse en la capacidad de cómputo de Dockup o en una máquina conectada.

Completa el trabajo específico de la aplicación permitiendo y verificando la actualización programada de feeds y el acceso saliente a los hosts de los feeds, aplicando la dirección pública canónica y ejecutando esta comprobación de aceptación: añadir feeds, ejecutar una actualización programada, marcar un elemento como leído y sincronizar ese estado mediante la API móvil. Añade el resultado de la restauración al runbook antes de que lleguen los usuarios reales.

Preguntas frecuentes

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

Enruta el contenedor de FreshRSS en el puerto 80 mediante un único origen HTTPS. El requisito externo de entrega es la actualización programada de feeds y el acceso saliente a los hosts de los feeds. No des por listo FreshRSS hasta que puedas añadir feeds, ejecutar una actualización programada, marcar un elemento como leído y sincronizar ese estado mediante la API móvil.

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

Haz persistir /var/www/FreshRSS/data e incluye los datos, las extensiones y la base de datos seleccionada en el mismo manifiesto de recuperación. Una restauración limpia de FreshRSS solo es correcta cuando vuelven las suscripciones, categorías, estado de lectura, filtros y extensiones, y la actualización programada recupera un elemento nuevo.

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

Usa HTTPS para el origen público de FreshRSS y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de FreshRSS: declara los proxies de confianza y la base HTTPS canónica. En FreshRSS, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente dependiente del origen.

¿Cómo debe probarse una actualización de FreshRSS?

Restaura el estado actual de FreshRSS en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las extensiones, las migraciones de la base de datos y los cambios en el parser de feeds pueden afectar a las actualizaciones aunque el inicio de sesión siga funcionando. Conserva la imagen anterior de FreshRSS hasta comprender sus límites de migración de datos y rollback.