Skip to main content
Two controls in floo.app.toml set how quickly an app responds after a quiet period and how much idle capacity stays running.
  • Web and API services use min_instances and max_instances.
  • Workers use the fixed instances count.
  • Whether CPU is always allocated or request-based follows the service type. The size of the shape is set with cpu and memory; see CPU and memory values.

​
On-demand HTTP

On-demand has the lowest idle cost; the first request after a quiet period pays for it. The service scales from zero to its maximum.
The first request after scale-to-zero may cold-start the container.

​
Warm HTTP

Warm keeps one instance ready, so the baseline does not cold-start, and bills that instance continuously while it idles.
This service keeps one instance ready and scales up to three. New burst capacity may still cold-start. Warm does not mean CPU is always on. Web and API services use request-based CPU, including services attached to floo-managed Postgres. A warm instance is metered for the whole time it is ready, whether or not it is serving requests.

​
Warm baseline cost

A warm instance bills idle CPU and memory for every hour it is ready, about 730 hours a month, and request traffic on top of that baseline is metered as usual. Rates are on getfloo.com/pricing.

​
Workers

Work that runs without an HTTP request belongs in a worker. Workers use a fixed count and always-allocated CPU.
A worker receives no HTTP traffic, and floo preflight and deploys accept a worker without port. floo dev requires port on every service, so declare one if you run the worker locally. Pause a worker with instances = 0:
Workers do not use min_instances. A global [resources] min_instances applies only to web and API services.

​
Defaults and limits

When HTTP min_instances is omitted, floo defaults to 0 on every plan and in every environment, including production: An explicit value wins, subject to plan limits. Set min_instances = 1 or higher to keep an HTTP service warm; each idle instance bills continuously. Omitted HTTP max_instances resolves to 3, and omitted worker instances resolves to 1. Per-service values override delegated floo.service.toml values, which override global [resources] values. An HTTP service kept warm only by the old production default becomes on-demand at its next deploy, promote, restart, or rollback, and may cold-start. floo does not create a new revision only to migrate this default. Set min_instances = 1 before then to keep it warm.

​
Verify the result

Inspect dev intent locally before pushing:
data.runtime_plan separates configured values from locally resolved defaults. An omitted HTTP minimum resolves to 0 with source platform_default in every environment, with no note. Inspect production intent locally too:
For an authenticated existing app, data.plan.runtime_services also reports effective values and their sources after applying plan limits. After deploy, inspect the applied plan for an environment:
The runtime_plan object keeps declared and effective values separate. It also reports the value source, availability posture, CPU allocation mode and reason, and warnings. A value clamped by the plan reports source plan_limit with a warning. A null source means the field does not apply to that service type, such as worker instances on a web service.

Config file spec

See every resource field and precedence rule.

Preflight

Inspect the local runtime plan before you push.