Skip to main content

access mode

Who can reach your app. public is open, password is a shared password, and accounts requires each user to sign in. Set with access_mode in floo.app.toml. See Auth.

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.

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. Without an attachment, credentials are injected into every service.

credit

One floo credit is $1 of metered usage. The Team plan includes 250 credits each month. See 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 and backs up for you: Postgres, Redis, or Storage. Declared with [managed.<name>], provisioned on deploy, and outlives any single deploy. 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, or 1.5 vCPU / 768 MiB with managed Postgres attached. 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. See Billing and spend caps.