Skip to main content
floo.app.toml in your repo is the source of truth for app shape. The dashboard shows its live effect and never edits it. Every field is in the config file spec; the control-plane model is How floo works.

​
What floo init creates

For a single-service project, floo init detects your runtime and writes one floo.app.toml with the service declared inline. It does not write a Dockerfile; copy one from Dockerfiles. Edit the config by hand before deploying.

​
Single service

One floo.app.toml with an inline service:

​
Adding managed services

Declare Postgres, Redis, or Storage in floo.app.toml:
The next git-triggered deploy provisions missing declarations and injects their env vars. The default Postgres block yields DATABASE_URL plus PG*; named resources yield suffixed keys such as REDIS_URL_CACHE and STORAGE_BUCKET_UPLOADS. Removing a deployed declaration proposes deleting the resource. By default the resource is retained, with no review and no teardown schedule; an explicit approval policy requires review. Deleting the resource is always a separate action.

​
Multi-service apps

Define all services in one floo.app.toml:
See the config file spec for every shape and field.

​
Local development

floo dev runs every service locally. Each one needs a dev_command:
floo dev runs migrate_command first, then dev_command as the long-running process, both in the service’s path directory. The managed attachment controls which services receive managed credentials.

​
Validate before deploying

Validates config, resolves the service graph, and shows what floo will build and which managed credentials each service receives.

What lives in config

See what belongs in config and what intentionally stays outside it.

Config file spec

Full reference for all fields, shapes, and precedence rules.

Scaling and availability

Choose on-demand, warm, running-worker, or paused-worker behavior.