Cómo ejecutar Hermes Agent en un servidor doméstico sin perder datos

Respuesta rápida

Para ejecutar Hermes Agent en un servidor doméstico sin perder datos, no confíes en el sistema de archivos interno del contenedor como el único lugar donde viven la configuración, habilidades, registros, archivos generados o configuración de la pasarela. Planifica primero una carpeta persistente del host o un volumen Docker, móntalo en la ruta del contenedor que la aplicación realmente usa, verifica la propiedad de los archivos y confirma que los datos sigan existiendo después del reinicio o reconfiguración. Este artículo se centra en el patrón común de fallo donde un contenedor no puede encontrar una carpeta debido a problemas de montaje de volumen, permisos o mapeo de rutas.

El flujo de trabajo más seguro para principiantes es:

1. Identifica qué datos de Hermes Agent deben sobrevivir.
2. Elige una carpeta dedicada del host o un volumen gestionado por Docker.
3. Mapea ese almacenamiento a la ruta correcta del contenedor.
4. Confirma que el usuario de la aplicación pueda escribir en ella.
5. Haz una copia de seguridad de la configuración importante antes de actualizaciones o reconstrucciones.
6. Reinicia y verifica que la configuración, los registros, los archivos generados y la configuración de la pasarela sigan presentes.

Un contenedor en ejecución no significa automáticamente que tus datos estén seguros. Los datos están seguros solo cuando se almacenan en una ubicación persistente, son escribibles por el usuario correcto, se respaldan cuando es necesario y se validan después del reinicio.

Por qué los datos de Hermes Agent pueden desaparecer en una configuración de contenedor

Las aplicaciones en contenedores suelen ser fáciles de iniciar y reemplazar. Esto es útil para actualizaciones, pruebas y recuperación, pero también significa que cualquier cosa almacenada solo dentro de la capa desechable del contenedor puede perderse cuando el contenedor se elimina, recrea o reconstruye.

Para un agente de IA autoalojado, esto puede afectar más que la configuración básica. Dependiendo de cómo uses el agente, puede importarte la configuración del modelo, habilidades, archivos generados, registros, configuración de la pasarela de mensajería y otros estados de la aplicación.

Reinicios de contenedores vs datos persistentes de la aplicación

Un reinicio normal del contenedor no siempre elimina los datos. Si los datos están almacenados en un volumen persistente o en una carpeta del host correctamente mapeada, deberían permanecer disponibles después del reinicio.

El riesgo aparece cuando archivos importantes viven solo dentro de la capa escribible del contenedor. Esa capa no es lo mismo que una ubicación de datos persistente planificada. Si recreas el contenedor sin preservar o volver a montar la ruta correcta, la aplicación puede comenzar desde cero o no encontrar sus archivos anteriores.

Por qué eliminar o recrear un contenedor puede eliminar el estado no guardado

Eliminar o recrear un contenedor es diferente de reiniciarlo. Un contenedor recreado puede usar un nuevo sistema de archivos interno, nuevas variables de entorno o un mapeo de montaje diferente.

Si la configuración, habilidades, registros o salidas generadas por Hermes Agent nunca se escribieron en una carpeta o volumen persistente del host, es posible que no se mantengan en el nuevo contenedor. Por eso pueden ser ciertas ambas afirmaciones: “la aplicación funcionaba ayer” y “la aplicación se reinició después de la actualización”.

La práctica segura es tratar el reemplazo del contenedor como un evento de riesgo para los datos, a menos que hayas confirmado dónde se almacenan los datos de la aplicación.

Por qué se deben planificar primero las rutas del host y las rutas del contenedor

Una ruta del host es donde viven los datos en el servidor doméstico. Una ruta del contenedor es donde la aplicación ve esos datos desde dentro del contenedor. Un montaje de volumen o montaje de enlace conecta esos dos mundos.

Si la ruta del host es correcta pero está montada en la ruta incorrecta del contenedor, la aplicación puede comportarse como si la carpeta no existiera. Si la ruta del contenedor es correcta pero la ruta del host es desechable, la aplicación puede escribir datos en un lugar no deseado.

Planifique el mapeo antes de ejecutar la aplicación, no después de perder datos.

¿Qué Datos Debe Proteger Antes de Ejecutar Hermes Agent?

Antes de cambiar un contenedor, actualizar una imagen o reconfigurar una pasarela, liste los datos que sería doloroso recrear. No todos los archivos necesitan la misma protección, pero debe saber cuáles son críticos.

Una regla útil es: proteja todo lo que almacene identidad, acceso, configuración, flujo de trabajo aprendido o salida que no pueda regenerar fácilmente.

Configuración del Agente y Ajustes del Proveedor del Modelo

La configuración del modelo generalmente incluye la elección del proveedor, valores del endpoint, nombres de modelos, opciones relacionadas con el contexto y acceso a la API. Si se pierden estas configuraciones, el agente puede iniciarse pero no responder correctamente.

Almacene la configuración del modelo en una ruta de datos persistente de la aplicación, no en una sesión temporal desechable. Si la configuración se proporciona mediante variables de entorno, mantenga una copia segura del archivo compose, archivo env o notas de despliegue.

También proteja cualquier elección de configuración que determine cómo el agente usa herramientas de terminal o pasarelas de mensajería.

Memoria de la Aplicación, Sesiones, Habilidades y Estado en Tiempo de Ejecución

Los datos del agente Hermes pueden incluir más de un archivo de configuración. La estructura de datos de habilidades de Hermes explica que las habilidades viven en ~/.hermes/skills/, que es la fuente principal de verdad para habilidades empaquetadas, instaladas desde el hub y creadas por el agente. También describe el estado relacionado, como manifiestos empaquetados, paquetes de habilidades, configuración del hub tap, escrituras pendientes de habilidades y configuraciones.

Esto es importante porque las habilidades creadas por el agente pueden convertirse en memoria procedimental reutilizable. Si se monta la ruta incorrecta, puede perder no solo configuraciones, sino también flujos de trabajo que el agente aprendió o habilidades que instaló.

Trate las habilidades, paquetes, escrituras pendientes y el estado relacionado con el perfil como datos persistentes del agente.

Descargas, Archivos Generados, Registros y Salidas de Herramientas

Los archivos generados son fáciles de pasar por alto. Un agente puede crear planes, scripts, informes, capturas de pantalla, registros o archivos descargados durante el uso normal.

Estos archivos pueden guardarse en el espacio de trabajo activo, el directorio de trabajo del backend, el directorio principal de la aplicación o una ruta de salida montada. Si esa ubicación está solo dentro del contenedor, los archivos pueden desaparecer cuando se elimine el contenedor.

Para uso práctico, decida dónde deben aparecer los archivos generados en el servidor host y verifique que el contenedor escriba allí.

Claves API, Tokens de Bots y Variables de Entorno

Los secretos no son datos ordinarios de la app. Las claves API, tokens de bots, contraseñas de panel y variables de entorno necesitan tanto persistencia como protección.

No guardes secretos en carpetas de salida generadas al azar o directorios compartidos amplios. Mantenlos en una ruta de configuración controlada con acceso limitado.

Una buena configuración para manejar secretos debe responder:

• dónde se almacena el secreto;
• qué usuario puede leerlo;
• si está incluida en las copias de seguridad;
• si la copia de seguridad está cifrada o controlada en acceso;
• cómo se puede rotar el secreto si se expone.

Ruta del Host vs Ruta del Contenedor vs Montajes de Volumen

Este es el concepto clave detrás de la mayoría de los problemas “el contenedor no puede encontrar la carpeta” y “los datos desaparecieron tras reiniciar”. Un contenedor solo puede ver lo que existe dentro de su propio sistema de archivos o lo que se ha montado en él.

Usa El Mapa de Supervivencia de Datos del Agente para organizar la configuración antes de solucionar problemas.

Módulo del Marco	Pregunta Clave	Lo que te Ayuda a Decidir	Enfoque de Configuración / Solución de Problemas
Inventario de Datos	¿Qué datos deben sobrevivir al reinicio o recreación del contenedor?	Qué configuraciones, habilidades, registros, descargas, tokens y archivos generados necesitan protección	Evita tratar datos importantes del agente como estado desechable
Ruta de Persistencia	¿Dónde debe vivir la data persistente en el host?	Si usar una carpeta dedicada del host, volumen Docker o bind mount	Evita el reinicio de datos tras la recreación del contenedor
Mapeo de Montaje	¿La ruta del host está correctamente mapeada en la ruta del contenedor?	Si la app realmente puede ver la carpeta deseada	Ayuda a diagnosticar errores de carpeta faltante y ruta de destino incorrecta
Límite de Permisos	¿Qué usuario posee los datos montados y qué usuario los escribe?	Si el usuario del host, usuario del contenedor, usuario de la app o root posee los archivos	Ayuda a solucionar permisos denegados sin hacer que todo sea propiedad de root
Límite de Respaldo	¿Qué debe respaldarse antes de actualizaciones o reconfiguraciones?	Qué datos son críticos y cuáles son temporales	Evita perder configuración, habilidades, sesiones, tokens y ajustes de gateway
Validación de Reinicio	¿Los datos siguen existiendo después de reiniciar o actualizar?	Si la configuración es realmente duradera	Convierte “se ejecuta” en una verificación de seguridad repetible

Lo que el Servidor Host Almacena

El servidor host almacena las carpetas reales, discos y ubicaciones de almacenamiento gestionadas por Docker. Si usas un bind mount, eliges una carpeta específica del host. Si usas un volumen Docker nombrado, Docker elige y gestiona la ubicación de almacenamiento.

Esta distinción es importante porque la visibilidad del host afecta la copia de seguridad y la migración. Una carpeta montada con bind puede ser más fácil de localizar y copiar para un principiante. Un volumen nombrado puede ser más limpio para datos gestionados por Docker, pero aún necesitas saber cómo inspeccionarlo o respaldarlo.

Elige el estilo de almacenamiento según si necesitas carpetas del host legibles para humanos, persistencia de aplicaciones gestionada por Docker o una ruta de respaldo controlada.

Lo que el Contenedor Puede Ver

El contenedor ve su propio sistema de archivos interno y cualquier ruta montada. No ve automáticamente todas las carpetas de tu servidor doméstico.

La guía de montaje bind de Docker muestra cómo un directorio del host puede aparecer dentro de un contenedor en una ruta de destino, y cómo los cambios en los archivos pueden reflejarse entre el host y el contenedor cuando el montaje es correcto.

Esa es la idea principal: a la aplicación no le importa dónde existe un archivo en el host a menos que el archivo esté montado en la ruta que la aplicación usa.

Cómo los montajes de volumen mantienen los datos de la aplicación persistentes

Un montaje persistente le da a la aplicación un lugar estable para escribir datos más allá de la vida de un solo contenedor. Para los datos de la aplicación, esto suele ser la diferencia entre “seguro al reiniciar” y “solo durante la vida del contenedor.”

El montaje debe coincidir con la ruta de datos que la aplicación espera. Si la aplicación escribe en una carpeta interna pero montas una carpeta diferente, los datos pueden ir a un almacenamiento desechable.

Una buena configuración persistente debe definir:

• la carpeta del host o el volumen nombrado;
• la ruta objetivo del contenedor;
• si el montaje es de lectura-escritura o solo lectura;
• qué datos de la aplicación pertenecen allí;
• cómo se respaldará la ruta.

Por qué un mapeo de ruta incorrecto causa errores de carpeta faltante

Un mapeo incorrecto suele parecer un problema de carpeta faltante. La carpeta puede existir en el host, pero el contenedor no puede verla. O el contenedor puede tener una carpeta en la ruta esperada, pero no está conectada a la carpeta del host que pretendías.

Los síntomas comunes incluyen:

• la aplicación dice que una carpeta no existe;
• los archivos generados aparecen dentro del contenedor pero no en el host;
• los registros desaparecen tras reconstruir el contenedor;
• la configuración se restablece después de la actualización;
• editas una carpeta del host pero la aplicación sigue usando configuraciones antiguas;
• los scripts de respaldo se ejecutan pero no incluyen los datos reales de la aplicación.

Cuando esto sucede, revisa la ruta del host y la ruta del contenedor juntas. No inspecciones solo un lado.

Cómo ejecutar Hermes Agent sin perder datos

El objetivo no es solo iniciar Hermes Agent. El objetivo es asegurarse de que los datos que te importan sobrevivan a reinicios, actualizaciones, reconstrucciones y reconfiguraciones.

Paso 1: Elige una carpeta de datos dedicada en el host

Elige una carpeta de datos del host antes de ejecutar o reconstruir el contenedor. Debe ser fácil de identificar, fácil de respaldar y no mezclada con archivos personales no relacionados.

Una carpeta dedicada reduce el riesgo porque puedes ver qué pertenece a la aplicación. También evita montar todo tu directorio personal u otras carpetas sensibles dentro del contenedor.

Una carpeta de datos práctica en el host debe ser:

• específico para la aplicación;
• fuera de rutas desechables de descarga;
• incluido en tu plan de respaldo;
• no compartido ampliamente con servicios no relacionados;
• escribible solo por los usuarios o servicios que necesitan acceso.

Paso 2: Montar la carpeta de datos dentro del contenedor

Monta la carpeta de datos del host en la ruta del contenedor que la aplicación espera. Este es el momento en que se crean o se previenen muchos problemas de pérdida de datos.

Para un montaje bind, la ruta del host la eliges tú y la ruta de destino es donde aparece dentro del contenedor. Para un volumen nombrado, Docker gestiona la ubicación en el lado del host.

No asumas que la aplicación usará automáticamente una carpeta montada. Confirma que el destino montado coincida con la ruta real de datos de la aplicación.

Paso 3: Confirma que el contenedor usa la ruta de datos de la aplicación esperada

Después de montar, verifica la ruta desde dentro del contenedor. Una carpeta puede existir en el host y aún ser invisible para la aplicación si no está montada correctamente.

La validación más simple es crear o localizar un archivo de prueba inofensivo desde un lado y confirmar que aparece en el otro. Luego verifica que la aplicación escriba archivos reales de configuración, registros o generados en la misma ruta persistente.

Este paso es especialmente importante antes de actualizaciones o migraciones.

Paso 4: Verifica la propiedad del archivo y los permisos de escritura

Un montaje correcto aún puede fallar si la aplicación no puede escribir en él. Los errores de permiso suelen ocurrir cuando los archivos son creados por root pero la aplicación luego se ejecuta como un usuario diferente.

Verifica la propiedad antes de cambiar permisos de forma amplia. La solución correcta suele ser permitir que el usuario previsto de la aplicación pueda leer y escribir en la carpeta específica de datos de la aplicación, no dar control total a todos los procesos sobre directorios amplios del host.

Si ves permiso denegado, identifica:

1. la ruta montada en el host;
2. la ruta objetivo del contenedor;
3. el usuario que ejecuta la aplicación;
4. el propietario del archivo;
5. si el montaje es de solo lectura;
6. si una ruta de respaldo o exportación también es escribible.

Paso 5: Mantén secretos y archivos de configuración fuera de rutas desechables

Los secretos y archivos de configuración no deben vivir solo en carpetas temporales, directorios de salida generados o historial de shell ad hoc. Si usas variables de entorno, mantén el archivo de despliegue o env en una ubicación persistente y controlada.

Evita mezclar secretos con registros o artefactos generados. Los registros pueden compartirse para solución de problemas, mientras que los secretos nunca deben compartirse de forma casual.

Si haces respaldo de secretos, protege la copia. Un respaldo que expone claves API o tokens de bot crea un tipo diferente de riesgo.

Paso 6: Reinicia el contenedor y verifica que los datos sigan existiendo

Después de la configuración, reinicia el contenedor y verifica si los datos importantes permanecen. Esta es la prueba más práctica de persistencia.

No te detengas en “el contenedor inicia.” Confirma que:

• la configuración del modelo sigue existiendo;
• las habilidades o el estado de la aplicación permanecen visibles;
• los registros continúan en el lugar esperado;
• los archivos generados aparecen en el host;
• la configuración del gateway o bot sigue funcionando;
• se pueden localizar archivos de respaldo.

Una configuración que pasa la validación tras reiniciar es mucho más segura que una que solo pasó la instalación inicial.

Permisos, respaldos y límites de seguridad

La seguridad de los datos depende de tres límites: quién puede escribir, qué se respalda y qué puede tocar el agente. Estos límites son especialmente importantes para agentes autoalojados porque pueden crear archivos, modificar flujos de trabajo o interactuar con herramientas.

Por qué importan los permisos de usuario del contenedor

Los permisos de usuario del contenedor deciden si la aplicación puede leer y escribir sus datos. Si la aplicación se ejecuta como un usuario pero la carpeta montada pertenece a otro usuario, las operaciones de escritura pueden fallar.

Por eso ejecutar un comando de configuración como root puede crear un problema posterior. Root puede crear archivos con éxito, pero el usuario normal de la aplicación puede no poder modificarlos.

Corrige los permisos a nivel de la carpeta de datos de la aplicación. Evita cambios amplios de permisos que expongan archivos no relacionados del host.

Por qué debes evitar ejecutar todo como root

Root puede evitar muchas restricciones, pero eso no lo hace un valor predeterminado seguro. Ejecutar todo como root puede crear archivos propiedad de root, ocultar problemas de permisos y dar a la aplicación más acceso del que necesita.

Para la mayoría de los flujos de trabajo de aplicaciones autoalojadas, root debe usarse solo para pasos administrativos específicos. La configuración rutinaria de la aplicación debe ejecutarse como el usuario previsto de la aplicación o contenedor cuando sea posible.

Un patrón más seguro es el de menor privilegio: da a la aplicación acceso de escritura solo a las carpetas que necesita.

Cuándo usar montajes de solo lectura o carpetas limitadas

Usa montajes de solo lectura cuando el agente necesite inspeccionar archivos pero no modificarlos. Usa carpetas limitadas con escritura cuando el agente necesite crear resultados pero no tocar directorios personales o del sistema amplios.

Esto es especialmente útil cuando quieres que el agente genere informes, planes o scripts sin darle acceso de escritura a todos los archivos del servidor.

Un diseño de carpeta limitada reduce el impacto de errores. También facilita las copias de seguridad porque sabes qué carpeta contiene el estado de la aplicación y cuál contiene los resultados generados.

Cómo hacer una copia de seguridad de los datos del agente antes de actualizaciones o reconfiguraciones

Haz una copia de seguridad de los datos importantes de la aplicación antes de cambiar imágenes de contenedores, rutas de montaje, configuraciones de gateway o perfiles. Una copia de seguridad es útil solo si sabes qué incluye y cómo restaurarla.

La comunidad de Docker discusión sobre permisos denegados en respaldo de volúmenes muestra un patrón común de fallo para usuarios: una ruta puede existir, pero las operaciones de respaldo o escritura pueden fallar debido a restricciones de permisos, propiedad, etiquetado o montaje.

Usa eso como recordatorio para probar las copias de seguridad, no solo para crearlas. Un plan de respaldo debe incluir tanto la creación de copias como la verificación de restauración.

Problemas comunes y cómo solucionarlos

Cuando faltan datos del agente Hermes, no reinstales la aplicación de inmediato. Primero identifica qué capa falló: inventario de datos, ruta de persistencia, mapeo de montaje, límite de permisos, límite de respaldo o validación de reinicio.

El contenedor no puede encontrar una carpeta montada

Esto generalmente significa que la ruta existe en una capa pero no en la otra. La carpeta del host puede no estar montada, la ruta de destino del contenedor puede ser incorrecta, o la aplicación puede estar buscando en otro lugar.

Verifica en este orden:

1. Confirma que la carpeta exista en el host.
2. Confirma que el contenedor tenga el montaje.
3. Confirma la ruta de destino dentro del contenedor.
4. Confirma que la aplicación esté configurada para usar esa ruta de destino.
5. Confirme que el usuario de la aplicación pueda leer la carpeta.
6. Confirme que el montaje fue recreado después de cambiar la configuración de compose o run.

No solucione esto creando carpetas aleatorias dentro del contenedor. Eso puede hacer que el error desaparezca temporalmente mientras deja los datos en almacenamiento desechable.

Los datos de la aplicación se restablecen después del reinicio

Si los datos se restablecen después del reinicio, la aplicación puede estar escribiendo en el sistema de archivos interno del contenedor en lugar de la ruta persistente. También puede estar usando un perfil, variable de entorno o directorio de datos diferente al esperado.

Verifique si la ruta de datos antes y después del reinicio es la misma. Luego verifique si la carpeta está respaldada por un montaje o solo por la capa del contenedor.

Si la aplicación fue recreada, confirme que el mismo volumen o montaje de enlace se adjuntó al nuevo contenedor.

Errores de permiso denegado en el directorio de datos

Permiso denegado significa que la aplicación puede ver la ruta pero no puede realizar la acción requerida. El problema puede ser la propiedad, configuraciones de montaje de solo lectura, etiquetas del sistema de archivos o una discrepancia entre el usuario del host y el usuario del contenedor.

Comience con la verificación más pequeña: ¿puede el usuario de la aplicación crear un archivo de prueba inofensivo en el directorio de datos? Si no, inspeccione el propietario y el modo de esa ruta específica.

Evite resolver esto dando acceso de escritura amplio a todo el directorio del host. Corrija la ruta de datos de la aplicación y el usuario previsto de la aplicación.

Los archivos generados se guardan solo dentro del contenedor

Si los archivos generados desaparecen después de la reconstrucción, probablemente se guardaron dentro del contenedor en lugar de en una ruta montada del host. Esto suele ocurrir cuando el directorio de trabajo o el directorio de salida de la aplicación no están mapeados.

Decida dónde deben guardarse los archivos generados. Luego monte esa carpeta de salida o configure la aplicación para que escriba en una ubicación persistente existente.

Después de cambiar la ruta, genere un archivo de prueba inofensivo y confirme que aparezca en el host.

Configuraciones del bot o gateway desaparecen después de la reconfiguración

La configuración del gateway puede desaparecer si se almacena en una ruta no persistente o si la aplicación se ejecuta bajo un perfil diferente después del reinicio. Lo mismo puede ocurrir si una variable de entorno se cambia en un lugar pero el contenedor en ejecución usa otro valor.

Verifique si la configuración del gateway, la referencia del token del bot, la lista blanca y la configuración del panel están almacenadas en la ubicación persistente esperada. Luego reinicie el gateway y confirme que las configuraciones sigan activas.

Si el bot funciona antes del reinicio pero no después, concéntrese en la persistencia y la configuración del entorno antes de cambiar el token.

Cómo verificar si los datos de su agente Hermes están seguros

Una configuración segura debe pasar las pruebas de reinicio, escritura, respaldo y acceso. Estas pruebas no necesitan ser complicadas, pero deben repetirse después de cambios importantes.

La configuración persiste después del reinicio

Cambie una configuración inofensiva, reinicie el contenedor y verifique que la configuración permanezca. Esto confirma que la aplicación está escribiendo en almacenamiento persistente.

Si la configuración desaparece, no continúe agregando más configuraciones. Primero corrija la ruta de los datos.

Los Registros y Archivos Generados Aparecen en la Carpeta Esperada del Host

Los registros y archivos generados deben aparecer donde los esperas en el host. Si solo aparecen dentro del contenedor, pueden perderse durante la reconstrucción.

Revisa ambos lados del montaje. El host y el contenedor deben coincidir respecto a los archivos importantes.

El Agente Puede Escribir en los Datos de la Aplicación Sin Errores de Permisos

El agente debe poder escribir en su carpeta de datos de la aplicación como el usuario previsto. Una prueba de escritura exitosa es más útil que simplemente confirmar que la carpeta existe.

Atento a errores de permisos en los registros después del reinicio. Algunos problemas de permisos aparecen solo cuando el agente intenta actualizar la configuración, escribir una habilidad, guardar un archivo generado o actualizar el estado de la puerta de enlace.

Los Archivos de Copia de Seguridad Pueden Ser Localizados y Restaurados

Una copia de seguridad está incompleta hasta que puedas localizarla y restaurarla en un lugar de prueba. Como mínimo, confirma que la copia contiene los datos que pretendías proteger.

Para configuraciones importantes, restaura la copia de seguridad en una carpeta separada o en una instancia de prueba antes de confiar en ella. Esto evita descubrir problemas de restauración solo después de perder datos.

El Acceso al Panel o a la Mensajería Sigue Funcionando Después del Reinicio

Después del reinicio, verifica que el acceso al panel o a la mensajería siga funcionando. Esto confirma que los datos persistentes, las credenciales, la configuración de la puerta de enlace y el acceso a la red siguen alineados.

Si el panel funciona pero la mensajería falla, verifica la configuración de la puerta de enlace y el acceso al token. Si la mensajería funciona pero los archivos generados desaparecen, revisa la ruta de salida y los montajes.

Cómo Funciona Esto en un Entorno Real de Servidor Doméstico

En una configuración real de servidor doméstico, la misma lógica de seguridad de datos se aplica incluso cuando el sistema proporciona un panel amigable. Aún necesitas saber qué datos deben sobrevivir, dónde se almacenan, cómo los ve el contenedor, qué usuario puede escribir en ellos y cómo verificarlos después del reinicio.

Por ejemplo, el flujo de configuración del agente Hermes de ZimaOS muestra una ruta específica del dispositivo que incluye la configuración del proveedor de modelos, la configuración de la puerta de enlace de Telegram, el acceso al contenedor Hermes, la activación del entorno de la aplicación, la comprobación del Panel Web y la solución de problemas de permisos o respuestas del bot.

Para los usuarios que ejecutan aplicaciones Docker, flujos de trabajo de agentes y servicios locales en una máquina compacta siempre encendida, el servidor doméstico ZimaBoard 2 es un ejemplo relevante del tipo de entorno de servidor doméstico ligero donde las carpetas persistentes, las rutas de contenedores, los permisos y la expansión de almacenamiento deben planificarse juntos. No es la única configuración posible, pero coincide con el tipo de flujo de trabajo de aplicaciones autoalojadas que se discute en esta guía.

La lección general es portátil: antes de confiar en un agente en contenedor para trabajo útil, asegúrese de que sus datos importantes sobrevivan más allá del contenedor que esté ejecutándose hoy.

Preguntas frecuentes

¿Por qué desaparecieron mis datos de Hermes Agent después de reiniciar el contenedor?

Un reinicio simple no debería eliminar datos persistentes, pero la aplicación puede parecer reiniciada si estaba escribiendo en una ruta no persistente del contenedor. Los datos también pueden faltar si el contenedor se recreó sin el mismo volumen o montaje enlazado. Verifique la ruta del host, la ruta del contenedor y la ruta real de los datos de la aplicación antes de cambiar más configuraciones.

¿Cuál es la diferencia entre un volumen de Docker y un montaje enlazado?

Un volumen de Docker es gestionado por Docker, mientras que un montaje enlazado (bind mount) mapea una carpeta del host que usted elige dentro del contenedor. Un volumen suele ser limpio para datos gestionados por la aplicación, mientras que un montaje enlazado es más fácil de localizar directamente en el host. La mejor opción depende de si desea almacenamiento gestionado por Docker o una carpeta visible en el host para respaldo e inspección.

¿Dónde debo almacenar los datos de la aplicación Hermes Agent en un servidor doméstico?

Use una carpeta persistente dedicada o un volumen de Docker en lugar de una ruta temporal del contenedor. La ubicación debe ser fácil de respaldar, limitada a las necesidades de la aplicación y no mezclada con archivos sensibles no relacionados. El punto más importante es que la ruta esperada por la aplicación dentro del contenedor debe mapearse realmente a ese almacenamiento persistente.

¿Por qué el contenedor dice que una carpeta no existe?

La carpeta puede existir en el host pero no dentro del contenedor. Esto generalmente significa que el montaje no se creó, la ruta de origen es incorrecta, la ruta de destino es incorrecta o la aplicación está buscando en una ruta diferente dentro del contenedor. Verifique tanto el lado del host como el del contenedor en lugar de crear una carpeta nueva a ciegas.

¿Debo ejecutar Hermes Agent como root para evitar errores de permisos?

Ejecutar como root puede ocultar el error inmediato, pero puede crear archivos propiedad de root y aumentar el riesgo. Un enfoque más seguro es permitir que el usuario de la aplicación pueda leer y escribir solo en la ruta de datos requerida. Use root solo para acciones administrativas o de reparación específicas cuando entienda el cambio.

¿Con qué frecuencia debo hacer una copia de seguridad de los datos de Hermes Agent?

Realice una copia de seguridad antes de actualizaciones, reconstrucciones de contenedores, cambios de ruta, reconfiguración de la puerta de enlace o migración a otro servidor. Para un uso activo, programe copias de seguridad regulares según la frecuencia con la que cambien las habilidades, configuraciones, archivos generados o sesiones. Una copia de seguridad no es confiable hasta que haya confirmado que los archivos pueden ser localizados y restaurados.