> ## Documentation Index
> Fetch the complete documentation index at: https://getfloo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Scaling and Availability

> Choose an on-demand, warm, fixed, or paused runtime posture in floo.app.toml.

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.

```toml theme={null}
[services.web]
type = "web"
path = "."
port = 3000
min_instances = 0
max_instances = 3
```

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.

```toml theme={null}
[services.web]
type = "web"
path = "."
port = 3000
min_instances = 1
max_instances = 3
```

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**. A service attached to floo-managed Postgres uses a
larger default shape and is about **$36.96/month** while warm.

| Default shape                                  | Estimated GCP cost | Estimated floo metered cost |
| ---------------------------------------------- | -----------------: | --------------------------: |
| HTTP, 1 vCPU / 512 MiB                         |       \$9.86/month |               \$24.64/month |
| HTTP with managed Postgres, 1.5 vCPU / 768 MiB |      \$14.79/month |               \$36.96/month |

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.

```toml theme={null}
[services.worker]
type = "worker"
path = "."
port = 3000
command = "bundle exec sidekiq"
instances = 1
```

`port` remains a required service field even though a worker does not receive
incoming HTTP traffic.

Pause the worker explicitly by setting `instances = 0`:

```toml theme={null}
[services.worker]
type = "worker"
path = "."
port = 3000
command = "bundle exec sidekiq"
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:

| Context                           |        Default | Result           |
| --------------------------------- | -------------: | ---------------- |
| Paid plan, production, web or API |            `1` | Warm             |
| Free plan                         |            `0` | On-demand        |
| Dev or preview                    |            `0` | On-demand        |
| Worker                            | not applicable | Uses `instances` |

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:

```bash theme={null}
floo preflight --json
```

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:

```bash theme={null}
floo preflight --env prod --json
```

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:

```bash theme={null}
floo services show web --app my-app --env dev --json
floo services show web --app my-app --env prod --json
```

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.

<CardGroup cols={2}>
  <Card title="Config File Spec" href="/docs/reference/config-spec">
    See every resource field and precedence rule.
  </Card>

  <Card title="Preflight" href="/docs/cli/preflight">
    Inspect the local runtime plan before you push.
  </Card>
</CardGroup>