Skip to main content
Choose how quickly an app responds after a quiet period, and how much idle capacity you keep running, with two small controls in floo.app.toml.
  • Web and API services use min_instances and max_instances.
  • Workers use the fixed instances count.
  • CPU allocation follows the service type. It is not a separate setting.

​
On-demand HTTP

Use on-demand when the lowest idle cost matters more than the first request after a quiet period. The service can scale from zero to its maximum.
The first request after scale-to-zero may cold-start the container.

​
Warm HTTP

Use warm when avoiding that baseline cold start justifies continuous idle billing for one ready instance.
This service keeps one instance ready and can still scale up to three. The baseline is warm, but 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. The warm baseline has a continuous idle capacity cost, while full CPU is billed when requests run.

​
Warm baseline cost

At the current floo rate card, one warm instance for the default HTTP shape is about 24.64/month∗∗.Aserviceattachedtofloo−managedPostgresusesalargerdefaultshapeandisabout∗∗24.64/month**. A service attached to floo-managed Postgres uses a larger default shape and is about **36.96/month while warm. These estimates use 730 hours of request-based minimum-instance idle pricing. They exclude request activity, plan credits, taxes, and any explicit resource overrides. Request traffic is metered separately under either posture.

​
Workers

Work that must run without an HTTP request belongs in a worker. Workers use a fixed count and always-allocated CPU.
port remains a required service field even though a worker does not receive incoming HTTP traffic. Pause the worker explicitly by setting 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 resolves it from the app plan and environment: An explicit value always wins, subject to plan limits. Set min_instances = 0 to opt a paid production HTTP service into scale-to-zero. Omitted HTTP max_instances resolves to 3, and omitted worker instances resolves to 1. Per-service values override delegated service values, which override global [resources] values. Existing paid production services with an omitted minimum adopt the warm default on their next production deploy, promote, restart, or rollback. floo does not create a new revision only to migrate this default. Commit an explicit min_instances = 0 before that next runtime change if the app should remain on-demand.

​
Verify the result

Before pushing, inspect dev intent locally:
Read data.runtime_plan. It separates configured values from locally resolved defaults and marks values that still require server resolution. For an authenticated existing app, resolve the production default against its actual plan before release:
Read data.plan.runtime_services. Each item contains the server-resolved effective value, its source, and a continuous-billing note when the paid production warm default applies. After deploy, inspect the server-resolved 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, reason, and any plan adjustment. 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.