Flowise in Production on PaaS: Queue Mode with Redis, Horizontally Scaled Workers and PostgreSQL Instead of SQLite

A Flowise instance that started as one person's experiment has a way of becoming the thing the whole company talks to. At that point its defaults, a SQLite file and a single process executing every flow inline, become a risk. This post follows a DevOps engineer taking Flowise from pilot to production on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, using Flowise's own queue architecture and the platform's scaling.

The company is an online retailer we will call Sable & Stone, whose Flowise customer-service assistant now handles about 2,000 conversations a day, with spikes when a marketing email goes out. The engineer's brief: no single point of failure in the Flowise tier, no lost conversations under load, and a redeploy that does not drop anyone mid-chat.

Step one: PostgreSQL instead of SQLite

Flowise stores flows, credentials, API keys and chat history in SQLite by default, in a file on the node's persistent storage. That is fine for one process; it is not fine for several, and it is not something a database backup tool understands. The engineer adds a PostgreSQL node to the environment from the topology wizard and sets Flowise's database variables (DATABASE_TYPE=postgres, host, port, name, user, password) on the Flowise layer through the platform's environment variables UI. Flowise creates its schema on restart; the existing flows are exported from the old instance and imported into the new one. The Database Backup/Restore add-on now backs up everything Flowise knows, nightly, and the PostgreSQL SSL/TLS add-on encrypts the connection.

Step two: queue mode

In its default mode a single Flowise process receives a prediction request and executes the whole flow, including the model calls, before responding. Under load, requests queue inside that one process and slow ones block fast ones. Flowise's queue mode separates the roles: the main server accepts requests and places jobs on a queue in Redis; one or more workers take jobs from the queue, execute the flows and return results. The engineer adds a Redis node to the environment, sets MODE=queue and the Redis connection variables on the Flowise layer, and creates a second layer of Flowise containers started with the worker command and the same variables. Both layers talk to the same PostgreSQL and Redis over the internal network.

Step three: scale the workers on the queue's behalf

The workers are the layer that feels load, and they are stateless: a worker holds nothing between jobs. The engineer sets the worker layer to scale in stateless mode from the base container with the same environment variables, and adds horizontal scaling triggers: add a node when the layer's average CPU exceeds 60% for two minutes, up to eight; remove one when below 20% for fifteen minutes, down to two. Worker CPU tracks the number of flows executing (the model call itself is I/O, but document parsing, embeddings for uploads and tool calls are not), so it is a fair proxy for queue depth. When a marketing email lands, the queue grows for a minute, the workers' CPU climbs, the platform adds nodes, and they start pulling jobs from Redis with no configuration beyond the variables they were born with.

Step four: redeploys nobody notices

Flowise releases often, and a redeploy used to mean a minute of errors. Now the main layer has two nodes behind a platform NGINX load balancer, and the engineer redeploys each layer sequentially: the platform takes one node out of the balancer, redeploys it to the new image tag with its variables intact, waits, then does the next. Workers are redeployed the same way; a worker finishes its current job before it stops, and unfinished jobs stay on the Redis queue for another worker. She tests each release on a cloned environment first, which gives her the whole stack, PostgreSQL and Redis included, for the hour the test takes.

Step five: the boring protections

• Process management. The Flowise containers restart automatically on crash; the engineer confirms the restart policy and adds a health check on the main layer's API so the balancer stops sending to an unhealthy node.
• Rate limiting. Flowise's built-in rate limiting per chat flow is enabled on the public-facing assistant so a scraper cannot burn the model budget.
• Load alerts on all four layers at 85% for 10 minutes, forwarded to the operations chat.
• Firewall. Only the NGINX node has a public IP and 443 open; Flowise main, workers, Redis and PostgreSQL are reachable only inside the environment group.
• Secrets. Flowise's credential encryption key and the model API keys are environment variables on the layers, not in flows, and the platform's collaboration roles restrict who can read them.

What production costs

Across a month the four layers average about 45 cloudlets an hour (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU), with the worker layer responsible for most of the variation: two nodes overnight, six for an hour after each campaign. At MassiveGRID's published $0.003372 per cloudlet-hour that is roughly $110 a month before discounts, plus the public IP and the model provider's charges, which remain the larger bill. The engineer's summary to the retailer's CTO: the assistant now has no single point of failure in its own tier, scales itself for campaigns, and costs about what one worker's laptop costs to lease.

Frequently Asked Questions

Does queue mode change how the API is called?

No. Clients call the same prediction endpoint on the main server. The difference is internal: the main server enqueues the job and returns the result when a worker completes it, including for streaming responses, which queue mode supports.

Can the workers run on a GPU server for a self-hosted model?

The workers call the model over the network, so the model can run anywhere: a hosted API, or a self-hosted model on a MassiveGRID GPU dedicated server reached through Flowise's Ollama or OpenAI-compatible node. The workers themselves need CPU and RAM, not GPUs.

How do I migrate an existing SQLite Flowise to this setup?

Export flows, credentials and variables from the existing instance through Flowise's export feature, configure the new instance with the PostgreSQL variables, start it, and import. API keys are re-created. Test on a clone before switching the domain.