この記事は、実空間コンピューティング研究室アドベントカレンダー6日目の記事で書いたものです。 ※我が研究室では毎年アドベントカレンダーとして、何でもいいので記事を書く伝統があります。

さて、今回の記事は備忘録として急いで書いたので内容が雑かもしれませんが、何かの参考になれば幸いです。

※2025年11月末の執筆時点の情報になりますので、Versionのアップデート等によっては内容が変わる可能性があります。

はじめに

今年も早いもので、クリスマス（論文執筆）のシーズンになってきましたね。 論文の執筆環境はローカルに立てるのが良いと古事記にもそう書かれていたので、 筆者はこれまでローカルにTeX Liveを押し込んだ環境を構築して書いていたのですが、研究室はOverleafに慣れているユーザが多そう(当社調べ)なので 有り余るオンプレVMリソースを有効活用するべく、Overleafをセルフホストしてみました。

対象読者

  • この記事はOverleafをセルフホストしてみたい方向けに、書いた記事になります。
    • Overleafの詳しい操作やTeXの詳細については本記事では説明を省略させていただきます。
  • cloudflaredを利用して「特定のドメインで終わるメールアドレス」を持つメンバーのみ、サーバにアクセスできるようにルールを設ける方法が知りたい方

Overleafとは

Overleafは一言で言うと、Webブラウザ上でLaTeXファイルの編集・PDF化ができるサービスです。 インターネット環境があれば、気楽に執筆することができ、他ユーザとの共有機能など大変便利です。

上でご紹介したブラウザ版が一般的かと思われますが、OverleafはありがたいことにOSSのOverleaf Toolkitなるものを提供しています。 今回はこのOverleaf ToolkitをDockerコンテナ上で稼働させ、Cloudflareを用いて研究室内部のユーザのみに公開する方法をご紹介します。 （※ここでは「研究室＝特定のメールアドレス（ドメイン）を持つユーザ」にアクセスを限定することとしますが、他のアクセス制限方法も可能です）

もちろんご自身のノートPCでも立てることが可能なので、ご興味がある方はお試しあれ！

Overleaf(セルフホスト)の特徴

Overleafのセルフホストと一括りに言っても、どうやら世の中には２種類あるようです。「俺」か「俺以外」か。ってことでしょうか(ホストだけに)

冗談はさておき、一つはCE(Community Edition)と名のつく無料版で、もう一つはServer Proという商用版です。 それぞれ使える機能やサポートの手厚さなどに違いがあるようですが、実現したいことがCEで十分なので今回はCEを選択しています。 詳しい違いなどは公式ページをご確認ください。

セルフホスト版メリット

  • インターネットを介さずに編集することも可能
    • 機密性の高い文書の管理などにも適している
    • overleaf.comが落ちた際にも手元で作業できる（今年1月か2月に珍しく鯖落ちしているところを目撃した気が..）
  • 重いor複雑なコンパイルの際も、上限をあまり気にすることなく実行可能

デメリット

  • ファイルのGit管理が困難
  • セキュリティ面やその他運用において工夫や管理作業が必要で、手間がかかる
    • 裏を返せば、カスタマイズしやすいということですね

大まかな流れ

※公式のサイトに構築の流れはある程度記載されており、その箇所についてはそちらを参考に進めるため、一部説明を省略します。 簡単な流れとしては以下の通りです。

  1. Overleaf Toolkitインストール・設定・起動
  2. TeX Liveインストール
  3. cloudflaredのインストール・トンネルの作成と起動
  4. Overleaf Toolkitアクセス確認

用意するもの

  • サーバもしくはVMなどの環境
    • スペックについては後述のセクションを参照
  • Cloudflareアカウントと任意のドメイン
    • 外部からOverleafへ安全に接続するためのトンネルを構築
    • ドメインはどこで取得しても構いませんが、DNSホストゾーンをCloudflareで管理している必要があります。
  • Dockerがインストール済（各環境に合わせて適宜ご用意をお願いします）
    • Overleaf（CE）をコンテナとして立ち上げます

今回使用する環境（スペック）

ここに関しては使用ユーザ数によってかなり変わってくる部分だと思います。 公式が出している要件を参照したり、ユーザの実際の使用量に応じて変えたりするのが良いと思います。 以下は今回使用したVMの情報を参考までに。Overleafを立てるだけだとかなりオーバースペック気味ですが、別の用途でも利用予定なのでこんな感じで

  • OS: Ubuntu 22.04 Server(VM)
  • CPU: 4コア
  • RAM: 8GB
  • ストレージ: 128GB

作業

1. Overleaf Toolkitのインストール

こちらの公式ドキュメントを参考に進めます。

まず最初はOverleaf公式リポジトリからcloneし、そのディレクトリに移動

git clone https://github.com/overleaf/toolkit.git ./overleaf-toolkit
cd ./overleaf-toolkit

このディレクトリ内にこのようなファイルやディレクトリが生成されていればOKです。

bin  CHANGELOG.md  config  data  doc  lib  LICENSE  README.md

続いてOverleafのバージョンや設定などを記述するための各種config(構成)ファイルを作成します。

./overleaf-toolkit直下で以下を実行します。

bin/init

そうすると、以下のようなファイルがconfigディレクトリ配下に生成されます。

overleaf.rc  variables.env  version

それぞれの役割を簡単に説明すると、

  • overleaf.rc → メインの設定ファイル（サーバのポート、MongoやRedisのバージョンなどを指定もこのファイルです）
  • variables.env → dockerコンテナに読み込む環境変数を記述
  • version → Dockerイメージのバージョンを指定します(執筆時点では6.0.1と表示されました)

今回はOverleafにアクセスする際に、ホストマシンが待ち受けるポートを8000にしたいので、overleaf.rcの以下の項目を変更しています ※他のサービスとのポートの競合を避けるためです

OVERLEAF_PORT=8000 #元は80番

保存をしたら、続いてvariables.envの編集を行います。基本はデフォルトのままで進めたいと思います。

まずはOverleafのアプリケーション名です（サービスのヘッダー部分にも表示されます）

OVERLEAF_APP_NAME="xxxxxxxxxx" #任意のインスタンス名

続いてサービスを公開するためのURLです。こちらはCloudflareの設定でも後ほど関係してきます。 特にサービスとして公開を行う予定はない（例：ローカル上で立てて試すだけ）なのであれば、この項目はスキップしても問題ないかと思われます。

OVERLEAF_SITE_URL=http://overleaf.example.com #任意のURL

また、今回は管理者がユーザを直接URLで招待して追加するため設定しないのですが、ユーザの作成時にOverleaf側からメールを送信するには以下の項目の設定が必要です。

# OVERLEAF_EMAIL_SMTP_HOST=smtp.example.com
# OVERLEAF_EMAIL_SMTP_PORT=587
# OVERLEAF_EMAIL_SMTP_SECURE=false
# OVERLEAF_EMAIL_SMTP_USER=
# OVERLEAF_EMAIL_SMTP_PASS=
# OVERLEAF_EMAIL_SMTP_NAME=
# OVERLEAF_EMAIL_SMTP_LOGGER=false
# OVERLEAF_EMAIL_SMTP_TLS_REJECT_UNAUTH=true
# OVERLEAF_EMAIL_SMTP_IGNORE_TLS=false
# OVERLEAF_CUSTOM_EMAIL_FOOTER=This system is run by department x

ここでご紹介した項目は一部ですので、適宜ご自身の環境に合わせてコメントアウト・追記を行ってください。

一連の項目の設定が終わったら、

bin/up

を実行します。そうするとdocker composeが実行され、Overleafインスタンスが起動します。

正しくコンテナが起動しているか確認するべくdocker psなどを実行し、

  • sharelatex/sharelatex:6.0.1
  • mongo:8.0
  • redis:7.4

の３種のコンテナ(任意のバージョン)のStatusがUpになっていれば起動成功です。 ちなみに”sharelatex”とは、少し前にOverleaf社がShareLaTeXというサービスを買収したため、その名残りらしい。

もし正しく起動していない場合は、configの内容で問題が発生しているか、各コンテナ間でバージョンの互換性がない可能性があります(1敗)

そういう時はdocker logs <コンテナID>などで、どこで転けているかを調べるとよいでしょう。

2. TeX Liveインストール

執筆自体はできる状態になりましたが、このままでは執筆時に日本語対応していないためエラーが発生してしまいます。

TeX Liveには数千種類におよぶパッケージが含まれており、執筆する際に必要となるパッケージを各自で選択してインストールする必要があります。

今回はTeX Liveに含まれるパッケージを全てインストールしますが(約9GB)、主要なパッケージのみで良い場合は他のスキームを選択し、必要に応じてパッケージを取捨選択すると良いでしょう(ストレージと時間の節約になります)

まず、以下のコマンドを実行してOverleafコンテナ内に入ります。

bin/shell

以下はコンテナ内のシェルで実行してください。 まず、TeXLiveのパッケージ管理ツールである、tlmgrのバージョンを確認します。

tlmgr --version

versionが表示されればTeX Liveは正しくインストールされています。 ここで、もし見つからない場合は、TeX Liveのインストールがなされていないのでインストールする必要があります。

続いてTeX Liveをアップデートします。

tlmgr update --self

ここで先ほど述べたTeX Liveのフルスキームをインストールします。 scheme-full以外にもさまざまなスキームが存在しますので必要に応じて選択してください。

tlmgr install scheme-full

しばらくインストールが完了するまで気長に待ちます。フルスキームの場合は、待っている間にお好きなアニメを1本以上観れるかもしれません。 ちなみに、筆者は日常系アニメが最近のブームです（聞いてない）

インストール完了後↓

※pLaTeXやupLaTeXを使用する場合は、シンボリックリンクを貼る作業を行います。 筆者はupLaTeX環境を構築したいので、以下のコマンドを実行します。

TeX Liveのバージョンである”2025”の部分と、プラットフォームの”x86_64-linux”は各自の環境に書き換えてください TeX LiveのVersionを確認したい場合は、ls /usr/local/texliveなどを実行すると良いかと思います。

ln -s /usr/local/texlive/2025/bin/x86_64-linux/uplatex /usr/local/bin/uplatex
ln -s /usr/local/texlive/2025/bin/x86_64-linux/upbibtex /usr/local/bin/upbibtex
ln -s /usr/local/texlive/2025/bin/x86_64-linux/mendex /usr/local/bin/mendex

作業が完了したらシェルから抜けます。

exit

この状態をイメージとしてコミットすることで、コンテナを再起動しても状態を保持することができます。

(本来はDockerfileなどであらかじめ作成するのが良いのかもしれませんが、公式がこの方法を推しているようなので大人しく従います。)

docker commit sharelatex sharelatex/sharelatex:6.0.1-with-texlive-full

ここでイメージタグの部分(6.0.1-with-texlive-full)の命名にルールがあり、これ以外だとコンテナの起動時に正しくイメージが読み込まれずにエラーが発生する可能性があるため <元のversion>-with-texlive-fullになるようにします。

docker commitが完了したら config/versionファイルの中身をたった今設定したタグ名に書き換えます。

6.0.1-with-texlive-full

コンテナが起動中の場合は、一旦bin/stopを実行してから

bin/up

を実行してコンテナを起動します。タグを変更して正常に起動できているか確認してください（タグが正しく設定されていない場合はここでエラーを吐いたりするようです。）

3. cloudflaredのインストール・トンネルの作成と起動

先にお伝えしておくと、「cloudflaredを用いてアクセスを制御しない場合」はこの章を飛ばして問題ありません。 Cloudflareのアカウントとドメインを所持している前提でスタートします。

作業に入る前に、簡単にcloudflaredについて説明しておくと、「ローカルにあるサーバを、ポート開放なしで安全にインターネット公開する」ための便利ツールです。 通常、研究室内のサーバを外部（自宅や他のキャンパス）からアクセスできるようにするには、大学のファイアウォールに穴を開ける申請をしたり、ルーターのポートフォワーディング設定をしたりと、面倒な手続きやセキュリティリスクがつきまといます。

しかし、このcloudflared (Cloudflare Tunnel) を使うと、サーバの内側からCloudflareのエッジサーバに向かってトンネルを掘る形になるため、外部からのアクセスを受け入れるためのポート開放（インバウンド通信の許可）が一切不要になります。

今回のOverleaf構築において採用した理由は主に以下の3点です。

  • ポート開放不要: 大学の厳しいネットワークポリシー下でも、アウトバウンド通信（中から外への通信）さえできれば公開可能。

  • SSL/TLS化: 面倒な証明書設定なしで、勝手にHTTPS化してくれる。

  • アクセス制御: Cloudflare Accessと組み合わせることで、「大学のメールアドレス(@univ.ac.jpなど)を持つ人だけアクセス許可」といった認証バリアをWebアプリの手前に設置できる。

本来ならVPNを張ったりBasic認証をかけたりと苦労する部分を、全部Cloudflare側に丸投げできるので、インフラ管理の手間が劇的に減ります。

今回はこちらの公式ガイドを元に進めていきます。

まず、お使いの環境に合わせてcloudflaredをインストールします。 今回はUbuntuなので、以下の通りに進めました。

  1. Cloudflare のパッケージ署名キーを追加
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-public-v2.gpg | sudo tee /usr/share/keyrings/cloudflare-public-v2.gpg >/dev/null
  1. Cloudflare のリポジトリを追加
echo "deb [signed-by=/usr/share/keyrings/cloudflare-public-v2.gpg] https://pkg.cloudflare.com/cloudflared any main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
  1. リポジトリの更新と、cloudflaredのインストール
sudo apt-get update && sudo apt-get install cloudflared

次に以下のコマンドを実行し、Cloudflareアカウントの認証をブラウザ上で行います。

cloudflared tunnel login

認証が完了したら、CLI上でトンネルを作成します。

cloudflared tunnel create <トンネル名>

今作成したトンネルを確認するには、

cloudflared tunnel list

で表示して、確認すると良いでしょう。

続いて、トンネルの設定ファイルを作成します。 ~/.cloudflared/ ディレクトリ内にconfig.ymlというファイルを作成し、以下の内容を記述します。 このファイルは「どのドメインへのアクセスを、ローカルのどのポートに流すか」を定義する重要なレシピです。

tunnel: <先ほど取得したTunnel-UUID>
credentials-file: /root/.cloudflared/<先ほど取得したTunnel-UUID>.json

ingress:
  - hostname: <割り当てたいドメイン (例: overleaf-hoge.example.com)>
    service: http://localhost:8000
  - service: http_status:404

ここでポイントなのが、service の部分です。先ほどoverleaf.rcで設定したポート8000をここで指定します。 <先ほど取得したTunnel-UUID> の部分は、cloudflared tunnel listコマンドで確認できるIDをコピペしてください。

次に、このトンネルとCloudflare上のDNSレコードを紐付けます。 以下のコマンドを実行すると、CloudflareのDNS設定にCNAMEレコードが自動で追加されます。便利ですね〜。

cloudflared tunnel route dns <トンネル名> <割り当てたいドメイン>

ここまで来たら、一度試しにトンネルを起動してみましょう。

cloudflared tunnel run <トンネル名>

この状態で、ブラウザから設定したドメイン（例: overleaf-hoge.example.com）にアクセスしてみてください。 まず、 Overleafのログイン画面（初回は管理者作成画面）が表示されれば、開通成功です！

確認ができたら Ctrl+C で一旦停止し、サーバ再起動時にも自動で立ち上がるようにサービス化しておきます。

cloudflared service install
systemctl start cloudflared
systemctl enable cloudflared

これで、トンネルの開通作業は完了です。

今のままだと、URLを知っている全人類がこのOverleafにアクセスできてしまう状態です。論文の進捗を全世界に公開するのはあまりにまずいので、研究室のメンバーのみアクセスできるように制限をかけましょう。

ここからはコマンドラインではなく、Cloudflare Zero TrustのWebダッシュボード上での操作になります。

  1. Cloudflare Zero Trust のダッシュボードを開き、Access > 「Zero Trustを起動する」ボタンを押す

  2. 左メニューの Accessコントロール > アプリケーション を選択し、「アプリケーションを追加する」をクリック

  3. セルフホスト を選択

  4. Application Configuration 画面で以下を入力 

アプリケーション名: overleaf (なんでもOK)

セッション時間: 24h (再認証までの時間)

「+パブリック ホスト名を追加」 を押して、先ほどOverleaf側で設定したドメインを入力する。 例: overleaf-hoge.example.comにしたい場合は、サブドメインに「overleaf-hoge」と入力し、ドメインは「example.com」を選択する。

  1. 画面下部に移動し、Accessポリシー メニューで「+ 新しいポリシーを作成する」を選択。
  2. ポリシーを設定する 「基本情報」メニューにて以下を設定する。
ポリシー名: (任意の名前)

アクション: Allow

セッション時間：（任意のセッション時間）

「ルールを追加する」メニューにて

セレクター: Emails Ending in（このドメインで終わるメールアドレスを持つ者のみアクセス可能）

値: @univ.ac.jp (研究室が配布するメールアドレスがあれば、ドメインを入力。複数指定可)

※もし、共通のメールアドレスがない場合は、セレクターを「メール」にし、メールアドレスを直接指定することもできます。

  1. これで設定を保存し、ポリシーが作成されたことを確認します。

  2. アプリケーションの作成画面に戻り、Access ポリシーメニューから「既存のポリシーを選択」を押し、適用したいポリシーを選択する。

  3. その他、特にカスタマイズしたい内容がない場合はそのまま「次へ」を押し、最後に「保存」を押します。

これで、アクセスの制限に関する設定は終了です。アプリケーションが追加されていることを確認してください。

改めてブラウザからアクセスすると、Overleafの画面の前にCloudflareの認証画面が表示され、指定したドメインのメールアドレスを入力してOTP（ワンタイムパスワード）を通さないとアクセスできないようになっているかと思います。

4. Overleaf Toolkitアクセス確認

https://<設定したURL>/launchpadにアクセスし、設定したメールアドレス認証が問題なく機能していることを確認しつつ、管理者アカウントの作成を行います。 URLの部分は先ほど設定したカスタムドメインになります（設定していない場合はhttp://localhost:8000/launchpad かと思われます） 管理者は、他の利用者を招待するためのメール送信（別途設定が必要）や招待URLの発行などが可能です。 現状の設定だと、管理者がURLを発行して招待する方式になっているので、メールを送信する場合はメールサーバの設定などを行なってください。

ログインはhttps://<設定したURL>/loginで可能です。

ログインするとこんな感じ。あとはoverleaf.comで利用するときとほぼ同じ操作感で執筆できるかと思います。

個人的に詰まったポイント

最後に今回の構築にあたって、参考になるか分かりませんが詰まったポイントを挙げておきます。

1. Overleaf ToolkitのバージョンとMongo DB対応のバージョンの不一致

おそらく一番最初に詰まった内容ですが、どうやらVMの構築時に設定したプロセッサの命令セットがx86-64-v2になっていた影響で Overleafが指定するMongoDBが使用できないエラーがありました。 Mongo DB v5.0以降では、AVX命令をサポートしているプロセッサでないと動作させることができません。 最初x86-64-v2だと気づかなかったので、Mongo DBのバージョンを落として対応しようと試みるなどしました。 対応する命令セット(x86-64-v3等)に変更という解決には至ったものの、無駄に時間を消費しました(盲点)。

2. TeX Liveをインストールした完了後のdocker commit

上でも述べましたが、docker commitの実行時

docker commit sharelatex sharelatex/sharelatex:6.0.1-with-texlive-full

にイメージタグの命名ルールがどうやらあったらしく、特定の形式(例：6.0.1-with-texlive-full)以外、6.0.1-with-texlive-full-20251124や6.0.1-jpのように設定した場合は、コンテナの起動時に正しくイメージが読み込まれずに以下のようなエラーが発生しました。

$ bin/up

# 出力
ERROR: invalid version '6.0.1-with-texlive-full-20251124'

なので、イメージタグは<version>-with-texlive-fullにする必要がありそうです。 これ以外にどの形式ならイメージタグが有効で、正しく読み込めるのかについては要検証ですね。

そもそもdocker commitではなく、Dockerfileにて定義するのが良いのではないかという気がしますが..

まとめ

今回は、Overleafをセルフホストし、Cloudflareを介してアクセスする方法をご紹介しました。 かなり説明を端折りましたが、Overleaf Toolkitのセルフホストについてなんとなく理解ができていましたら幸いです。

普段overleaf.comを使っていて、サーバが落ちたら作業できない！とりあえず臨時で使い慣れた執筆環境を立てたい！と思っていた方にはぴったりだったのではないでしょうか？

これで１家に１台Overleafサーバが構築される未来が見えますね！

Overleafに限らず、快適に論文を執筆できる環境を模索・構築できるのが一番だと思うので、様々な環境を試してみてください！

明日は、Reimanbowさんによる Arch Linux の布教記事のようです。皆さんも良き Arch ライフを！