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

# Configuring an app

> The floo.app.toml patterns you reach for most, from a single service to multi-service with managed credentials.

`floo.app.toml` in your repo is the source of truth for app shape. The dashboard
shows its live effect and never edits it. Every field is in the
[config file spec](/docs/reference/config-spec); the control-plane model is
[Git as source of truth](/docs/guides/config-as-code).

## What `floo init` creates

For a single-service project, `floo init` detects your runtime and writes one `floo.app.toml` with the service declared inline, plus a `Dockerfile` when none exists. Edit either by hand before deploying.

## Single service

One `floo.app.toml` with an inline service:

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

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

## Adding managed services

Declare Postgres, Redis, or Storage in `floo.app.toml`:

```toml theme={null}
[managed.default]
type = "postgres"

[managed.cache]
type = "redis"

[managed.uploads]
type = "storage"
```

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 tier-3 proposal. By default the resource is retained, with no review and no teardown schedule; an explicit approval policy requires review. Deleting the resource is always a separate action.

## Multi-service apps

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

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

[managed.default]
type = "postgres"

[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 every shape and field.

## Local development

`floo dev` runs each service that declares a `dev_command`:

```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"]
```

`floo dev` runs `migrate_command` first, then `dev_command` as the long-running process, both in the service's `path` directory. The `managed` attachment controls which services receive managed credentials.

## Validate before deploying

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

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

<CardGroup cols={3}>
  <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>

  <Card title="Scaling and availability" href="/docs/guides/scaling">
    Choose on-demand, warm, running-worker, or paused-worker behavior.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.