Skip to main content
Web and API services bill only while they serve requests, and floo keeps them running between visits: every five minutes it sends each service a small request, so an instance never sits idle long enough to stop. This costs about 4 cents a month per service and environment, metered like any other request.

​
When a cold start still happens

A cold start is a request that waits for a new instance to boot. floo-managed Postgres is separate: it pauses after five minutes without queries, even when the service is warm. The first query after a pause waits for it to resume, about 0.5 s after a short pause and up to 2 s after an hour or more.

​
What a cold start costs

On the app floo projects create makes (Next.js with floo-managed Postgres), a cold request after an hour without traffic took 4.4 s: A warm request to the same app took 0.05 to 0.15 s.

​
Make your app start fast

Most of a cold start is your app’s own startup, so this is where it shrinks.
  • Run migrations in migrate_command, not in the start command. floo runs migrate_command once per deploy, before traffic moves. A start command that migrates makes every cold start wait on the database. See Run migrations through migrate_command.
  • Do no network work before the server listens. Connect to databases and other APIs on first use, not at import.
  • Ship only what runs. For Next.js, build with output: "standalone" and copy only .next/standalone and .next/static into the runtime image.
  • Keep floo’s warm-up request cheap. floo’s warm-up and deploy checks send GET /_next/static/__floo_warm with no signed-in user. Next.js answers it as a missing static file without running your code, and other frameworks return their usual 404. If your app does work on every request (auth middleware, a catch-all route), return 404 for this path first.
The app floo projects create makes does the first three, and needs nothing for the fourth. floo marks these requests as lifecycle noise in floo logs.

​
See what your service does

min_instances in floo.app.toml sets it. The app floo projects create makes states min_instances = 0 with a comment, so the choice is visible where you change it. To see what floo applied:
runtime_plan.availability is on_demand for a service with no reserved instances and warm for one with min_instances of 1 or more. Each new instance writes a Starting new instance line to the service’s logs. Reason: AUTOSCALING marks one that a request started; DEPLOYMENT_ROLLOUT marks one a deploy started.

​
Reserve an instance

Set min_instances = 1 on the service in floo.app.toml and push:
A reserved instance is billed for every hour it is ready, idle or not. See Warm baseline cost.