The short answer
Antideploy puts an app to sleep when nobody is using it, on every plan. The next visit wakes it, and that first request waits for the app to start. It took 2.9 to 13.9 seconds in our measurements, depending on the stack. Requests after that answer in a fraction of a second. A sleeping app costs you nothing, and there is no always-on option today.
How long it takes
Measured on 19 September 2026, with three sleeping apps for each stack, from India:
-
Static site. The first request took 2.9 to 5.8 seconds, and the next 0.12 to 0.22.
-
Flask. 3.1 to 5.5 seconds, then 0.15 to 0.42.
-
Streamlit. 4.3 to 5.8 seconds, then 0.14 to 0.15.
-
FastAPI. 5.1 to 9.2 seconds, then 0.14 to 0.25.
-
Express. 5.4 to 10.0 seconds, then 0.12 to 0.15.
-
Vite single-page app. 6.3 to 6.6 seconds, then 0.16.
-
Next.js. 8.6 to 13.9 seconds, then 0.15 to 0.44, and one app took 7.3 seconds.
Why it sleeps
A sleeping app stops its process, which costs nothing. The next request starts it again. The database sleeps too: an idle database suspends and wakes on the next query, so the first request after a quiet spell is slower than the rest.
What helps
- A lighter framework starts faster than a heavier one
- Do less work when the app starts: load big data on first use, and avoid long start-up code
- A page that does not need a server, such as a static site, wakes faster than a server app
- Show a loading state in your frontend, so a slow first request does not look broken
What does not exist yet
There is no always-on option today, and Antideploy does not offer a way to keep an app awake. A scheduled job calls your app on a schedule and wakes it, but it runs at most every five minutes and is meant for work, not for keeping the app warm. If your app must answer instantly at any hour, use a platform that offers always-on instances.