floo init creates files in your repo, those files become the source of truth for app shape, and the dashboard reflects their live effect instead of mutating them.
This page is the common patterns. Config file spec is
the complete field reference, and Git as source of truth
is the control-plane model behind both.
What floo init creates
For a single-service project, floo init detects your runtime and writes a single floo.app.toml with the service declared inline. A Dockerfile is scaffolded too when one isn’t already present.
You can edit floo.app.toml by hand before deploying.
Single service
Most apps need onefloo.app.toml with an inline service:
Adding managed services
If you need Postgres, Redis, or Storage, declare it infloo.app.toml:
DATABASE_URL plus PG*; named resources yield suffixed keys such as REDIS_URL_CACHE and STORAGE_BUCKET_UPLOADS. Removing a deployed declaration is a tier-3 proposal. The default retains the resource without review or a teardown schedule; explicit approval policies require review. Provider deletion remains a separate action.
Multi-service apps
Define all services in onefloo.app.toml:
Local development
Adddev_command and migrate_command to run services locally with floo dev:
migrate_command runs before the service starts. dev_command is the long-running process. Both run in the service’s path directory. The managed attachment controls which services receive declared managed credentials.
Validate before deploying
Config as code
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.