Some services spend most of their day waiting. An occasional webhook receiver or a small internal HTTP utility might do useful work for a moment, then sit idle until the next call.
Keeping a container ready is a reasonable default. It is also a choice. In alpha.21, Hakopod adds another one: let a public HTTP service sleep, then wake it when a request arrives.
The request has to wait somewhere
A sleeping service has zero replicas. Its URL still routes through the activation gateway. When traffic arrives, the gateway waits for the container to become ready and forwards the request.
That waiting is part of the caller’s experience. A fast handler does not make a cold image pull or slow startup disappear. Before enabling sleep, think about the timeout of the system calling you. A webhook sender may give up sooner than a person opening a page.
Hakopod lets you configure startup and request deadlines, concurrency limits and an always-warm option. The first version runs zero or one replica. It does not add horizontal request autoscaling or a pool of warm workers.
Start with a disposable HTTP workload
The dashboard includes editable JavaScript and Python function starters. You can also enable Serverless HTTP on an existing HTTP container. Either way, the service still needs correct variables, secret bindings, a listening port and readiness behavior.
Good candidates can finish their work within a request and survive being restarted. Persistent databases and background workers belong in regular services. A process that acknowledges a request and keeps working afterward is a poor fit for a lifecycle governed by HTTP idleness.
The gateway does not retry application requests. That matters for handlers that charge a card or create a record. Your application still needs its own idempotency design for retries made by clients or upstream systems.
Sleeping is different from stopped
Manual Stop is an explicit operator decision. Incoming traffic does not undo it. Initial deployments also need to pass readiness before becoming eligible for sleep, so activation is not a way around a failed rollout.
For existing installations, there is a setup step: enable a reachable private activation gateway. Upgrades preserve current operator settings. Do not assume that installing a newer version has opened the listener or changed ordinary services into sleeping ones.
The feature has been exercised on a two-node development cluster, including concurrent wake-up and manual-stop behavior. That gives us evidence about those paths, not a cold-start latency promise for every image.
Read the serverless guide, then try a small, non-critical HTTP service whose callers can tolerate the wait. Measure its startup before making sleep part of the experience someone depends on.