Skip to main content

​
access mode

Who can reach your app. public is open and accounts requires each user to sign in. Set with access_mode in floo.app.toml. Routes also accept api_key for program access. See Auth and App API keys.

​
agent event

A failed deploy or a runtime error that repeats past its threshold. floo bundles the context and POSTs a signed event to your webhook. Read them with floo events list. See Agent webhooks.

​
agent surfaces

The two equal ways an agent drives floo: the floo CLI, where every command supports --json, or the HTTP API at https://api.getfloo.com/v1, starting from agents.md with every operation in openapi.json. Both sign in through the same device flow; the CLI runs it with floo auth login.

​
app

One deployable unit: a repo, a floo.app.toml, and the services it declares. Apps have a dev and a prod environment.

​
attachment

The declaration that a service receives a managed service’s credentials, written as env.managed on that service. When no service declares one, credentials are injected into every service; once any service does, services without one receive none.

​
credit

The unit floo bills metered usage in. Plans, rates, and included credits are on getfloo.com/pricing.

​
deploy

One run of the pipeline for one environment: build the commit’s image, run migrate_command, roll the new revision out, and shift traffic to it. Every push to the connected branch creates a deploy to dev; floo deploys list shows them, and any earlier one is a rollback target. A release is a deploy to prod; see release.

​
edge

The policy layer that runs before traffic reaches your container: route matching, managed auth, and access mode. Inspect it with floo edge routes list.

​
environment

dev or prod. Every push deploys to dev. Prod is published by promoting a release. Managed data is isolated between them.

​
floo.app.toml

The repo-backed declaration of your app: services, routes, workers, cron, and managed-service intent. It is committed to git, so every change is reviewable in a pull request. See Config file spec.

​
floo.service.toml

An optional per-service config file for the delegated layout, where each service’s settings live beside its code instead of inline in floo.app.toml. A service is inline or delegated, never both. See Config file spec.

​
gateway

floo’s inbound proxy, and the only public path to your container. Your app trusts the identity headers it sets. See Networking and egress.

​
managed service

A stateful primitive floo runs for you: Postgres, Redis, or Storage. Declared with [managed.<name>], provisioned on deploy, and outlives any single deploy. Redis is cache-only and has no backup. See Managed services.

​
org

The organization that owns apps, members, and billing. Members hold an admin, member, or viewer role, and the spend cap is set per org. See Team and access control.

​
preflight

Local validation of floo.app.toml and your source. Runs without an account and without deploying. floo preflight.

​
preview environment

A branch-scoped, production-shaped sandbox created for a pull request, with its own isolated managed resources. Torn down when the pull request closes. See Preview environments.

​
promote

Publish a dev-validated release to prod. floo releases promote. Promote reuses the images that passed dev, or rebuilds them from the same commit with prod’s build-time env vars when prod has any NEXT_PUBLIC_, VITE_, or REACT_APP_ variable.

​
release

The prod deploy that a promote creates from the live dev deploy, recorded with a tag, the commit, who promoted it, and the image digest, plus a GitHub release when the repo is connected. floo releases list shows them. See Releases and rollbacks.

​
service

A process floo runs from your repo. A web service takes inbound traffic, a worker runs background work with no inbound traffic, and cron jobs run on a schedule.

​
shape

The CPU and memory an instance of a service runs with. The default HTTP shape is 1 vCPU / 512 MiB. Override it with cpu and memory in [resources] or on a service. See Scaling and availability.

​
spend cap

An org-wide dollar limit on metered usage. What happens at the cap depends on the org’s policy: alerts_only emails admins and blocks nothing, freeze_new_spend blocks new deploys and managed services, and hard_stop also scales running services to zero. Set the amount with floo billing spend-cap set and the policy on the dashboard Billing page. Prepaid paygo always requires a positive hard_stop limit and a funded balance. See Billing and spend caps.