サンドボックス化されたコンパイル
Overleaf Proには、エンタープライズのセキュリティのためにコンパイルを隔離されたサンドボックス環境で実行するオプションが付属しています。これは各プロジェクトをそれぞれ専用の保護されたDocker環境で実行することで実現されます。
セキュリティの向上
Sandboxed Compiles（サンドボックス化されたコンパイル）は、多くのLaTeXドキュメントがPDFコンパイル過程で任意のシェルコマンドを実行する能力を必要としたり持っていたりするため、Server Proに推奨されるアプローチです。Sandboxed Compilesを使用すると、各コンパイルは制限された機能を持つ別個のDockerコンテナ内で実行され、他のユーザーやプロジェクトと共有されず、ホストネットワークなど外部リソースへのアクセスもありません。
Overleaf Proを 使用せずに Sandboxed Compilesを利用しようとすると、コンパイルはメインの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ソケットにアクセスできること（バインドマウント経由）を必要とします。これにより、これらの兄弟コンテナ（sibling compile containers）を管理できます。
仕組み
Sandboxed Compilesが有効な場合、Dockerソケットはホストマシンから sharelatex コンテナへマウントされ、コンテナ内のコンパイラサービスがホスト上に新しいDockerコンテナを作成できるようになります。各プロジェクトでコンパイラが実行される際、LaTeXコンパイラサービス（CLSI）は以下の処理を行います：
プロジェクトファイルを書き出して、
OVERLEAF_DATA_PATH.マウントされたDockerソケットを使って新しい
texliveコンテナをコンパイル実行のために作成します。その
texliveコンテナに、プロジェクトデータをOVERLEAF_DATA_PATH.の下の場所から読み込ませ、
texliveコンテナ内でプロジェクトをコンパイルします。
Toolkitユーザー
サンドボックス化コンパイル（別名「Sibling containers」）を有効にするには、次の設定オプションを overleaf-toolkit/config/overleaf.rcに設定してください。:
Docker-composeユーザー
以下の例では、次の点に注意してください：
Overleafコンテナにマウントされたdockerソケットのボリューム
DOCKER_RUNNERに設定されているtrueSANDBOXED_COMPILESに設定されているtrueSANDBOXED_COMPILES_HOST_DIRに設定されている/data/overleaf_data/data/compiles, コンパイルデータがホスト上に書き出される場所
Overleaf CE/Server Pro以降、 5.0.3 環境変数は SHARELATEX_* から OVERLEAF_*.
へと名称が変更されました。 もしあなたが 4.x バージョン（またはそれ以前）を使用している場合は、変数に適切なプレフィックスが付いていることを確認してください（例： SHARELATEX_MONGO_URL の代わりに)
SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"
TexLiveイメージの変更
以下の環境変数は、サンドボックス化コンパイルで使用するTeX Liveイメージを指定するために使用されます：ALL_TEX_LIVE_DOCKER_IMAGES（必須）
使用するTeX Liveイメージのカンマ区切りリストです。Overleaf Toolkitをデプロイに使用する場合、これらのイメージはダウンロードまたは更新されます。ダウンロードをスキップするには、SIBLING_CONTAINERS_PULL=falseconfig/overleaf.rc.
をALL_TEX_LIVE_DOCKER_IMAGE_NAMES
に設定してください。).
イメージのフレンドリ名のカンマ区切りリストです。省略した場合はバージョン名が使用されます（例：latest-full
以下の環境変数は、サンドボックス化コンパイルで使用するTeX Liveイメージを指定するために使用されます：TEX_LIVE_DOCKER_IMAGE以下の環境変数は、サンドボックス化コンパイルで使用するTeX Liveイメージを指定するために使用されます：新しいプロジェクトのコンパイルに使用されるデフォルトのTeX Liveイメージです。このイメージは
に含まれている必要があります。設定されていない場合、
の最初のイメージがデフォルトイメージとして使用されます。 に設定してください。 ユーザーはプロジェクトメニューでプロジェクトに使用するイメージを選択できます。 ここではデフォルトのTeX LiveイメージがDocker Hubの で、古いプロジェクトには
ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLive 2025, TeXLive 2024 TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full 公式のtexliveイメージ
texlive/texlive:latest-full を使用すると、いくつかの問題が発生する可能性があります。公式texliveイメージに関する3つの主要な問題は、❶ 再コンパイルエラー、❷ glossariesが動作しない、❸ フォントが欠ける、の3点です。したがって、我々は
ayaka-notes/texlive-full を強く推奨します。これにより非常に優れた体験が得られます。少なくとも2つのtexlive-fullイメージを設定することを強く推奨します。 サンドボックス化されたコンパイル
詳細な理由については、以下を参照してください。 環境変数： TEX_COMPILER_EXTRA_FLAGS
は、我々が最適化の多くをTeXLive Full Dockerイメージ内で直接行うため、ayaka-notes/overleaf-proでは現在非推奨となっています。例えば、shell escapeはデフォルトで有効になっています。 環境変数：.
非推奨 コンパイルが専用のコンテナ内で行われる場合、コンパイル中にTeXファイル内部から外部コマンドを実行することを許可するのは比較的安全です。これはminted
環境変数：のようなパッケージで必要とされます。これを目的として、次の環境変数が使用できます：
TeXコンパイラ用の追加フラグのリスト。例：
-shell-escape -file-line-error
推奨TeX Liveイメージ イメージのフレンドリ名のカンマ区切りリストです。省略した場合はバージョン名が使用されます（例： 以下はOverleaf向けに特別に最適化された一連のTeX Liveイメージで、 以下の環境変数は、サンドボックス化コンパイルで使用するTeX Liveイメージを指定するために使用されます：:
およびに追加できます。ghcr.io/ayaka-notes/texlive-full:2025.1（またlatestタグ）ghcr.io/ayaka-notes/texlive-full:2024.1ghcr.io/ayaka-notes/texlive-full:2023.1ghcr.io/ayaka-notes/texlive-full:2022.1
ghcr.io/ayaka-notes/texlive-full:2021.1 ghcr.io/ayaka-notes/texlive-full:2020.1 イメージがどのようにタグ付けされなければならないかについて厳密なスキーマがあります（以下の正規表現が適用されます。最初の数字はTeX Liveの年を、2番目の数字はパッチバージョンを決定します）。 ^[0-9]+.[0-9]+既知の問題
を使用すると、
6.0.1-ext-v3.3
、私はこれらの設定をvariables.envに入れています。ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full:で問題なく動作します。しかし、別のtexliveイメージをプルしました：
TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-fulldanteev/texlive:2025-10-15そしてこれら両方の変数を新しいイメージ名に変更しましたが、動作しません：TEX_LIVE_DOCKER_IMAGE=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 ...
における更新された設定が有効になっていないようです。コンパイルはまだ新しいイメージではなく、
ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-fullイメージの実行を試みています。TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full再起動したり、コンテナを削除して再実行したりしてみましたが、同じ問題のままでした。何か解決策はありますか？
技術的な制限のため、もし単一のDocker TeXLiveイメージ（例えば
texlive-fullA:latest ）のみを設定した場合、
あなたのOverleafインスタンスをしばらく稼働させた後で、TeXLiveイメージを texlive-fullB:latestに変更したくなることがあるでしょう。すると、ユーザーがすべてのプロジェクトをコンパイルできなくなることがあります。
これは、各プロジェクトのサンドボックスコンパイル用TeXLive-Fullイメージの名前がデータベースに永続化されるためです。ユーザーがプロジェクトのTeXLiveバージョンを例えば2024から2025に切り替えた場合、その
イメージ名が変更されます。
CLSIがプロジェクトをコンパイルする際、データベースに保存されているコンテナイメージ名を使用して直接プロジェクトをコンパイルします。 もしあなたが1つのDockerイメージしか提供しない場合、ユーザーはプロジェクトのコンパイルに使用されるイメージを変更できません。この場合、全ユーザープロジェクトのTeXLiveイメージをmongoDB内で 手動で変更するスクリプトを作成する必要があります。
最終更新