網站的後台配置除了使用雲端服務的虛擬機器外，我們還可以選擇所謂「無侍服器架構（severless architecture)」，典型例子有和AWS Lambda，或GCP Cloud Functions 或 Cloud Run。
使用這種方法，必先將網站的API 路由打包成單獨的函數包，配置 API Gateway（AWS）或 Cloud Endpoints（GCP）以將傳入的 HTTP 請求路由到正確的函數，並設定觸發器以告知雲端提供者何時呼叫每個函數。
當中的運作是這樣的：當HTTP 請求到達雲端提供者的基礎架構（透過 API 閘道、負載平衡器或類似入口點），提供者檢查是否已有可處理此請求的「熱容器」。如果沒有，它會啟動一個新的執行環境，載入網站的函數程式碼，初始化執行階段環境，如Node.js，然後使用傳入的請求資料執行已設定的函數，函數運行後會產生回應，並將該回應傳回客戶端。
這裡的「容器」指的是一個輕量級的、隔離的環境——並非完整的虛擬機，而是更接近 Docker 容器，它只包含執行網站程式碼所需的作業系統和執行時間環境。雲端供應商負責維護這些容器的池，並可以根據需求快速建立或銷毀它們。
函數執行完畢後，容器不會立即消失，為了應對可能到來的下一個請求，服務提供者會將容器保留一小段時間（通常為幾分鐘），是為「熱容器」。如果這容器處於「熱」狀態時收到新請求，它會跳過初始化步驟，直接執行您的程式碼—這樣速度更快。但如果容器空閒時間過長，服務提供者會將其終止以釋放資源。下一個請求會觸發另一個冷容噐啟動，這又會重新產生所有初始化開銷。
無伺服器架構能自動擴展，如果同時有上百個請求到達，服務提供者只需並行啟動一百個容器即可，我們無需預測流量或預先配置容量。當流量下降時，這些容器會逐步終止，我們無需再為其付費。
這種模式的缺點在於控制權，我們無法輕鬆安裝自訂系統程式庫，長時間運行的進程無法正常運作，並且會受到執行時間限制（通常為幾秒鐘到幾分鐘，具體取決於服務提供者），但對於 API 端點等請求-回應模式，這種模型非常適用。
