Índice del diarioDockup / nota de campo
Note / self-host-shiori

Cómo autoalojar Shiori en 2026: archivos, cuentas y almacenamiento persistente

Guía práctica para autoalojar Shiori con Docker, puertos, datos persistentes, TLS, seguridad, copias de seguridad y los fallos que impiden usarlo en producción. Paso a paso.

Un despliegue de Shiori con errores no siempre se cae. Puede mostrar la página de inicio de sesión mientras falla el archivado porque faltan dependencias de Chromium o los permisos del sistema de archivos son incorrectos. En su lugar, empieza con una comprobación de extremo a extremo: guarda un marcador con contenido archivado, búscalo, edita sus etiquetas y verifica que el archivo siga disponible después de que cambie la página de origen.

Esta comprobación coincide con la finalidad catalogada de Shiori: un gestor de marcadores que archiva el contenido de las páginas. También permite detectar antes la falta de dependencias, las suposiciones incorrectas sobre el proxy y los datos efímeros, algo que un sondeo de disponibilidad no puede hacer.

Delimita el entorno de ejecución de Shiori

La salud del proceso y la salud del producto son aspectos distintos en Shiori. El puerto 8080 puede responder mientras la transacción que ve el usuario sigue fallando. El requisito externo de Shiori es disponer de un volumen de datos con permisos de escritura y acceso saliente a las páginas que se van a archivar. Prueba el DNS saliente, TLS y el comportamiento del proveedor sin publicar otro servicio de entrada.

Usa este ejercicio de preparación después de cambios de configuración relevantes: guarda un marcador con contenido archivado, búscalo, edita sus etiquetas y verifica que el archivo siga disponible después de que cambie la página de origen. Mantén las comprobaciones externas costosas fuera de los sondeos de liveness para que una interrupción del proveedor no provoque un bucle de reinicios. El trabajo de capacidad debería tener en cuenta la captura de páginas mediante el navegador, el tamaño de los archivos, las miniaturas y las solicitudes salientes, ya que esto se acerca más a la presión real de Shiori que las solicitudes de páginas.

Restaura Shiori en un host vacío

Enumera el estado antes de crear el primer registro real: la base de datos, el contenido de las páginas archivadas, las miniaturas y la configuración. Monta /shiori antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Confirma el montaje escribiendo datos inocuos, reemplazando Shiori y volviendo a leerlos.

Las snapshots son útiles para hacer rollback rápidamente, pero necesitas una copia de seguridad independiente cuando el host o el volumen desaparecen. Restaura en un entorno vacío con la imagen fijada y verifica que vuelvan los marcadores, las etiquetas, los archivos archivados y las cuentas, y que un enlace de origen inactivo siga abriendo su contenido guardado. Usa volúmenes persistentes y snapshots para mantener diferenciados estos dos mecanismos de recuperación.

Decisiones de seguridad específicas de Shiori

El riesgo de seguridad específico de la aplicación consiste en mantener sin cambios la cuenta inicial en una instancia pública. La respuesta operativa es sustituir la cuenta inicial, limitar el uso compartido público y tratar las URL privadas archivadas como contenido sensible. Completa el bootstrap mediante una ruta restringida y elimina inmediatamente después el acceso temporal de configuración.

SHIORI_DIR controla el comportamiento, no la confidencialidad; valida su tipo y valor, y almacena las credenciales reales de Shiori por separado. Concede al proceso de Shiori únicamente los montajes y las rutas de dependencias documentados; evita el acceso a la raíz del host y al socket de Docker. Registra los fallos de autenticación y los errores de configuración, pero redacta los tokens, las cadenas de conexión y el contenido de los usuarios.

Prueba de aceptación de Shiori para producción

Una release candidate de Shiori se gana el tráfico al completar un escenario fijo: guarda un marcador con contenido archivado, búscalo, edita sus etiquetas y verifica que el archivo siga disponible después de que cambie la página de origen. Captura el digest de la imagen, la configuración efectiva sin secretos, el origen público y las marcas de tiempo de ese escenario. Los datos de prueba deben ser desechables, pero lo bastante realistas como para recorrer la misma ruta que usan los usuarios.

Ejecútalo después de reemplazar el entorno de ejecución y, a continuación, reconstruye el servicio a partir de la base de datos, el contenido de las páginas archivadas, las miniaturas y la configuración. La recuperación es correcta cuando vuelven los marcadores, las etiquetas, los archivos archivados y las cuentas, y un enlace de origen inactivo sigue abriendo su contenido guardado. Compara las mediciones de recursos de la captura de páginas mediante el navegador, el tamaño de los archivos, las miniaturas y las solicitudes salientes con la release anterior, e investiga cualquier desviación relevante antes de promocionarla.

Por último, ejecuta este fallo controlado: deniega temporalmente la ruta de prueba utilizada por un volumen de datos con permisos de escritura y el acceso saliente a las páginas archivadas. Verifica que Shiori explique el fallo, no dañe el estado existente y se recupere cuando vuelva a cumplirse la condición válida. Guarda un fragmento de log redactado y el tiempo de recuperación. En conjunto, estas comprobaciones cubren el comportamiento, la durabilidad y la operabilidad, no solo el tiempo de actividad del proceso.

Inicia Shiori con valores predeterminados observables

Mantén la invocación inicial de Shiori lo bastante reproducible como para revisarla en un pull request.

docker run -d \
  --name shiori \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v shiori-data:/shiori \
  -e SHIORI_DIR=/shiori \
  ghcr.io/go-shiori/shiori:latest

No dependas de latest cuando ya existan datos reales. Captura el digest utilizado, el usuario del contenedor y la propiedad del montaje. Sigue el log de la aplicación durante una prueba completa —guarda un marcador con contenido archivado, búscalo, edita sus etiquetas y verifica que el archivo siga disponible después de que cambie la página de origen— y anota cualquier migración antes de poner la ruta detrás del tráfico de producción.

Dominios, headers del proxy y puerto 8080

Trata la URL externa de Shiori como una configuración que debe sobrevivir a los redeploys. Primero dirige la interfaz y la API a través de un origen HTTPS estable; después dirige el hostname al puerto 8080 conservando intactos el host y el esquema originales.

La lista de comprobación de reachability del despliegue puede demostrar que las solicitudes entran en el contenedor. A partir de ahí, el fallo conocido —el archivado falla porque faltan dependencias de Chromium o los permisos del sistema de archivos son incorrectos— debe investigarse en Shiori, en su estado o en su carga de trabajo, no en la automatización de certificados.

Actualiza Shiori sin hacer suposiciones

La primera métrica operativa útil de Shiori es si puede guardar un marcador con contenido archivado, buscarlo, editar sus etiquetas y verificar que el archivo siga disponible después de que cambie la página de origen. Combínala con señales de saturación de la captura de páginas mediante el navegador, el tamaño de los archivos, las miniaturas y las solicitudes salientes. Un sondeo que solo compruebe el proceso no debería llamar a dependencias costosas ni reiniciar el contenedor porque un servicio upstream no esté disponible durante unos instantes.

Trata las actualizaciones como cambios de datos porque las migraciones de la base de datos de Shiori y las dependencias de captura de páginas pueden cambiar el comportamiento del archivado. Fija las versiones, ensaya la actualización sobre un estado restaurado y conserva la imagen anterior hasta que el rollback siga siendo válido. Cuando el archivado falle porque faltan dependencias de Chromium o los permisos del sistema de archivos son incorrectos, conserva los logs anteriores al reinicio; normalmente contienen el mensaje que identifica la causa.

Qué debería automatizar Dockup para Shiori

La capa de plataforma de Shiori consta del puerto 8080, el ingress, TLS, la configuración del entorno de ejecución, el almacenamiento y la reachability de las dependencias. Dockup puede reproducir estos elementos para su propia infraestructura o para un servidor que conecte el cliente.

Después, el operador completa la capa de producto: dirige la interfaz y la API a través de un origen HTTPS estable; aplica esta regla de acceso —sustituye la cuenta inicial, limita el uso compartido público y trata las URL privadas archivadas como contenido sensible—; y ejecuta «guarda un marcador con contenido archivado, búscalo, edita sus etiquetas y verifica que el archivo siga disponible después de que cambie la página de origen». Registrar esa prueba junto al despliegue evita confundir el aprovisionamiento automatizado con la preparación de la aplicación.

Preguntas frecuentes

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

Dirige el contenedor de Shiori en el puerto 8080 a través de un único origen HTTPS. El requisito externo de entrega es disponer de un volumen de datos con permisos de escritura y acceso saliente a las páginas que se van a archivar. No consideres que Shiori está listo hasta que puedas guardar un marcador con contenido archivado, buscarlo, editar sus etiquetas y verificar que el archivo siga disponible después de que cambie la página de origen.

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

Conserva /shiori e incluye la base de datos, el contenido de las páginas archivadas, las miniaturas y la configuración en el mismo manifiesto de recuperación. Una restauración limpia de Shiori solo es correcta cuando vuelven los marcadores, las etiquetas, los archivos archivados y las cuentas, y un enlace de origen inactivo sigue abriendo su contenido guardado.

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

Usa HTTPS para el origen público de Shiori y mantén el puerto 8080 en la ruta interna. Aplica correctamente la configuración de Shiori: dirige la interfaz y la API a través de un origen HTTPS estable. En Shiori, 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 Shiori?

Restaura el estado actual de Shiori 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 Shiori y las dependencias de captura de páginas pueden cambiar el comportamiento del archivado. Conserva la imagen anterior de Shiori hasta comprender los límites de la migración de datos y del rollback.