> ## 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.

# Pricing

> What floo meters, what a credit is, and how to cap spend.

You pay for what your app uses. There is no per-seat charge on usage and no
charge for idle apps that have scaled to zero.

## What gets metered

| Resource      | Metered by                                  |
| ------------- | ------------------------------------------- |
| CPU           | per vCPU-second, for every running instance |
| Memory        | per GiB-second, for every running instance  |
| Managed Redis | provider usage, passed through at cost      |

Managed Postgres, Storage (stored data and operations), bandwidth and egress,
and builds are included at no charge today. They do not appear on your usage
ledger.

Exact unit rates are published at
[getfloo.com/pricing](https://getfloo.com/pricing), effective-dated so past
invoices stay reproducible.

**One floo credit is \$1 of metered usage.**

## Plans

| Plan          | Cost                  | Includes                                        |
| ------------- | --------------------- | ----------------------------------------------- |
| Pay as you go | No monthly commitment | Payment method required, usage billed monthly   |
| Team          | \$250/month           | 250 floo credits each month, org governance     |
| Enterprise    | Custom                | Contract pricing with committed-spend discounts |

Every plan can run every primitive: web services, workers, cron, managed
Postgres, Redis, and Storage. Plans gate how much you can spend and who can
administer it, never what you can build.

## Spend caps

Set a monthly cap, in dollars, so an agent cannot run up a bill. The cap is
org-wide, not per app. `0` turns budget protection off.

```bash theme={null}
floo billing spend-cap set 100
floo billing usage --json
```

A cap comes with a policy that decides what happens at 100%:

| Policy             | At the cap                                                                                                      |
| ------------------ | --------------------------------------------------------------------------------------------------------------- |
| `alerts_only`      | Emails org admins. Nothing is blocked.                                                                          |
| `freeze_new_spend` | Blocks new deploys, preview deploys, and new managed services. Running instances keep serving and keep billing. |
| `hard_stop`        | Blocks new spend and scales running services to zero.                                                           |

The CLI sets only the amount. `floo billing spend-cap set` keeps the policy the
org already has, or selects `freeze_new_spend` when budget protection was off.
Pick a different policy on the dashboard Billing page. Under
`freeze_new_spend` and `hard_stop`, a blocked deploy fails with the typed error
`SPEND_CAP_EXCEEDED`. Warning emails go out at 80% under every policy.

See [Billing and spend caps](/docs/guides/budget-controls) for the full workflow.

## What this costs in practice

Under the `floo-credits-2026-09` rate policy, effective 2026-09-01, CPU is
$0.0468 per vCPU-hour and memory is $0.0216 per GiB-hour. One warm instance for
730 hours:

* Default HTTP shape, 1 vCPU / 512 MiB: 730 × $0.0468 + 730 × 0.5 × $0.0216 = $34.16 + $7.88, about **\$42/month**.
* The same service attached to managed Postgres runs a 0.5 vCPU / 256 MiB
  database proxy next to it, 1.5 vCPU / 768 MiB in total: 730 × 1.5 × $0.0468 + 730 × 0.75 × $0.0216 = $51.25 + $11.83, about **\$63/month**.

Both figures assume the instance stays warm; a service that scales to zero is
billed only for what it serves.

See [Scaling and availability](/docs/guides/scaling) to choose a runtime posture.