Dashboard vs CLI

Floo is intentionally split into two surfaces:

• the CLI is the control plane
• the dashboard is the window into live state

This keeps the product usable for humans, agents, and teams without creating configuration drift.

​

Use the CLI and repo for app shape

Use repo-backed config and the CLI for things that define what the app is:

• app and service definitions
• routing
• build and runtime settings
• managed service declarations
• deploy initiation and rollout observation

That keeps desired state reviewable in git and deterministic for agents.

​

Use the dashboard for live operational visibility

Use the dashboard when you want a readable view into the live system:

• releases and deploy history
• logs and usage
• team and access state
• billing and operational settings

The dashboard is especially useful for teammates who are not operating from a shell all day.

​

Why this split matters

If the repo said one thing and the dashboard silently mutated the same config in a different place, agents would no longer know which state was real. Floo avoids that ambiguity by keeping repo-backed config authoritative and using the dashboard as a view into the resulting live system.

​

What stays outside repo-backed config on purpose

Some state is intentionally managed outside the config files:

• env vars and secrets
• custom domains
• access grants and team membership
• billing
• API keys

Those are secret, interactive, or operational by nature.

​

Recommended team model

• agents and power users operate from the CLI
• config changes are reviewed in git
• the rest of the team uses the dashboard for visibility

That gives you one control plane without forcing every stakeholder into the shell.