> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/es/configuracion/overleaf-toolkit/compilaciones-en-entorno-aislado.md). # Compilaciones en entorno aislado Overleaf Pro incluye la opción de ejecutar compilaciones en un entorno sandbox seguro para la seguridad empresarial. Lo hace ejecutando cada proyecto en su propio entorno Docker seguro. ### Seguridad mejorada Las compilaciones en sandbox son el enfoque recomendado para Server Pro debido a que muchos documentos LaTeX requieren o tienen la capacidad de ejecutar comandos arbitrarios de shell como parte del proceso de compilación del PDF. Si usas compilaciones en sandbox, cada compilación se ejecuta en un contenedor Docker separado con capacidades limitadas que no se comparten con ningún otro usuario o proyecto y no tiene acceso a recursos externos como la red del host. {% hint style="warning" %} Si intentas ejecutar Overleaf Pro **sin** compilaciones en sandbox, la compilación se ejecuta junto con otras compilaciones simultáneas dentro del contenedor Docker principal y los usuarios tienen acceso completo de lectura y escritura a los `sharelatex` recursos del contenedor (sistema de archivos, red y variables de entorno) al ejecutar compilaciones LaTeX. {% endhint %} ### Gestión de paquetes más sencilla Para evitar instalar paquetes manualmente, recomendamos habilitar las compilaciones en sandbox. Esta es una configuración ajustable dentro de Server Pro que proporcionará a tus usuarios acceso al mismo entorno TeX Live que el de overleaf.com, pero dentro de tu propia instalación local. Las imágenes de TeX Live usadas por las compilaciones en sandbox contienen los paquetes y fuentes más populares, probados con nuestras plantillas de galería, lo que garantiza la máxima compatibilidad con los proyectos locales. Habilitar las compilaciones en sandbox te permite configurar qué versiones de TeX Live pueden elegir los usuarios dentro de su proyecto, además de establecer una versión predeterminada de la imagen de TeX Live para los nuevos proyectos. {% hint style="info" %} Si intentas ejecutar Overleaf Pro sin compilaciones en sandbox, tu instancia usará de forma predeterminada una versión de esquema básico de TeX Live para las compilaciones. Esta versión básica es ligera y solo contiene un subconjunto muy limitado de paquetes LaTeX, lo que con mucha probabilidad provocará errores de paquetes faltantes para tus usuarios, especialmente si intentan usar plantillas preconstruidas. {% endhint %} Como Overleaf Pro ha sido diseñado para funcionar sin conexión, no existe una forma automática de integrar las plantillas de galería de overleaf.com en tu instalación local; sin embargo, es posible hacerlo manualmente plantilla por plantilla. Para obtener más información sobre cómo funciona esto, consulta nuestra guía para transferir plantillas desde overleaf.com: [/pages/7231a90673c6e603d0c6758a51fb647a197c6622#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/es/configuracion/overleaf-toolkit/pages/7231a90673c6e603d0c6758a51fb647a197c6622#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxed Compiles requiere que el `sharelatex` contenedor tenga acceso al socket de Docker en la máquina host (mediante un montaje de enlace) para que pueda administrar estos contenedores de compilación hermanos. {% endhint %} ## Cómo funciona Cuando las compilaciones en sandbox están habilitadas, el socket de Docker se montará desde la máquina host dentro del `sharelatex` contenedor, de modo que el servicio compilador dentro del contenedor pueda crear nuevos contenedores Docker en el host. Luego, para cada ejecución del compilador en cada proyecto, el servicio compilador de LaTeX (CLSI) hará lo siguiente: * Escribir los archivos del proyecto en una ubicación dentro del `OVERLEAF_DATA_PATH`. * Usar el socket de Docker montado para crear un nuevo `texlive` contenedor para la ejecución de la compilación. * Hacer que el `texlive` contenedor lea los datos del proyecto desde la ubicación bajo `OVERLEAF_DATA_PATH`. * Compilar el proyecto dentro del `texlive` contenedor. ### Habilitar las compilaciones en sandbox #### Para usuarios de Toolkit Para habilitar las compilaciones en sandbox (también conocidas como contenedores hermanos), establece las siguientes opciones de configuración en `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Para usuarios de Docker Compose {% hint style="danger" %} A partir de Overleaf CE/Server Pro `5.0.3` las variables de entorno han sido renombradas de `SHARELATEX_*` a `OVERLEAF_*`. {% endhint %} Si estás usando una `4.x` versión (o anterior), asegúrate de que las variables tengan el prefijo correspondiente (por ejemplo, `SHARELATEX_MONGO_URL` en lugar de `OVERLEAF_MONGO_URL`). 
version: '2'
services:
    sharelatex:
        #...
        volúmenes:
            - /data/overleaf_data:/var/lib/overleaf
            - /var/run/docker.sock:/var/run/docker.sock
        entorno:
            #...
            DOCKER_RUNNER: "true"
            SANDBOXED_COMPILES: "true"
            SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"
            #...
        #...
### Cambiar la imagen de TexLive {% hint style="info" %} Para usuarios de China continental, puedes usar `ghcr.nju.edu.cn` para acelerar la descarga. {% endhint %} Overleaf Pro usa tres variables de entorno para determinar qué imágenes de TeX Live usar para las compilaciones en sandbox: * `TEX_LIVE_DOCKER_IMAGE` **(obligatorio),** La imagen predeterminada de TeX Live usada para compilar nuevos proyectos. Esta imagen debe incluirse en `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(obligatorio),** Una lista separada por comas de nombres descriptivos para las imágenes, usada para las opciones de la interfaz. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(obligatorio),** Una lista separada por comas de imágenes de TeX Live que se usarán. Si se usa Overleaf Toolkit para la implementación, estas imágenes se descargarán o actualizarán. Para omitir la descarga, establece `SIBLING_CONTAINERS_PULL=false` en `config/overleaf.rc`. Al iniciar tu instancia de Overleaf Pro con el `bin/up` comando, Toolkit descargará automáticamente todas las imágenes enumeradas en `ALL_TEX_LIVE_DOCKER_IMAGES`. Aquí tienes un ejemplo en el que usamos por defecto TeX Live 2025 para los nuevos proyectos y mantenemos TeX Live 2024 para los proyectos existentes. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2025.1, ghcr.io/ayaka-notes/texlive-full:2024.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2025, Texlive 2024 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2025.1 ``` {% endcode %} {% hint style="danger" %} Se recomienda encarecidamente establecer **al menos 2 imágenes texlive-full**. Para una explicación detallada, consulta [#known-issues](#known-issues "mention") {% endhint %} ### Imágenes de TeX Live disponibles Estas son una serie de imágenes de TeX Live especialmente optimizadas para Overleaf; también se pueden añadir a `TEX_LIVE_DOCKER_IMAGE` y `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (también `latest` etiqueta) * `ghcr.io/ayaka-notes/texlive-full:2024.1` * `ghcr.io/ayaka-notes/texlive-full:2023.1` * `ghcr.io/ayaka-notes/texlive-full:2022.1` * `ghcr.io/ayaka-notes/texlive-full:2021.1` * `ghcr.io/ayaka-notes/texlive-full:2020.1` {% hint style="warning" %} Existe un esquema estricto sobre cómo deben **deben** etiquetarse (se aplica la siguiente expresión regular `^[0-9]+.[0-9]+`, donde el primer número determina el año de TeX Live y el segundo la versión del parche). {% endhint %} ### ¿Puedo usar otro registro de imágenes? > Algunas personas podrían preguntarse si puedo reemplazar `ghcr.io` por otro sitio espejo, o cambiar texlive por otra imagen de Docker Hub? No, no lo recomendamos porque la configuración es relativamente complicada. Si estás descargando desde un sitio espejo, puedes renombrar tu imagen a `ghcr.io/ayaka-notes/texlive-full`. Pero, si realmente quieres usar tu propio registro de imágenes, añade: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Luego, debes asegurarte de que todas las imágenes de texlive estén en `your-repo`, como * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Para información detallada, lee el código fuente a continuación para entender cómo analizamos tu variable de entorno: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Establecer la imagen raíz predeterminada si no se proporciona let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Exportar imageRoot a Settings Settings.imageRoot = imageRootPath // allowedImageNames debería ser: // [ // { imageName: "texlive-2023:latest", imageDesc: "TeX Live 2023" }, // { imageName: "texlive-2022:latest", imageDesc: "TeX Live 2022" }, // ] Settings.allowedImageNames = parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGES) .map((texImage, index) => ({ imageName: texImage.split("/")[texImage.split("/").length - 1], imageDesc: parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGE_NAMES)[index] || texImage.split(':')[1], })) // Al final, imageName se combinará con imageRoot para formar la ruta completa de la imagen // El nombre completo será algo como: ghcr.io/ayaka-notes/texlive-2023:latest // Establecer el nombre de imagen predeterminado si no se proporciona if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Exportar currentImageName a Settings // Este es el nombre de imagen de los proyectos recién creados Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Problemas conocidos > Usando `6.0.1-ext-v3.3`, tengo esta configuración en `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Esto funciona bien con `texlive/texlive:latest-full`. Sin embargo, descargué otra imagen de texlive `danteev/texlive:2025-10-15` y cambié ambas variables al nuevo nombre de imagen, pero no funciona: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > En los registros, veo lo siguiente: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(HTTP code 404) no such container - No such image: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP code 404) no such container - No such image: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > Parece que la configuración actualizada en `variables.env` no está surtiendo efecto. La compilación sigue intentando ejecutar la `texlive/texlive:latest-full` imagen, no la nueva imagen. > > Intenté reiniciar, eliminar los contenedores y volver a ejecutar, pero sigue siendo el mismo problema. > > ¿Alguna solución? Debido a algunas limitaciones técnicas, si solo configuras una única imagen Docker de TeX Live, como `texlive-fullA:latest` ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Y después de ejecutar tu instancia de Overleaf durante un tiempo, es posible que quieras modificar la imagen de TeX Live a `texlive-fullB:latest`. Entonces verás que tus usuarios no pueden compilar todos los proyectos. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Esto se debe a que el nombre de la imagen TeXLive-Full (para compilación en sandbox) en cada proyecto se conserva en la base de datos. *Solo cuando el usuario cambie la versión TeXLive de su proyecto, por ejemplo, de 2024 a 2025, se cambiará el nombre de la imagen en la base de datos*. Cuando CLSI compila un proyecto, usa el nombre de la imagen del contenedor que encuentra en la base de datos para compilar directamente el proyecto. Si solo proporcionas una imagen Docker, los usuarios no podrán modificar la imagen usada para compilar el proyecto. En este caso, necesitas escribir un script para **modificar manualmente** la imagen de TeXLive de todos los proyectos de usuarios en mongoDB. ### Depurar Ejecuta el siguiente comando para comprobar el registro de clsi desde Toolkit: {% code overflow="wrap" %} ```bash bin/logs clsi ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/es/configuracion/overleaf-toolkit/compilaciones-en-entorno-aislado.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.