Would you run RAGFlow's Compose stack as-is in production, and what would you change?

## What "as-is" actually gives you The quickstart stack is deliberately convenient: one command, five services, defaults that work on a laptop. Read as a production topology, it is a single-host, single-replica deployment of four stateful systems with shared-secret defaults committed in a file. Nothing about that is wrong for its purpose — it is wrong as an unexamined production choice, and the interview question is whether you can tell the difference. ## Capacity: the two very different workloads RAGFlow has two load profiles that compete for the same box. **Ingestion** is bursty and CPU-heavy. DeepDoc layout analysis, OCR and table-structure recognition are real computer vision work, and the task executor is where it runs. Embedding adds either more CPU or an external API round trip per chunk. A one-off load of ten thousand PDFs will saturate a machine for hours. **Query** is latency-sensitive and comparatively light: a vector plus keyword search in the document engine, optional reranking, then generation — the last of which is usually dominated by the model provider, not by RAGFlow. Run them together on one host and a bulk ingest becomes a visible query-latency incident. The structural fix is to give ingestion its own capacity — additional executor capacity, ideally on separate hosts, drawing from the same Redis queue — so the two scale independently. Where GPUs are available, a GPU-enabled Compose variant accelerates the parsing/OCR path, which is the single biggest ingestion win. ## Memory and the document engine Elasticsearch is the heaviest container in the stack. `docker/.env` exposes a memory limit for it, and the documented host baseline is roughly 4 CPUs and 16 GB RAM — a floor, not a target. On Linux, `vm.max_map_count` must be at least 262144 or the node will not start. If memory is the binding constraint and the corpus is modest, Infinity is the lighter engine, but that choice must be made before ingestion because switching engines means re-parsing everything. Index growth is driven by chunk count and embedding dimensionality, not by the size of the source PDFs, so capacity planning starts from an estimate of chunks per document times documents, not gigabytes of input. ## Durability: what a backup must cover Four stores, three different answers: - **MySQL** — irreplaceable. Tenants, API keys, datasets and their configuration, one record per document, assistants, agent definitions, session history. Take real backups and test a restore. - **MinIO** — irreplaceable in practice. It holds the originals, which are the only input a re-parse can use. Lose it and the corpus cannot be rebuilt from RAGFlow at all. - **Document engine** — derived. Technically rebuildable by re-parsing, which is true and expensive: for a large corpus that is hours of CPU and, on a hosted embedding provider, a real invoice. Snapshot it anyway, and treat "we can rebuild" as a recovery plan with an RTO measured in hours. - **Redis** — transient. Losing it costs re-queuing in-flight parse jobs. And the operational landmine worth saying out loud: `docker compose down -v` removes the volumes and therefore all of the above. It should never be in a production runbook without a very deliberate reason. ## Security posture `docker/.env` ships with default passwords for MySQL, MinIO, Redis and the search engine; those are laptop conveniences. In a real deployment they come from a secret manager, the data services are not published to any interface beyond the Compose network, and the application is fronted by TLS with authentication that matches your organisation's identity story rather than local accounts alone. Tenant API keys are full-authority credentials: issue a separate one per integration so a leak is revocable without breaking ingestion, and keep them out of browser-side code. ## Availability Single replica means planned downtime for upgrades and unplanned downtime for host failure. Whether that is acceptable is a product question — an internal knowledge assistant can tolerate it; a customer-facing support answerer cannot. The path from tolerable to not-tolerable is where you stop running bundled data services: managed MySQL, managed object storage and a managed search cluster convert your redundancy and backup problem into a vendor's, leaving you to run the stateless-ish application container behind a load balancer. That is a real cost increase and the reason to do it is failover, not fashion. ## Upgrades Image tags in `.env` are the upgrade lever. Pin them — never track a moving tag in production — read the release notes for schema and index changes, snapshot MySQL before an upgrade, and rehearse on a staging stack built from the same Compose files. Any release that changes chunking or embedding behaviour raises the question of whether existing datasets need re-parsing to benefit, which is a scheduling decision, not an automatic one. ## How I would answer in the room "For an internal deployment serving one team, the stock stack plus rotated credentials, TLS, and nightly MySQL and object-store backups is proportionate. For anything customer-facing, I would separate ingestion capacity from query serving, pin image tags, and move the four stateful services to managed equivalents so that a host failure is a page rather than an outage — and I would make the document-engine and embedding-model choices before the first real ingest, because both are effectively one-way doors."