Skip to main content
floo is config-as-code. 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 one floo.app.toml with an inline service:

​
Adding managed services

If you need Postgres, Redis, or Storage, declare it 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 is a reviewed tier-3 proposal, not permission for an automated data deletion.

​
Multi-service apps

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

​
Local development

Add dev_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

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

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.