services - floo

floo services is the canonical surface for managed services (Postgres, Redis, Storage) and the place to inspect any service, managed or application, running in your app. Postgres and Storage hold persistent state. Managed Redis is cache-only: treat its contents as disposable. floo makes no backup, restore, or durability guarantee for it; keep authoritative data in Postgres. The default authoring surface is a [managed.<name>] block in floo.app.toml; a deploy creates declared resources that are missing. floo services add is the operational provisioning lane for an app that already exists. Removing a previously deployed declaration is tier-3. The shared default retains the resource without review or a schedule. An explicit approval policy requires review; an approved Redis/Storage removal schedules a rescindable teardown without deleting data. floo services remove remains the explicit, confirmed terminal deletion executor.

The legacy [postgres], [redis], [storage] sections in floo.app.toml still auto-provision on first deploy during the deprecation window and emit a warning. Use floo services add for each legacy service type; an existing resource is reported as already provisioned. Replace the legacy sections with [managed.<name>] declarations. See Managed Services for the full transition story.

list

List all services for an app, both application services (web, api, worker) and managed services (postgres, redis, storage). The URL column is the reachable address of each service in the environment you asked for: 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>-<env>-<service>.on.getfloo.com); 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.on.getfloo.com",
        "cloud_run_url": "https://my-app-web-abc123.run.app",
        "cpu": "2",
        "memory": "1Gi",
        "max_instances": 3,
        "min_instances": 1,
        "instances": null,
        "runtime_plan": {
          "environment": "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"]
      }
    ]
  }
}

Application-service resource fields preserve the declared values returned by the platform API. A null value means that field was not explicitly configured. runtime_plan separately 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 details for one service. Branches automatically: managed services return status and injected env-var keys; application services return port, URL, ingress, and configured CPU, memory, scaling, and request-body limits. You don’t need to know which type a name maps to.

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
`--env ENV`	Environment to query: `dev` or `prod` (default: `dev`)

Connection credentials are never returned by show in plaintext. Use floo env list for masked verification. Secret-shaped values require the global --reveal-secrets flag with floo env get; use it only when you control the output destination. For application services, human output separates configured resources from the effective runtime plan. JSON keeps the same distinction in the top-level resource fields and runtime_plan. See Scaling and Availability.

add

Provision a managed service or re-record a legacy declaration. If the create endpoint returns a MANAGED_SERVICE_ALREADY_EXISTS 409 for (app, type, name), add resolves the existing row and reports it 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
`--tier TIER`	Deprecated. Accepted for backwards compatibility but ignored. Every managed Postgres service ships with the same defaults: 25 connections, 60s statement timeout, and 16 MB `work_mem`. For sustained higher concurrency, email team@getfloo.com for a dedicated instance.	`basic`
`--name NAME`	Logical name for this service row (lowercase, alphanumeric + underscores). Useful when you want 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 Postgres schema and role on the shared instance, a Redis database, or a storage bucket).
Synthesizes the corresponding env var(s). Postgres gets DATABASE_URL + PG*, Redis gets REDIS_URL, Storage gets STORAGE_BUCKET + STORAGE_URL, and injects them into your app’s environment scope.

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, both dev and prod credentials are provisioned up front. Promote does not need to re-provision. Preview environments use separate preview-owned managed resources. For managed Postgres, inspect or reset those preview database branches with floo db branches.

remove

Permanently destroy a managed service and its data. This is a tier-3 destructive operation: it drops the Postgres schemas, deletes the Redis databases, or deletes the storage buckets for the service.

# 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 because 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 terminal path that destroys managed-service data. Deploy never performs that deletion. Removing or disabling a modern [managed.<name>] declaration produces a tier-3 to_deprovision proposal. By default, the resource keeps working without review or a schedule. An explicit policy requires review; approval schedules a rescindable teardown for Redis and Storage. Postgres receives 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 that was 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)
`INVALID_TIER`	Tier value is not `basic`, `standard`, or `performance`

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 migrate the managed Postgres database directly.
Preview Environments, preview database branches and supported data modes.
Scaling and Availability - choose and verify HTTP and worker runtime posture.

​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