Skip to main content
floo init creates config files in your repo. This guide explains what they are and when to edit them.

​
What floo init creates

For a single-service project, floo init detects your runtime and creates:
  • floo.app.toml with your app name
  • floo.service.toml with your service type, port, and ingress
You can edit these files by hand before deploying.

​
Single service

Most apps need one floo.service.toml: 
[app]
name = "my-app"

[service]
name = "web"
type = "web"
port = 3000
ingress = "public"

​
Adding managed services

If you need Postgres, Redis, or Storage, use floo.app.toml: 
[app]
name = "my-app"

[postgres]
tier = "basic"

[redis]

[services.web]
type = "web"
path = "."
port = 3000
ingress = "public"
Managed services are declared as top-level sections. They are auto-provisioned on first deploy.

​
Multi-service apps

Define all services in one floo.app.toml: 
[app]
name = "full-stack"

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

[services.api]
type = "api"
path = "./api"
port = 8080
Or delegate to per-service config files. See the Config File Spec for all shapes.

​
Local development

Add dev_command and migrate_command to run services locally with floo dev: 
[app]
name = "full-stack"

[postgres]

[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"
migrate_command runs before the service starts. dev_command is the long-running process. Both run in the service’s path directory with managed service credentials injected.

​
Validate before deploying

floo deploy --dry-run --json
This validates config, resolves the service graph, and shows you what floo will build.

Config File Spec

Full reference for all fields, shapes, and precedence rules.

Managed Services

Add Postgres, Redis, or Storage to your app.