Serverless HTTP
Let an HTTP function or container sleep between requests, with explicit limits.
Self-hosted alpha.21 adds Serverless HTTP for public HTTP services. Start a JavaScript function or Python function in the new application or Add service form, or enable it for an HTTP container. Review the handler, variables, secrets and deployment plan before running it.
Sleep, wake and stop#
An idle service can stop all its replicas. The activation gateway waits for the container to become ready, then forwards the next request. Configure startup and request deadlines, concurrency limits and an optional always-warm replica. The gateway does not retry application requests.
This version runs zero or one replica. It is not horizontal request autoscaling, a Lambda handler interface or a background/event trigger system. Request bodies are limited to 4 MiB. Use ordinary services for persistent data and background workers.
If you stop a service manually, incoming traffic does not wake it. Initial deployments must pass readiness before becoming eligible to sleep. Failed or changing releases are not activated until deployment or recovery reaches a healthy revision.
Prepare an existing installation#
Fresh native installations configure a private gateway on the management node's internal IPv4 address at port 8082. Upgrades preserve operator settings. Existing installations must explicitly configure a reachable gateway before the option becomes available.
Follow the versioned gateway setup. Keep the listener private to cluster nodes and pods. Do not remove or change it while live services depend on it without reviewing and redeploying those services. One gateway holds the active lease for the installation. Sleeping services need that gateway’s management host to be available.
Inspect a slow wake#
Check Requests, the Runtime card, pod events, image pulls, the listening port and readiness checks. Request duration includes cold-start waiting. A sleeping service has no ready workload endpoint until wake-up finishes.
The feature was exercised on a two-node development K3s cluster. This is not a latency benchmark or a production availability guarantee. Cloud remains in development and needs separate gateway provisioning. Read the full configuration and limits.