services - floo

floo services provisions and removes managed services (Postgres, Redis, Storage) and inspects any service in your app, managed or application. Postgres and Storage hold persistent state. Managed Redis is cache-only: floo makes no backup, restore, or durability guarantee for it, so keep authoritative data in Postgres. Declare managed services in a [managed.<name>] block in floo.app.toml; a deploy creates declared resources that are missing. floo services add provisions one on an app that already exists. Removing a declaration never deletes data; see remove.

The legacy [postgres], [redis], [storage] sections in floo.app.toml still auto-provision on first deploy during the deprecation window, with a warning. Run floo services add for each legacy service type (an existing resource is reported as already provisioned), then replace the sections with [managed.<name>] declarations. See Managed Services.

list

List application services (web, api, worker) and managed services (postgres, redis, storage). The URL column is each service’s address in the requested environment: an active custom domain when one is verified, otherwise the floo host. Apps with more than one web or api service get one host per service (<app>-dev-<service>.getfloo.app in dev, <app>-<service>.getfloo.app in prod); single-service apps use the app host. Workers, cron jobs, and internal-ingress services have no URL.

floo services list --app my-app
floo services list --app my-app --env prod

Flags

Flag	Description	Default
`--app APP`	App name or UUID	inferred from config
`--env ENV`	Environment to query: `dev` or `prod`	`dev`

JSON output

{
  "success": true,
  "data": {
    "app_services": [
      {
        "id": "2d2895fc-0fc7-45d7-a18f-7c8795f76835",
        "name": "web",
        "type": "web",
        "port": 3000,
        "status": "running",
        "ingress": "public",
        "url": "https://my-app-dev.getfloo.app",
        "cloud_run_url": "https://my-app-web-abc123.run.app",
        "cpu": "2",
        "memory": "1Gi",
        "max_instances": 3,
        "min_instances": 1,
        "instances": null,
        "runtime_plan": {
          "env": "dev",
          "service_type": "web",
          "availability": "warm",
          "declared": {
            "cpu": "2",
            "memory": "1Gi",
            "min_instances": 1,
            "max_instances": 3,
            "instances": null
          },
          "effective": {
            "cpu": "2",
            "memory": "1Gi",
            "min_instances": 1,
            "max_instances": 3,
            "instances": null
          },
          "sources": {
            "cpu": "configured",
            "memory": "configured",
            "min_instances": "configured",
            "max_instances": "configured",
            "instances": null
          },
          "cpu_allocation": "request_based",
          "cpu_allocation_reason": "http_request_scoped",
          "warnings": []
        },
        "max_request_body_mb": 32
      }
    ],
    "managed_services": [
      {
        "id": "7b0890a0-0f53-46e4-b4e7-04fda184cd66",
        "app_id": "fb6e7446-2d02-4307-b05e-b00120620da5",
        "name": "default",
        "type": "postgres",
        "status": "ready",
        "env_var_keys": ["DATABASE_URL", "PGHOST", "PGPORT", "PGDATABASE", "PGUSER", "PGPASSWORD"]
      }
    ]
  }
}

Top-level resource fields on an application service are the declared values; null means not explicitly configured. runtime_plan reports the effective values and their sources for the selected environment. On every plan and in every environment, including production, an omitted HTTP min_instances appears as effective 0 with source platform_default.

show

Show one service, managed or application; you don’t need to know which a name maps to. Managed services return status and injected env-var keys; application services return port, URL, ingress, and configured CPU, memory, scaling, and request-body limits. Pass the name positionally or with --service, not both.

floo services show web --app my-app
floo services show web --app my-app --env prod --json
floo services show default --app my-app    # the default postgres row

Flags

Flag	Description
`--app APP`	App name or UUID
`--service NAME`	Service name, instead of the positional form
`--env ENV`	Environment to query: `dev` or `prod` (default: `dev`)

show never returns connection credentials. Use floo env list for masked verification. floo env get prints a secret-shaped config value only with the global --reveal-secrets flag; use it only when you control the output destination. For application services, human output separates configured resources from the effective runtime plan, as JSON does with the top-level fields and runtime_plan. See Scaling and Availability.

add

Provision a managed service or re-record a legacy declaration. When (app, type, name) already exists (a MANAGED_SERVICE_ALREADY_EXISTS 409), add reports the existing row as already provisioned, with already_provisioned: true in JSON.

floo services add postgres --app my-app
floo services add redis --app my-app
floo services add storage --app my-app

Arguments

Argument	Description
`<type>`	Service type: `postgres`, `redis`, or `storage`.

Flags

Flag	Description	Default
`--app APP`	App name or UUID	inferred from config
`--name NAME`	Logical name for this service row (lowercase, alphanumeric + underscores), for more than one of the same type.	`default`

What it does

Calls POST /v1/apps/{app_id}/managed-services to provision the underlying resource (a managed Postgres database, a Redis database, or a storage bucket).
Synthesizes the env vars and injects them into your app’s environment scope. Postgres gets DATABASE_URL (plus PG* for the default row), Redis gets REDIS_URL, Storage gets STORAGE_BUCKET + STORAGE_S3_*. A non-default --name suffixes the key, for example REDIS_URL_CACHE.

For multi-service apps, runtime injection is controlled by [services.<name>.env] managed = [...]. Run floo preflight --json to see the exact env_injection_plan. For Postgres, dev and prod credentials are both provisioned up front, so promote does not re-provision. Preview environments use separate preview-owned managed resources. For managed Postgres, inspect those preview database branches with floo previews resources.

remove

Permanently destroy a managed service and its data. It deletes the service’s Postgres database, Redis database, or storage bucket.

# Interactive: type the service name to confirm
floo services remove postgres --app my-app

# Non-interactive (CI, agents): explicit verbose flag
floo services remove postgres --app my-app --yes-i-know-this-destroys-data

Arguments

Argument	Description
`<type>`	Service type: `postgres`, `redis`, or `storage`.

Flags

Flag	Description	Default
`--app APP`	App name or UUID	inferred from config
`--name NAME`	Service row name.	`default`
`--yes-i-know-this-destroys-data`	Skip interactive confirmation. Required in non-interactive contexts. Deliberately verbose: destroying user data must be an explicit decision.	off

There is no --yes or --force. The flag name is not a bug. floo services remove is the only path that destroys managed-service data; deploy never does. Removing or disabling a [managed.<name>] declaration produces a to_deprovision proposal to delete it. By default the resource keeps working, with no review and no schedule. Under an explicit approval policy, review is required, and an approved Redis or Storage removal schedules a teardown, which can still be cancelled, without deleting data; Postgres gets no teardown schedule and keeps working. Renaming a block proposes creation under the new name and removal of the old resource. A CLI-added resource never declared in config appears as to_orphan until explicitly removed.

Errors

Code	Meaning
`NOT_AUTHENTICATED`	Run `floo auth login` first
`SERVICE_NOT_FOUND`	No service with that name exists on the app
`MANAGED_SERVICE_NOT_FOUND`	No managed service of that type/name exists (raised by `remove`)
`MANAGED_SERVICE_ALREADY_EXISTS`	Cannot create a duplicate (never raised by `add`, which is idempotent; surfaces if you call the API directly with conflicting state)

Managed Services, full lifecycle: deprecation, dev/prod isolation per service type.
floo preflight, see which managed services are to_provision, to_retain, to_orphan, or in flight.
floo db, query and inspect the managed Postgres database directly.
Preview Environments, preview database branches and supported data modes.
Scaling and Availability, choose and verify HTTP and worker runtime modes.

​list

​Flags

​JSON output

​show

​Flags

​add

​Arguments

​Flags

​What it does

​remove

​Arguments

​Flags

​Errors

​Related

list

Flags

JSON output

show

Flags

add

Arguments

Flags

What it does

remove

Arguments

Flags

Errors

Related