Skip to main content
Ayakaleaf Pro se ejecuta en tu infraestructura. Tú controlas sus datos, el acceso y los límites de red. Esta página explica el modelo de seguridad predeterminado. También identifica tus responsabilidades operativas.

​
¿Es Ayakaleaf Pro fiable y seguro?

Ayakaleaf Pro es una mejora autoalojada de Overleaf Pro, y nuestro código fuente está disponible en ayaka-notes/ayakaleaf-pro. Tu despliegue controla dónde se ejecutan los servicios y dónde residen los datos. La seguridad depende de tu configuración y de tu operación. Protege el acceso de administrador, habilita HTTPS y mantén copias de seguridad. Gracias a OpenAI por su amable apoyo. Usaremos periódicamente Codex Security para analizar nuestro repositorio en busca de problemas de seguridad y compartiremos públicamente los resultados de las correcciones de vulnerabilidades.

​
¿Adónde van mis datos?

De forma predeterminada, los datos de la aplicación permanecen dentro de tu despliegue:
  • MongoDB almacena los datos de usuarios y proyectos.
  • Redis almacena la caché y los datos de colaboración en tiempo real.
  • Los volúmenes locales o el almacenamiento compatible con S3 contienen los archivos de los proyectos.
De forma predeterminada, solo se expone el servicio web. Los servicios internos se comunican a través de la red de Docker.

​
¿Se enviarán mis datos a terceros o se obtendrán de ellos?

Nada sale de tu despliegue a menos que habilites una función que lo requiera. Ayakaleaf Pro no envía telemetría, analíticas de uso ni informes de fallos. Los informes de errores y las analíticas están deshabilitados en la configuración predeterminada. Varias funciones nunca realizan solicitudes externas. Las plantillas se almacenan y se sirven desde tu propio despliegue. El ejecutor de scripts de Python se ejecuta en el navegador del usuario mediante WebAssembly, y su entorno de ejecución se sirve desde tu propio servicio web en lugar de desde una CDN pública, por lo que el código y la salida de los scripts nunca llegan a la red. Git Bridge solo es accesible en la red interna de Docker. La búsqueda completa en proyectos, la paleta de símbolos, el control de cambios, el historial de proyectos y el panel de administración son totalmente locales. Los contenedores de compilación en sandbox se crean con la red deshabilitada. Las solicitudes de las funciones restantes llegan a los siguientes destinos. Cada solicitud se origina en el servicio web:
Las funciones de IA están deshabilitadas de forma predeterminada. Cuando se habilitan, el chat y las sugerencias para errores de LaTeX envían prompts y el contexto relevante del proyecto al endpoint del modelo configurado con AI_BASE_URL. La búsqueda web opcional envía consultas al servicio compatible con Tavily configurado, y la búsqueda en la documentación envía consultas a DOCS_MCP_URL (predeterminado: https://docs.overleaf.com/~gitbook/mcp). Los resultados de búsqueda pueden incluirse en las solicitudes al proveedor del modelo. Consulta Integración de IA para la configuración y los controles de usuario.
La integración con GitHub se comunica con github.com y api.github.com. Se habilita por usuario vinculando una cuenta de GitHub, y la autorización solicita los scopes read:org, repo y workflow. Al hacer push se sube el contenido completo de los archivos del proyecto como blobs de Git, que luego se ensamblan en árboles y commits. También realiza operaciones de ramas, referencias, comparación y fusión, y lee el perfil de la cuenta vinculada, sus pertenencias a organizaciones y su lista de repositorios. El contenido del proyecto sale de tu despliegue en ambas direcciones: trata una cuenta de GitHub vinculada como una vía de exportación para todos los proyectos asociados a ella.
La integración con Zotero se comunica con www.zotero.org para la autorización y con api.zotero.org para los datos de la biblioteca. Se habilita por usuario vinculando una cuenta de Zotero. Se envían el intercambio OAuth y la clave de API del usuario. Las lecturas son unidireccionales: las bibliotecas de referencias se importan como BibTeX y no se sube ningún contenido de los proyectos.
La integración con Mendeley se comunica con api.mendeley.com tanto para la autorización como para los datos de la biblioteca. Se habilita por usuario vinculando una cuenta de Mendeley. El intercambio OAuth solicita el scope all de Mendeley, el único que ofrece su API, pero Ayakaleaf solo realiza lecturas: las bibliotecas de referencias y las bibliotecas de grupo se importan como BibTeX y no se sube ningún contenido de los proyectos. Los tokens de acceso se renuevan automáticamente; cuando Mendeley revoca una autorización, la credencial almacenada se descarta y se pide al usuario que vuelva a vincular la cuenta.
Las páginas de documentación se obtienen de https://learnwiki.overleaf.com, configurable con WIKI_URL. Las solicitudes las realiza el servicio web, no el navegador del usuario, por lo que la wiki de origen ve tu servidor y nunca las direcciones de tus usuarios. Solo se envía el título de la página solicitada, y las respuestas se almacenan en caché en disco. Apunta WIKI_URL a tu propio espejo, o bloquea el destino, si el tráfico saliente de documentación no es aceptable.
El envío de correo electrónico se comunica con el servidor SMTP o la API de correo que configures; no hay ninguno predeterminado. Las direcciones de los destinatarios y el contenido de los mensajes salen de tu despliegue, incluidos los enlaces de restablecimiento de contraseña y de invitación.
Dos comprobaciones opcionales están deshabilitadas de forma predeterminada. La comprobación de contraseñas comprometidas está inactiva a menos que se establezca HAVE_I_BEEN_PWNED_ENABLED; cuando está habilitada, envía los primeros caracteres de un hash SHA-1 de la contraseña a api.pwnedpasswords.com, nunca la contraseña en sí. La verificación CAPTCHA está inactiva a menos que se configure una clave de sitio de reCAPTCHA, y se comunica con www.google.com cuando está activa.
El inicio de sesión único solo llega al proveedor de identidad que proporciones, y lo que viaja hasta él depende del protocolo. Con LDAP, el servicio web se conecta directamente a tu directorio: se autentica con la cuenta de servicio que configures, busca bajo la base, el filtro y la lista de atributos que definas, y verifica la contraseña introducida en el formulario de inicio de sesión contra tu directorio, de modo que el nombre de usuario y la contraseña llegan al servidor de directorio. Habilitar los contactos respaldados por el directorio provoca una búsqueda adicional para rellenar la lista de contactos. Con OIDC, el servicio web intercambia el código de autorización en tu endpoint de token y luego llama a tu endpoint de información de usuario, solicitando de forma predeterminada los scopes openid profile email; esto se puede configurar con OVERLEAF_OIDC_SCOPE. Con SAML, la solicitud de autenticación viaja a través del navegador del usuario hasta el proveedor de identidad en lugar de mediante una conexión directa del servidor. En los tres casos, el nombre y la dirección de correo electrónico del usuario llegan desde el proveedor en lugar de enviarse a él, y luego se almacenan en el registro de usuario local.
Las credenciales de terceros (tokens OAuth y claves de API) se guardan en MongoDB en el registro del usuario, cifradas con AES-256-CTR con una sal y un vector de inicialización por registro. Nunca se almacenan en texto plano ni se escriben en los logs. La clave de cifrado proviene de ${PROVIDER}_CIPHER_PASSWORD si está establecida (como en Zotero y Mendeley); de lo contrario, se genera una en el primer uso y se conserva dentro de tu volumen de datos con permisos solo para el propietario. Haz una copia de seguridad de esa clave junto con tu volumen de datos: si se pierde, las credenciales almacenadas no podrán descifrarse y todos los usuarios tendrán que volver a vincular sus cuentas.
Los archivos vinculados desde una URL los obtiene tu despliegue en nombre del usuario, por lo que el destino es la dirección que proporcione el usuario. Los archivos de URL vinculados están deshabilitados a menos que añadas url a ENABLED_LINKED_FILE_TYPES, y la configuración predeterminada no lo incluye. Las importaciones externas de ZIP y TeX mediante la API Open in Overleaf también usan el mismo componente linked-url-proxy. Las solicitudes directas resuelven el nombre de host de destino y rechazan los rangos de red restringidos, con sujeción a las excepciones de recursos permitidos configuradas. Con OVERLEAF_LINKED_URL_OUTBOUND_PROXY configurado, el proxy saliente resuelve los nombres de host, por lo que debe aplicar él mismo las restricciones de la red interna; las comprobaciones de red de la aplicación solo se aplican a las URL que contienen direcciones IP. Consulta URL externa — Proxy saliente para más detalles. Estas solicitudes obtienen la URL proporcionada en lugar de subir archivos de los proyectos.
Si tu política exige una lista de destinos salientes permitidos, permite solo los hosts de las funciones que hayas habilitado: github.com y api.github.com para GitHub, www.zotero.org y api.zotero.org para Zotero, api.mendeley.com para Mendeley, learnwiki.overleaf.com o tu propio WIKI_URL para la documentación, api.pwnedpasswords.com para la comprobación de contraseñas, www.google.com para CAPTCHA, además de tu propio servidor de correo y proveedor de identidad. Si las funciones de IA o la búsqueda están habilitadas, permite también los endpoints configurados del modelo, de la búsqueda web y del MCP de documentación. Deniega los destinos que no requieran las funciones habilitadas. Cuando el tráfico saliente deba inspeccionarse o registrarse de forma centralizada, las integraciones con GitHub, Zotero y Mendeley pueden enrutarse cada una a través de un proxy HTTP estableciendo GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL y ZOTERO_PROXY_URL. La obtención de URL vinculadas y las importaciones remotas pueden usar OVERLEAF_LINKED_URL_OUTBOUND_PROXY. Los archivos vinculados desde una URL no pueden limitarse a una lista de hosts, ya que el destino lo elige el usuario en el momento de la solicitud; restringe esa función mediante el ajuste de recursos permitidos del propio componente proxy, o déjala deshabilitada.
Si despliegas Ayakaleaf Pro con el almacenamiento s3.md habilitado, ¿se cifran los datos almacenados en S3?No. Los datos no se cifran. Todos los fragmentos del historial, los archivos de plantillas, los PDF y demás archivos se almacenan en texto plano. Si usas un proveedor externo de almacenamiento S3 de terceros, presta especial atención a la seguridad y la privacidad de los datos.

​
¿Están aisladas las compilaciones de los proyectos?

Ayakaleaf Pro admite compilaciones en sandbox. Cada compilación se ejecuta en un contenedor independiente. Los contenedores de sandbox no tienen acceso a la red de forma predeterminada. Esto reduce la exposición a los recursos de la red interna. Las compilaciones en sandbox requieren acceso al socket de Docker del host. Restringe la administración del host a operadores de confianza.

​
¿Puedo confiar en las compilaciones de CI y en las imágenes de contenedor?

GitHub Actions compila y publica las imágenes de contenedor de Ayakaleaf Pro. Las imágenes están disponibles en el GitHub Container Registry público. Las imágenes admiten amd64 y arm64. Docker selecciona la arquitectura correspondiente al descargar una imagen. No uses la etiqueta latest en producción. Fija una versión explícita, preferiblemente un digest de imagen. Prueba cada actualización en un entorno que no sea de producción. Verifica la imagen, la configuración y las integraciones antes del despliegue.

​
¿El código es de código abierto?

Ayakaleaf Pro y los repositorios de funciones relacionados están disponibles públicamente. Esto permite a los usuarios revisar los cambios y rastrear las fuentes upstream. El código fuente público permite una revisión independiente. Por sí solo, no garantiza compilaciones de versiones reproducibles. Antes de actualizar, revisa:
  • La etiqueta de la versión o el commit.
  • La versión o el digest de la imagen.
  • Las dependencias de terceros y los requisitos de licencia.
Última modificación el 5 de octubre de 2026