Skip to main content
This section is for people who run Wavefront. For setting up a local or Docker deployment from scratch, start with the repository’s DOCKER_SETUP.md.

​
The services

Your own databases and buckets, connected as datasources, are separate from the ones above.

​
How a background run flows

  1. POST /v3/workflows/<id>/inference on floware saves any input files to object storage, records the execution as pending, and puts a task on the Celery queue in Redis.
  2. The worker picks the task up, marks it in_progress, builds the workflow, and runs it. Workflow steps that call Wavefront (queries, inserts, file downloads, functions) go back to floware’s API.
  3. The worker writes output.json and history.json to object storage and publishes the result on a Redis stream.
  4. floware consumes the stream and updates the execution to completed or failed; clients poll it.
So the worker needs to reach Redis, object storage, the model providers and floware’s API. Most “stuck in pending” problems are one of those missing (see Environment).

​
How the console reaches an app

Each app registered in the console has a public URL (for users) and a private URL (for the console). floconsole forwards console requests to the app’s private URL, signed with a short-lived token made from a secret shared with that app. Console users therefore never need accounts on the apps themselves.

​
Scaling

  • floware is stateless apart from its database and Redis; run several replicas behind a load balancer. FLOWARE_WORKER_COUNT sets processes per replica.
  • Workers scale with background load; each takes tasks from its app’s queue.
  • Model capacity is usually the real limit: provider tokens-per-minute quotas cap how many image-heavy runs can proceed at once.