> ## Documentation Index > Fetch the complete documentation index at: https://getfloo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Dashboard vs CLI > Understand which surface is the control plane, which is the window, and why the split matters. 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 credential attachments * 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 * managed Postgres, Redis, and Storage resources * custom domains * access grants and team membership * billing * API keys Those are secret, stateful, interactive, or operational by nature. The CLI owns their mutations; generated files such as `.floo/services.lock` make stateful changes reviewable without making git the source of truth for data. ## 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. See the repo-as-control-plane model in more detail. Configure agents to use the CLI and parse the output contract correctly.