How to Configure Open WebUI File Upload Limits and Fix RAG 413 Errors

Chat Uploads Versus Knowledge Base Collections

Open WebUI separates document handling into two operational contexts: ad-hoc chat attachments and curated Knowledge Base collections. Each pathway enforces distinct boundary rules to balance interactive speed against administrative control.

Chat uploads are designed for immediate conversational context. When a user attaches a file directly to an active prompt, the upload is subject to both RAG_FILE_MAX_SIZE and RAG_FILE_MAX_COUNT. By default, both settings are unconstrained until an administrator assigns explicit numeric caps in the environment configuration or administrative dashboard. If a user attempts to attach more files than the configured limit allows, the frontend blocks the operation before file transmission begins.

Knowledge Base uploads follow a different operational model. Documents added to a Knowledge Base in the Workspace panel still respect the RAG_FILE_MAX_SIZE cap, but they bypass RAG_FILE_MAX_COUNT entirely. This separation allows administrators to ingest hundreds of technical manuals or policy documents into a shared reference library without altering the strict file-count guardrails applied to everyday chat prompts. Furthermore, Knowledge Bases support Full Context Mode, which bypasses vector retrieval and injects complete document texts directly into models with large context windows.

Archive Decompression and Memory Exhaustion Defenses

A common point of confusion occurs when Open WebUI rejects a small file that sits well below all configured size thresholds. This behavior frequently affects Microsoft Word documents (.docx), Excel spreadsheets (.xlsx), PowerPoint decks (.pptx), and digital publications (.epub).

These formats are compressed zip archives. To extract readable text, Open WebUI's ingestion workers must unpack the underlying XML structures into memory. To protect the host operating system against zip bomb attacks and uncontrolled memory exhaustion, Open WebUI inspects the uncompressed payload size during extraction.

If an archived document contains complex styling, embedded media, or repetitive XML tokens that expand to dozens of times the on-disk file size, the backend rejects the file with an explicit decompression threshold error. This is an intentional defense mechanism. Even when RAG_FILE_MAX_SIZE is configured for high capacity, corrupt archives or files with massive expansion ratios are refused before they can consume host memory and crash the Python worker process.

Configuring Nginx Ingress and Timeout Directives

To permit large document uploads through Nginx, locate the configuration file responsible for your Open WebUI virtual host. Add or update the client_max_body_size directive within the server or location block:

server {
    listen 443 ssl http2;
    server_name chat.example.com;
    client_max_body_size 250M;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
    proxy_connect_timeout 60s;
    proxy_request_buffering off;
    proxy_buffering off;
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Disabling proxy_request_buffering allows Nginx to pass incoming data chunks directly to Open WebUI as they arrive, rather than waiting to buffer the entire file on the proxy host's local disk. After modifying the configuration, validate the syntax with nginx -t and reload the service with systemctl reload nginx.

Managing Edge Gateways and Cloudflare Upload Ceilings

If your Open WebUI domain routes through a managed cloud gateway or content delivery network, proxy directives on your local server may still be overridden by edge network rules.

Cloudflare enforces rigid client body limits based on account tiers. Free and Pro tiers enforce a ceiling of 100M per HTTP request, while higher commercial tiers expand this limit. If an administrator configures Open WebUI and Nginx to accept larger documents, Cloudflare will still intercept the request at the edge and return an HTTP 413 error whenever a user uploads a file exceeding the edge ceiling.

Bypassing this edge restriction requires either setting Cloudflare proxy status to DNS-only (gray cloud) for the Open WebUI subdomain, or using an internal network tunnel such as WireGuard or Tailscale to route team traffic directly to your host without traversing public edge proxies.

Setting Environment Variables in Docker Compose

In Docker deployments, environment variables control the baseline ingestion boundaries. Add the following parameters to your docker-compose.yml file:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - WEBUI_SECRET_KEY=replace_with_a_persistent_random_secret
      - RAG_FILE_MAX_SIZE=150
      - RAG_FILE_MAX_COUNT=10
      - FOLDER_MAX_FILE_COUNT=200
      - RAG_ALLOWED_FILE_EXTENSIONS=.pdf,.txt,.docx,.md,.csv,.json
      - RAG_EMBEDDING_TIMEOUT=300
    volumes:
      - open-webui-data:/app/backend/data
    restart: unless-stopped

volumes:
  open-webui-data:

The RAG_FILE_MAX_SIZE variable accepts an integer representing megabytes. When configured with a specific numeric limit, any single document exceeding that value in megabytes is rejected by the FastAPI upload handler with an informative error message before text parsing begins.

The RAG_ALLOWED_FILE_EXTENSIONS variable provides an essential security filter. Restricting uploads to known document extensions prevents users from uploading binary executables or unsupported media that would fail during text extraction.

Updating Document Ingestion Policies in the Admin Panel

Administrators can also modify upload parameters dynamically without restarting Docker containers:

1. Sign in to Open WebUI with an administrator account.
2. Open the user profile menu in the bottom-left corner and select Admin Panel.
3. Navigate to Settings and select the Documents tab.
4. Under the General section, locate Max Upload Size.
5. Enter your desired size threshold in megabytes, or leave the field blank to allow unconstrained uploads.
6. Adjust Max Upload Count to limit how many files a user can attach in one prompt.
7. Click Save in the bottom-right corner to apply the changes.

Open WebUI stores these admin settings in its internal database. When persistent configuration is active, values saved in the web interface take precedence over environment variables defined in your Docker Compose file.

The SQLite Fork Collision in Multi-Worker ChromaDB Deployments

The default vector database in Open WebUI is ChromaDB, which runs embedded inside the application container using a local SQLite persistence layer. This setup works reliably for single-user development, but it introduces an immediate point of failure in multi-worker production deployments.

When administrators configure Open WebUI to use multiple Uvicorn workers (such as setting UVICORN_WORKERS=2 or higher to improve web concurrency), Uvicorn forks multiple worker processes. Because SQLite connections are not fork-safe, each child process inherits an open file handle to the same underlying SQLite database.

When a user uploads a large document that requires hundreds of sequential vector writes, the worker calls the internal save_docs_to_vector_db function. Concurrent writes to the shared SQLite file trigger an immediate database lock conflict. Uvicorn logs report that child processes died instantly without a timeout:

INFO: save_docs_to_vector_db: adding to collection file-id
INFO: Waiting for child process [pid]
INFO: Child process [pid] died

The user sees their upload freeze and then fail. Resolving this requires either running Open WebUI with a single worker, pointing Open WebUI to a standalone ChromaDB HTTP instance, or switching the VECTOR_DB setting to an external enterprise database such as pgvector, Qdrant, or Milvus.

Mitigating Ingestion Latency and CUDA Out-of-Memory Spikes

Vector embedding computation represents the second major failure point during large file uploads. By default, Open WebUI runs a local SentenceTransformers embedding model on the host CPU or GPU.

Processing large text documents generates thousands of chunks. Passing these chunks through local embedding models creates intense memory pressure. In GPU-enabled containers, PyTorch memory fragmentation frequently causes CUDA out-of-memory errors:

CUDA out of memory. Tried to allocate X MiB. GPU has a total capacity of Y GiB of which Z MiB is free.

Furthermore, in older Open WebUI releases, long-running embedding computations on CPU blocked the main Python event loop. Uvicorn monitors worker health using periodic five-second heartbeat pings. If local embedding operations tie up the CPU for more than five seconds, Uvicorn assumes the worker has hung and terminates the process mid-ingestion.

A third symptom of heavy ingestion is the race condition error: 400: The content provided is empty. Open WebUI processes file uploads asynchronously, returning a file identifier immediately while text extraction proceeds in the background. When an external script or automated prompt attempts to query the document before background embedding finishes, the system reads empty content and aborts the query.

To mitigate these local hardware bottlenecks, administrators can reduce RAG_EMBEDDING_BATCH_SIZE (from 32 down to 8 or 4), offload embeddings to an external Ollama instance or cloud API, and ensure adequate swap memory on the Docker host.

Connecting Open WebUI to Fast.io Through Streamable HTTP MCP

Open WebUI supports the Model Context Protocol natively through Streamable HTTP connections. This allows language models in Open WebUI to search and retrieve information from external Fast.io workspaces on demand during inference, without requiring local vector storage. Detailed integration patterns are covered in the Fast.io Storage for Agents documentation.

To connect Open WebUI to your intelligent workspace:

1. Open your Fast.io workspace settings and generate an API key.
2. In Open WebUI, open the administrative Integrations view.
3. Under External Tool Servers, select the option to add a new connection.
4. Set the connection type to MCP using Streamable HTTP.
5. In the server URL field, enter https://mcp.fast.io/mcp.
6. Set authentication to Bearer and paste your API key into the key field (or use the direct endpoint at https://mcp.fast.io/mcp/key).
7. Save the connection to complete the handshake.

Once connected, Open WebUI registers the consolidated MCP toolset. When a user asks a question about company policies, product architecture, or legal agreements, the language model dynamically invokes the workspace search tool. The model retrieves precise, citation-backed document excerpts in real time. The chat container never needs to ingest, chunk, or store the underlying multi-gigabyte files locally.

Preserving Version History and Context Across Agent Teams

Decoupling storage from the chat container also solves multi-agent coordination challenges. In standard Open WebUI setups, documents uploaded to a chat session or Knowledge Base are isolated to that specific installation. Team members using other AI tools like Claude Code, Cursor, or Cline cannot see or search those files.

Intelligent workspaces serve as a shared coordination layer. Because Fast.io maintains per-file version history, every update to a reference document or project deliverable is tracked automatically. Multiple agents and human team members can read and write to the same workspace simultaneously without risking file collision.

When an autonomous agent finishes compiling research or generating project assets, ownership transfer allows the agent to transfer workspace ownership to a human team lead while retaining administrative access. Activities remain auditable through an append-only audit log.

Every organization starts with a 14-day free trial, which requires a credit card. Plans are Starter at $29/mo, Business at $99/mo, and Growth at $299/mo on Fast.io pricing. Offloading document ingestion to an intelligent workspace allows your self-hosted Open WebUI deployment to remain lightweight, responsive, and completely immune to local vector database crashes.