硬體需求
在為執行 Overleaf 準備硬體時，主要考量因素是會有多少位同時進行編譯的使用者。 例如，如果您擁有總共 100 位使用者的授權，但預期同時工作的只有約 5 位，那麼最低配置的安裝就已足夠。如果您預期同時工作（並進行編譯）的比例較高，則應考慮準備規格更高的伺服器。最低配置安裝
在約 5 位同時使用者的情況下，基本運作的最低需求為 2 核心與 3GB 記憶體。對於同時使用率較低，或可接受在高負載期間編譯時間較長的較大型群組，這個最低需求也同樣足夠。如果您考慮在小型執行個體中使用以 NFS（Network File System）為基礎的檔案系統，請參閱疑難排解中的相關章節。
擴充
根據經驗法則，為了提供高水準且穩定的服務，每增加 5 到 10 位同時使用者，就應在最低配置之上增加 1 個 CPU 核心與 1GB 記憶體。 這僅應作為參考，因為一般文件的大小（較大的文件會耗用更多編譯資源）、使用者編譯的頻率，以及在高負載期間對較長編譯時間的容忍度等因素，都會影響所需的資源配置。 我們許多客戶希望在整個組織或大型團隊中部署 Server Pro。在這些情況下，我們很難提供具體的設定需求建議，因為使用情境與可用的底層硬體可能差異很大。
超出單一大型伺服器極限的客戶，可以參考 Server Pro 的水平擴充。
儲存空間
在較大型的設定中，我們不建議使用 Network File System（NFS）/Amazon EFS/Amazon EBS 作為專案/歷史記錄的儲存空間，且在水平擴充時明確不支援。 這些檔案系統的行為無法提供 Server Pro 在大規模運作時所需的效能與可靠性。當檔案系統跟不上負載時，應用程式會因過多的阻塞式 IO 操作而停滯。這些停滯可能導致以 Redis 為基礎的鎖定逾時，進而造成專案資料損毀。 我們建議改用相容 S3 的物件儲存。S3 效能緩慢只會影響檔案的上傳/下載，僅會使連到 S3 供應商的開啟連線數增加，不會影響應用程式其餘部分的行為。此外，Server Pro 可以為 S3 請求指定合理的逾時時間，而這在應用程式層級對檔案系統/IO 操作是無法做到的。供您參考，GitLab 在其自行管理的產品中也採取類似立場，不支援 NFS/Amazon EFS。
大型部署的 Nginx 專屬設定
根據預設，Overleaf Server 執行個體將連線數限制為 768。這包括持續性的 Websocket 連線、頂層 HTML 導覽與 ajax 請求。一旦達到上限，編輯器可能無法連線、編輯器頁面可能無法完整載入，且編譯請求可能會失敗。Nginx 會回傳狀態碼 500 的回應，並在sharelatex 容器內的 var/log/nginx/error.log 中記錄 worker_connections are not enough while connecting to upstream。
worker_connections 設定會限制 nginx 每個 worker 可接受的同時連線數。worker 的數量由 worker_processes 設定控制，在我們的 nginx 設定中預設為 4。
與系統的其他部分相比，Nginx 的工作量並不大，因此這些限制可作為一種安全措施，防止過多連線壓垮系統。提早捨棄部分多餘的連線，比拖慢每一個連線更好。
Overleaf Server 執行個體提供以下環境變數，用於調整這些 nginx 設定：
-
NGINX_WORKER_PROCESSES對應worker_processes（預設4） -
NGINX_WORKER_CONNECTIONS對應worker_connections（預設768） -
NGINX_KEEPALIVE_TIMEOUT對應keepalive_timeout（預設65）在sharelatex容器前方執行另一個 proxy（例如用於 TLS 終止）時，Overleaf Server 執行個體中的NGINX_KEEPALIVE_TIMEOUT必須大於前一個 proxy 的設定。例如，在 Docker 主機上另有一個 nginx 程序 nginx-host 時，以下是兩個範例： -
使用預設值
NGINX_KEEPALIVE_TIMEOUT時，在 nginx-host 中使用keepalive_timeout 60s（upstream 中的預設值） -
使用自訂值
NGINX_KEEPALIVE_TIMEOUT=100s時，在 nginx-host 中使用keepalive_timeout 90s（upstream 中的自訂值）