App sleep and wake

Kyno puts inactive HTTP apps to sleep so they do not hold memory while nobody is using them. Sleeping is automatic and reversible: the app keeps its URL, configuration, workspace access, image, and persistent data.

The short version

1. Kyno records the time of the latest authenticated request to the app.
2. If no newer request arrives before the plan’s idle timeout, Kyno stops the app’s microVM and marks the app as Sleeping.
3. The next authenticated request to the same URL starts the app again.
4. Once the app is ready, Kyno forwards that original request and resets the idle clock.

Plan	Sleeps after
Free	15 minutes without an authenticated request
Starter	30 minutes without an authenticated request
Team	30 minutes without an authenticated request
Enterprise	30 minutes without an authenticated request

The idle check runs periodically, so an app may sleep shortly after—not at the exact second—the timeout passes. The timeout is assigned when the app is created.

What counts as activity?

An app is active when an authorized workspace member makes a request through its Kyno URL and the request reaches the ready app. Opening a page usually makes several requests for HTML, scripts, styles, data, or images; each authorized request refreshes the activity time.

These do not keep an app awake:

• an anonymous request from someone who is not a workspace member;
• viewing the app’s status or logs in the Kyno dashboard;
• an agent listing apps through MCP;
• Kyno’s internal runtime health checks;
• an open browser tab that is no longer making requests; or
• outbound work performed by the app without a new incoming request.

Authentication is checked before Kyno wakes an app. Internet scanners and non-members therefore cannot consume runtime capacity by repeatedly hitting a private app URL.

What happens while an app sleeps?

Kyno stops the Firecracker microVM, which releases its runtime memory. It does not redeploy, rebuild, or delete the app.

Sleeping preserves:

• the same Kyno URL;
• the application image;
• variables and encrypted secrets;
• workspace membership and app sessions;
• the persistent /data disk and SQLite database; and
• deployment history and logs already recorded by Kyno.

Data outside /data is not persistent across starts, whether the start follows sleep, a manual restart, or host maintenance. See the application contract.

How waking works

When an authorized person visits a sleeping app, Kyno queues one start and waits for it to become ready. Requests arriving during the same wake share that start rather than launching duplicate runtimes.

The gateway waits up to 15 seconds for startup. If startup takes longer, the visitor may briefly see App is not ready with a 503 response. The start continues in the background; wait a few seconds and refresh. A successful request then resets the idle clock.

If the app continues returning 503, ask your agent:

Get this app’s current Kyno status and recent events. Explain why its last start failed before changing anything.

The final process must listen on 0.0.0.0:$PORT and remain running. See Troubleshooting for startup checks.

Sleeping is different from stopping

State	How it happens	Opens automatically on a visit?
Sleeping	Kyno reaches the inactivity timeout	Yes
Stopped	An owner or agent explicitly stops the app	No

A manually stopped app stays stopped until an owner or agent starts it. This is useful when an app should not run or accept traffic at all. Use automatic sleep when the app should remain available on demand.

Automations

Scheduled and webhook automations are one-shot workloads, not sleeping HTTP apps. Their lightweight triggers remain in the Kyno control plane and start the automation only when its schedule or event fires. An idle HTTP app does not need to remain awake for a separate automation to run.