Cómo alojar Memos en 2026: notas, acceso a la API y backups

Considera Memos como un sistema pequeño, no como una imagen de Docker. El objetivo de cara al usuario es claro: notas Markdown rápidas con una API; el despliegue solo es aceptable cuando puedes crear una nota privada y un adjunto, recuperarlos a través de la API, editarlos y confirmar que siguen disponibles después de reemplazar el contenedor.

Esta distinción permite detectar el fallo habitual con el que se encuentran los operadores después de las pruebas locales: el archivo de base de datos está en la capa del contenedor y desaparece al reemplazarlo. También hace que el plan de backup y actualización sea lo bastante específico como para poder probarlo.

Convierte el comando local en un servicio inspeccionable

El primer contenedor debe ser fácil de eliminar y volver a crear. Mantén los datos fuera de la capa de escritura, enlaza el puerto 5230 solo donde el proxy pueda acceder a él y pasa la configuración en tiempo de ejecución.

docker run -d \
  --name memos \
  --restart unless-stopped \
  -p 127.0.0.1:5230:5230 \
  -v memos-data:/var/opt/memos \
  neosmemo/memos:stable --mode prod --port 5230

Fija la versión de la imagen después de la prueba inicial. Lee el primer error de arranque en lugar del mensaje final de reinicio, verifica cada montaje con docker inspect y sigue los logs mientras creas una nota privada y un adjunto, los recuperas a través de la API, los editas y confirmas que siguen disponibles después de reemplazar el contenedor. Esta secuencia permite distinguir un comando de imagen incorrecto de un problema de dependencias o permisos.

Define primero qué significa que Memos funciona

Separa cuatro aspectos de Memos: la entrada, el listener en 5230, el estado persistente y los servicios de soporte o la capacidad local. El requisito del runtime local es un volumen persistente para su base de datos integrada y sus recursos. Prueba ese límite antes de publicar el servicio y de nuevo después de reemplazar un contenedor.

Ejecuta la transacción conocida —crear una nota privada y un adjunto, recuperarlos a través de la API, editarlos y confirmar que siguen disponibles después de reemplazar el contenedor— antes de dar por completa esa separación. Mide las escrituras de SQLite, el crecimiento de los adjuntos, el tráfico de la API y las búsquedas sobre las notas acumuladas, y conserva el resultado junto con el registro del despliegue. Esto proporciona tanto un criterio de aceptación como la primera referencia de capacidad.

No des a Memos acceso a todo el host

En Memos, la superficie importante no tiene por qué ser la página de inicio. El error principal es dejar abierto el registro durante más tiempo del previsto. Contrarréstalo de forma deliberada: cierra el registro cuando corresponda y mantén las notas privadas detrás de una cuenta segura y HTTPS.

Memos no tiene un secreto de bootstrap obligatorio en esta configuración base; protege en su lugar la cuenta de administrador real o la autenticación del sistema upstream. Usa un usuario de contenedor sin privilegios cuando la imagen lo permita y no montes credenciales que no estén relacionadas. Aplica límites de rate o tamaño en la entrada, donde el trabajo no confiable pueda consumir escrituras de SQLite, crecimiento de adjuntos, tráfico de la API y búsquedas sobre las notas acumuladas.

TLS es fácil; las URL generadas no

Evita usar orígenes públicos temporales o permanentes para Memos. En su lugar, utiliza un origen HTTPS estable para los clientes del navegador y la API, apunta el nombre DNS elegido a la ruta de la plataforma y configura el proxy para que solo reenvíe al puerto 5230.

Ejecuta esta acción desde fuera del host: crea una nota privada y un adjunto, recupéralos a través de la API, edítalos y confirma que siguen disponibles después de reemplazar el contenedor. Si falla la entrada, la guía de solución de problemas de 502 cubre los errores de puerto y listener. Si Memos recibe la solicitud, pero el archivo de base de datos está en la capa del contenedor y desaparece después de reemplazarlo, las pruebas ya apuntan a un problema más allá del proxy.

Demuestra que Memos sobrevive a un reemplazo

Una imagen de contenedor se puede volver a descargar; la base de datos de Memos y los recursos subidos no. Monta /var/opt/memos antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Inspecciona el montaje efectivo en lugar de confiar en el nombre de un archivo de Compose y comprueba que el usuario del runtime puede escribir donde Memos lo necesita.

Elige una política de retención y un destino externo al host, y después ensaya la recuperación sin tocar producción. El ejercicio solo se supera cuando vuelven los usuarios, las notas, las etiquetas y los recursos, y la API recupera la nota privada conocida. Para estados respaldados por una base de datos, combina snapshots del almacenamiento con exportaciones coherentes con la aplicación, tal como se describe en recuperación point-in-time frente a snapshots.

Cinco comprobaciones más fiables que la salud del contenedor

No uses el tráfico del primer usuario como prueba de aceptación de Memos. Prepara un estado de ejemplo inocuo y ejecuta la acción completa «crear una nota privada y un adjunto, recuperarlos a través de la API, editarlos y confirmar que siguen disponibles después de reemplazar el contenedor». Anota la URL pública exacta, el resultado, la referencia de la imagen y el intervalo de logs asociados a la ejecución.

Reemplaza el contenedor y repite la prueba sin reconstruir los datos. Después, recupera el servicio en un host vacío; la condición de recuperación es que vuelvan los usuarios, las notas, las etiquetas y los recursos, y que la API recupere la nota privada conocida. Observa las escrituras de SQLite, el crecimiento de los adjuntos, el tráfico de la API y las búsquedas sobre las notas acumuladas en cada ejecución, y define una alerta en torno al deterioro de la transacción, no en torno a las métricas de un contenedor inactivo.

Una última comprobación debe fallar a propósito: envía una entrada inocua cerca del límite de recursos o formato asociado a este límite: el archivo de base de datos está en la capa del contenedor y desaparece después de reemplazarlo. Verifica que el mensaje resultante de Memos identifica el límite relevante en lugar de provocar el borrado de datos o un reinicio infinito. Restablece la condición válida y confirma que la misma transacción de ejemplo se completa correctamente. Incluye este breve ejercicio en la checklist de release.

Logs que responden a la siguiente pregunta

Usa «crear una nota privada y un adjunto, recuperarlos a través de la API, editarlos y confirmar que siguen disponibles después de reemplazar el contenedor» como smoke test de Memos después de cada despliegue. Sus métricas de soporte son las escrituras de SQLite, el crecimiento de los adjuntos, el tráfico de la API y las búsquedas sobre las notas acumuladas; define alertas cuando esos recursos se acerquen a un punto que degrade la acción del usuario.

El principal riesgo de cambio es que las migraciones de la base de datos de Memos deben ensayarse sobre una copia, porque todo el estado del servicio vive en una única ruta compacta. Un release seguro parte de un snapshot recuperable y valida cualquier cambio de estado unidireccional antes de mover el tráfico. Cuando el archivo de base de datos está en la capa del contenedor y desaparece después de reemplazarlo, conserva el contenedor fallido el tiempo suficiente para leer su configuración y el primer error.

Usa Dockup para la capa de plataforma

Dockup elimina el trabajo manual de reverse proxy y gestión del ciclo de vida alrededor de Memos. El servicio recibe una ruta HTTPS estable al puerto 5230, configuración inyectada y almacenamiento persistente durante los reemplazos. Un servidor de cliente conectado sigue el mismo modelo que el compute alojado en Dockup.

Después del lanzamiento, cumple el contrato de la aplicación: usa un origen HTTPS estable para los clientes del navegador y la API, confirma el requisito local —un volumen persistente para su base de datos integrada y sus recursos— y ejecuta esta prueba: crea una nota privada y un adjunto, recupéralos a través de la API, edítalos y confirma que siguen disponibles después de reemplazar el contenedor. Así, la experiencia de un clic sigue siendo útil sin ocultar los detalles que hacen que Memos sea recuperable y seguro.

Preguntas frecuentes

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

Enruta el contenedor de Memos en el puerto 5230 a través de un único origen HTTPS. El requisito del runtime local es un volumen persistente para su base de datos integrada y sus recursos. No consideres que Memos está listo hasta que puedas crear una nota privada y un adjunto, recuperarlos a través de la API, editarlos y confirmar que siguen disponibles después de reemplazar el contenedor.

¿Qué datos de Memos deben incluirse en un backup?

Persiste /var/opt/memos e incluye la base de datos de Memos y los recursos subidos en el mismo manifiesto de recuperación. Una restauración limpia de Memos solo se completa cuando vuelven los usuarios, las notas, las etiquetas y los recursos, y la API recupera la nota privada conocida.

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

Usa HTTPS para el origen público de Memos y mantén el puerto 5230 en la ruta interna. Aplica correctamente la configuración de Memos: utiliza un origen HTTPS estable para los clientes del navegador y la API. En Memos, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente que depende del origen.

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

Restaura el estado actual de Memos 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 Memos deben ensayarse sobre una copia, ya que todo el estado del servicio vive en una única ruta compacta. Conserva la imagen anterior de Memos hasta comprender los límites de migración de datos y rollback.