Skip to main content
Floo is config-as-code by design. floo.app.toml is the source of truth for app configuration. This is not just a preference. It is what makes agent-native deployment workable. Agents need a deterministic, reviewable file that describes desired state.

​
What lives in config

Use repo-backed config for app shape:
  • app and service definitions
  • routing
  • ports and ingress
  • managed service declarations
  • build settings
  • service paths
  • migrate and dev commands
Example: 
[app]
name = "my-app"

[postgres]
tier = "basic"

[services.web]
type = "web"
path = "."
port = 3000
ingress = "public"

​
What stays outside config

Some state is intentionally managed outside the repo:
  • env vars and secrets
  • custom domains
  • access grants and team membership
  • billing
  • API keys
  • destructive actions like app deletion
These either should not be committed to git or depend on live, interactive workflows.

​
Why this matters for agents

When config lives in the repo:
  • agents can read and edit it directly
  • changes are reviewable in pull requests
  • the deploy surface is deterministic
  • there is no second config system to reverse-engineer
If the dashboard could mutate repo-backed config independently, the agent would no longer know which state was real.

​
The dashboard is a window

The dashboard is for visibility into the live system. It shows releases, logs, settings, team state, and usage. It does not become a competing source of truth for app shape that already lives in floo.app.toml.
  1. Write or update config in the repo.
  2. Review it in git.
  3. Connect GitHub if needed.
  4. Push changes and watch the deploy.
floo init my-app
floo preflight --json
floo apps github connect owner/repo
git push origin main

Configuration

Learn the file shapes and common config patterns.

Dashboard vs CLI

See how the read/write split works in practice.