サンドボックス化されたコンパイル

Overleaf Pro は、エンタープライズ向けのセキュリティのためにコンパイルを隔離されたサンドボックス環境で実行するオプションを提供します。これは、各プロジェクトをそれぞれ独立したセキュアな Docker 環境で実行することによって実現されます。

セキュリティの向上

多くの LaTeX 文書は PDF コンパイルの過程で任意のシェルコマンドを実行する必要がある、またはその能力を持っているため、Sandboxed Compiles は Server Pro に推奨されるアプローチです。Sandboxed Compiles を使用すると、各コンパイルは他のユーザーやプロジェクトと共有されない機能が制限された別々の Docker コンテナで実行され、ホストネットワークなどの外部リソースへのアクセスはありません。

Sandboxed Compiles を使わずに （または）なしで Overleaf Pro を実行しようとすると、コンパイルはメインの Docker コンテナ内で他の同時コンパイルと共に実行され、ユーザーは LaTeX コンパイル実行時に sharelatex コンテナのリソース（ファイルシステム、ネットワーク、環境変数）に対して読み書きの完全なアクセス権を持ちます。

パッケージ管理が容易に

パッケージを手動でインストールするのを避けるために、Sandboxed Compiles を有効にすることをお勧めします。これは Server Pro の設定可能なオプションで、ユーザーに overleaf.com と同じ TeX Live 環境へのアクセスを、オンプレミスのインストール内で提供します。Sandboxed Compiles で使用される TeX Live イメージには、ギャラリーテンプレートでテストされた最も人気のあるパッケージやフォントが含まれており、オンプレミスプロジェクトとの互換性を最大限に確保します。

Sandboxed Compiles を有効にすると、ユーザーがプロジェクト内で選択できる TeX Live バージョンや、新しいプロジェクトのデフォルト TeX Live イメージバージョンを設定することができます。

Sandboxed Compiles を使わずに Overleaf Pro を実行しようとすると、インスタンスはコンパイルに対して基本的なスキームの TeX Live バージョンを使用することになります。この基本バージョンは軽量で、非常に限られたサブセットの LaTeX パッケージしか含まれておらず、特に事前構築されたテンプレートを使用しようとする際にユーザーにパッケージ不足のエラーを引き起こす可能性が高いです。

Overleaf Pro はオフラインで動作するように設計されているため、overleaf.com のギャラリーテンプレートをオンプレミスインストールに自動的に統合する方法はありません。ただし、テンプレートごとに手動で行うことは可能です。これがどのように機能するかの詳細については、overleaf.com からテンプレートを移行するガイドをご参照ください： overleaf.comからのテンプレートの転送.

Sandboxed Compiles を有効にするには、 sharelatex コンテナがホストマシン上の Docker ソケットにアクセスできる（バインドマウント経由）必要があり、これによりこれらの兄弟コンパイルコンテナを管理できます。

仕組み

Sandboxed Compiles が有効になると、Docker ソケットはホストマシンから sharelatex コンテナにマウントされ、コンテナ内のコンパイラサービスがホスト上に新しい Docker コンテナを作成できるようになります。各プロジェクトでコンパイラを実行するたびに、LaTeX コンパイラサービス（CLSI）は次のことを行います：

• プロジェクトファイルを OVERLEAF_DATA_PATH.

• の内部の場所に書き出します。 マウントされた Docker ソケットを使用して新しい texlive

• コンテナをコンパイル実行のために作成します。 マウントされた Docker ソケットを使用して新しい その OVERLEAF_DATA_PATH.

• コンテナに、プロジェクトデータを マウントされた Docker ソケットを使用して新しい 下の場所から読み込ませます。

コンテナ内でプロジェクトをコンパイルします。

Sandboxed Compiles を有効にする

Toolkit ユーザー向け Sandboxed Compiles（Sibling containers とも呼ばれる）を有効にするには、次の設定オプションを:

overleaf-toolkit/config/overleaf.rc

config/overleaf.rc
に設定します：

SERVER_PRO=true

SIBLING_CONTAINERS_ENABLED=true 5.0.3 Docker Compose ユーザー向け Overleaf CE/Server Pro 以降では、 環境変数は SHARELATEX_*.

から OVERLEAF_* にリブランドされました。 もし 4.x バージョン（またはそれ以前）を使用している場合は、変数がそれに応じたプレフィックスになっていることを確認してください（例：).

SHARELATEX_MONGO_URL
ではなく
    OVERLEAF_MONGO_URL
        #...
        ）。
            version: '2'
            services:
        sharelatex:
            #...
            volumes:
            - /data/overleaf_data:/var/lib/overleaf
            - /var/run/docker.sock:/var/run/docker.sock
            #...
        #...

environment:

DOCKER_RUNNER: "true" SANDBOXED_COMPILES: "true" SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"

TexLive イメージの変更

• 中国本土のユーザーは、ダウンロードを高速化するために ghcr.nju.edu.cn を使用できます。 Overleaf Pro は、Sandboxed Compiles に使用する TeX Live イメージを決定するために 3 つの環境変数を使用します：.

• TEX_LIVE_DOCKER_IMAGE ghcr.nju.edu.cn （必須）、

• Overleaf Pro は、Sandboxed Compiles に使用する TeX Live イメージを決定するために 3 つの環境変数を使用します： ghcr.nju.edu.cn 新しいプロジェクトのコンパイルに使用されるデフォルトの TeX Live イメージ。このイメージは ALL_TEX_LIVE_DOCKER_IMAGES および overleaf-toolkit/config/overleaf.rc.

ALL_TEX_LIVE_DOCKER_IMAGE_NAMES に含まれていなければなりません。 イメージのフレンドリ名のカンマ区切りリストで、フロントエンドのオプションに使用されます。 Overleaf Pro は、Sandboxed Compiles に使用する TeX Live イメージを決定するために 3 つの環境変数を使用します：.

使用する TeX Live イメージのカンマ区切りリスト。Overleaf Toolkit がデプロイに使用される場合、これらのイメージはダウンロードまたは更新されます。ダウンロードをスキップするには、

SIBLING_CONTAINERS_PULL=false

を設定してください。
次の場所に設定します：
Overleaf Pro インスタンスを

bin/up コマンドで起動すると、Toolkit は自動的ににリストされているすべてのイメージをプルします。 サンドボックス化されたコンパイル

ここでは新しいプロジェクトに対して TeX Live 2025 をデフォルトにし、既存プロジェクトには 2024 を維持する例を示します。

config/variables.env 中国本土のユーザーは、ダウンロードを高速化するために ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2025.1, ghcr.io/ayaka-notes/texlive-full:2024.1 Overleaf Pro は、Sandboxed Compiles に使用する TeX Live イメージを決定するために 3 つの環境変数を使用します：:

• ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2025, Texlive 2024 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2025.1 少なくとも 2 つの texlive-full イメージを設定することを強く推奨します。 詳細な理由については、

• 利用可能な TeX Live イメージ

• を参照してください。

• これらは Overleaf 用に特別に最適化された一連の TeX Live イメージで、

• および

• に追加することもできます。

ghcr.io/ayaka-notes/texlive-full:2025.1 （または latest ^[0-9]+.[0-9]+タグ）

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 イメージのタグ付けには厳密なスキーマがあり、.

次のように

SIBLING_CONTAINERS_PULL=false

タグ付けされなければなりません（以下の正規表現が適用され、最初の数字が TeX Live の年、二番目がパッチバージョンを決定します）。

他のイメージレジストリを使用できますか？ 一部の人は、ghcr.io

• を別のミラーサイトに置き換えたり、texlive を Docker Hub の別のイメージに切り替えたりできるか疑問に思うかもしれません。

• いいえ、それはお勧めしません。設定が比較的複雑になるためです。ミラーサイトからダウンロードしている場合は、イメージ名を

ghcr.io/ayaka-notes/texlive-full

にリネームすることができます。

しかし、本当に独自のイメージレジストリを使用したい場合は、次を追加してください：
  IMAGE_ROOT=hub.your.com/your-repo
  その後、texlive のすべてのイメージが
  your-repo
  に存在することを確認する必要があります。

  例：
  // [
  hub.your.com/your-repo/texlive-full:2025.1
  hub.your.com/your-repo/texlive-full:2024.1
  // ]
  詳細な情報については、以下のソースコードを読んで、環境変数をどのように解析しているかを理解してください：
    sandboxed-compiles/index.mjs
      if (process.env.SANDBOXED_COMPILES === 'true') {
      // Set default image root if not provided
        let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes";
    }))
  
  // Export imageRoot to Settings
  Settings.imageRoot = imageRootPath

  // allowedImageNames should be:
  //  { 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], // In the end, imageName will be put together with imageRoot to form the full image path// The full name will be like: ghcr.io/ayaka-notes/texlive-2023:latest // Set default image name if not provided:

if(!process.env.TEX_LIVE_DOCKER_IMAGE) {
process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName

// Export currentImageName to Settings // This is the new created projects' image nameSettings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE 既知の問題 使用しているのは

6.0.1-ext-v3.3
で、次の設定を

variables.env

に入れています： 

TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full // Set default image name if not provided ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full // This is the new created projects' image name これは

texlive/texlive:latest-full

では正常に動作します。しかし別の texlive イメージ

danteev/texlive:2025-10-15 をプルし、これらの変数を新しいイメージ名に変更しましたが、うまく動作しません：

TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15
ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15
ログには次のように表示されます：

{"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 ... どうやら、の設定の更新が反映されていないようです。コンパイルは新しいイメージではなく、依然として

TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15
ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15
ログには次のように表示されます：

イメージの実行を試みています。 再起動やコンテナの削除と再実行を試みましたが、同じ問題が続きました。.

何か解決策はありますか？

技術的な制約により、もし単一の Docker TeXLive イメージ（例えば 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,」のように設定していて、しばらく Overleaf を稼働させた後に TeXLive イメージを例えば、
texlive-fullB:latest に変更した場合、ユーザーがすべてのプロジェクトをコンパイルできなくなることがあります。これは、各プロジェクトで使用される TeXLive-Full イメージ名がデータベースに永続化されるためです。ユーザーがプロジェクトの TeXLive バージョンを例えば 2024 から 2025 に切り替えたときのみ、データベース上のイメージ名が変更されます。CLSI がプロジェクトをコンパイルするときは、データベースに記録されたコンテナイメージ名を使って直接プロジェクトをコンパイルします。もしあなたが一つの Docker イメージしか提供しない場合、ユーザーはプロジェクトのコンパイルに使用されるイメージを変更できません。この場合、mongoDB 内の全ユーザープロジェクトに対して TeXLive イメージを手動で変更するスクリプトを作成する必要があります。