> ## 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.

# Configuration

> Understand the floo config files that live in your repo and drive deploy behavior.

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.

For the control-plane model itself, start with [Config as Code](/docs/guides/config-as-code).

## 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:

```toml theme={null}
[app]
name = "my-app"

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

## Adding managed services

If you need Postgres, Redis, or Storage, provision it with the CLI:

```bash theme={null}
floo services add postgres --app my-app
floo services add redis --app my-app
floo services add storage --app my-app
```

Managed-service commands provision durable resources, inject the matching env vars on deploy, and update `.floo/services.lock`. Commit the lock file. Deploy never destroys managed-service data because a config file changed.

## Multi-service apps

Define all services in one `floo.app.toml`:

```toml theme={null}
[app]
name = "full-stack"

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

[services.api]
type = "api"
path = "./api"
port = 8080
```

See the [Config File Spec](/docs/reference/config-spec) for all shapes.

## Local development

Add `dev_command` and `migrate_command` to run services locally with `floo dev`:

```toml theme={null}
[app]
name = "full-stack"

[services.web]
type = "web"
path = "./web"
port = 3000
ingress = "public"
dev_command = "npm run dev"

[services.api]
type = "api"
path = "./api"
port = 8000
ingress = "public"
dev_command = "uv run uvicorn app.main:app --reload --port 8000"
migrate_command = "uv run alembic upgrade head"

[services.api.env]
managed = ["postgres"]
```

`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 credentials from `floo services add`.

## Validate before deploying

```bash theme={null}
floo preflight --json
```

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

<CardGroup cols={2}>
  <Card title="Config as Code" href="/docs/guides/config-as-code">
    See what belongs in config and what intentionally stays outside it.
  </Card>

  <Card title="Config File Spec" href="/docs/reference/config-spec">
    Full reference for all fields, shapes, and precedence rules.
  </Card>
</CardGroup>