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

# Glossary

> The terms floo uses, defined once.

## 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](/docs/guides/app-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](/docs/guides/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](/docs/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](/docs/reference/config-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](/docs/reference/config-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](/docs/guides/networking).

## 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](/docs/guides/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](/docs/guides/team-access).

## 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](/docs/guides/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](/docs/guides/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](/docs/guides/scaling).

## 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](/docs/guides/budget-controls).