Ragmux vs Cloudflare AI Gateway: edge control plane or self-hosted retrieval?

Cloudflare AI Gateway and Ragmux both sit in front of the model providers an application calls, but only one of them is something you deploy. Cloudflare AI Gateway is a proprietary layer built into Cloudflare’s own network — there’s no container to run and no source to audit, the same shape as OpenRouter. Ragmux is a single binary you operate yourself. This page compares what each one actually does with the traffic that passes through it, not which is “better,” since they ask different things of the team adopting them.

Disclosure: this site runs on Cloudflare

Before anything else: ragmux.com itself is deployed on Cloudflare Pages. That has no bearing on what Cloudflare AI Gateway’s own documentation says or on the facts in this comparison, but naming a company’s product while also being its customer is worth being upfront about rather than leaving a reader to discover it elsewhere.

What each one is

Cloudflare’s AI Gateway documentation describes it as a layer for observability and control — analytics, caching, rate limiting and model fallback — in front of requests to the providers you already call, and labels it “Available on all plans” in its own docs. It runs entirely on Cloudflare’s network: there is no deployment of it outside Cloudflare’s own infrastructure, and access is tied to a Cloudflare account rather than a license you can fork or audit.

Ragmux is the single Go binary described throughout this site — one OpenAI-compatible API, one PostgreSQL database with pgvector, and retrieval as a first-class part of the request path. See What is an AI gateway? for the fuller version.

Feature comparison

What Cloudflare AI Gateway actually adds

Its documentation centers on edge caching, analytics and rate limiting in front of the providers you already call, rather than on hosting routing or retrieval logic of its own. That’s a genuinely different job than what Ragmux does: a team already sending traffic through Cloudflare’s network gets caching and visibility with nothing new to deploy, patch or back up — the same “no infrastructure of your own” trade-off OpenRouter offers, here scoped to a caching and observability layer instead of full model routing. For a team whose traffic already flows through Cloudflare’s edge for other reasons, adding AI Gateway is closer to flipping on a feature than standing up a system.

Retrieval lives in a different product, not in AI Gateway

Cloudflare does offer a vector database — Vectorize — and AI Gateway’s own documentation lists it under “Related products” there, described as letting you “Build full-stack AI applications with Vectorize, Cloudflare’s vector database.” (Vectorize’s own docs phrase it slightly differently, as “Cloudflare’s powerful vector database.”) So the two are at least cross-referenced. Neither page goes further than that cross-link, though: nothing in either one’s documentation describes a built-in pipeline connecting them. Building retrieval on Cloudflare’s platform today means wiring Vectorize together with your own chunking, embedding and retrieval logic as a separate system in front of AI Gateway, the same shape as pairing LiteLLM or Portkey with an external vector database — not one product doing both. Ragmux treats that pipeline as part of the gateway itself: a project linked to a document store gets its query embedded, searched and injected automatically. See Build private document Q&A with your own PDFs for how that works.

Budgets: tokens vs. dollars, both enforced

Both projects enforce a spend ceiling, not just report one, and it’s worth being exact about which axis each one enforces rather than assuming Ragmux is ahead here by default. Cloudflare’s own spend limits documentation describes the feature plainly: “Spend limits let you set cost-based budgets on your AI Gateway. When cumulative spend reaches the limit within a time window, AI Gateway blocks further requests with a 429 response until the window resets.” That is a real, currency-denominated ceiling, enforced the same way Ragmux’s own budgets are — the next request is refused, not just logged — and Cloudflare’s own docs currently mark the feature Beta.

Ragmux’s project and API key budgets (budget_daily_tokens, budget_monthly_tokens) enforce on the same request-refusal model, but the unit is different: tokens, never currency. The dashboard shows an estimated dollar cost per request and per project, built from an editable price table, but that estimate is informational — it is never what a budget check compares against. A dollar-denominated budget is listed on Ragmux’s public roadmap as not scheduled, not shipped today (see Where Ragmux is not the answer below). A team that needs a hard ceiling in dollars specifically, enforced automatically, gets that from Cloudflare AI Gateway today; a team that wants to bound token consumption per project, independent of a price table that can drift, is closer to what Ragmux’s budgets do. “Which one enforces spend” is not the honest axis to compare them on — both do; “which unit does the enforcement use” is.

Two different definitions of “self-hosted-adjacent”

Cloudflare AI Gateway and Ragmux both let a team avoid managing model provider credentials in every calling application, but the boundary of what’s “yours” sits in a different place for each. With AI Gateway, the credentials, cache, logs and analytics all live inside Cloudflare’s account model — access is tied to who can log into that Cloudflare account, and the data behind the dashboard is Cloudflare’s infrastructure to operate, not yours. With Ragmux, the equivalent state — provider credentials encrypted with a key you hold, request logs, and the document store behind any RAG-enabled project — lives in a PostgreSQL database you run and back up yourself. Neither is wrong; they’re answering different questions about who operates what, and a team that already trusts Cloudflare with its edge traffic may reasonably extend that trust to its AI traffic too, the same way a team that wants nothing outside its own network reaches for a self-hosted gateway instead.

Observability: an account dashboard vs. a queryable database

Both projects report on what happened to a request, but the shape of that reporting differs in a way worth naming. Cloudflare’s own docs list analytics and logging among AI Gateway’s core features, surfaced through the Cloudflare dashboard tied to the account that owns the gateway. Ragmux writes a row to its own request_logs table for every call — tokens, latency, status, whether retrieval ran, an estimated cost — queryable directly through its own database or exported as CSV, and can additionally expose a Prometheus /metrics endpoint (off by default, METRICS_ENABLED=true to turn it on; token-protected with METRICS_TOKEN unless it is bound to a loopback address through METRICS_LISTEN) and OpenTelemetry spans over OTLP for a team that already runs its own observability stack. The practical difference is who can query the data and how: Cloudflare’s is a dashboard you view inside Cloudflare’s account system, Ragmux’s is a database row a team’s own tools can query directly, export, or feed into whatever monitoring stack it already operates.

A worked example: a team split across two questions

Take a team that already proxies its application traffic through Cloudflare for unrelated reasons — DDoS protection, a CDN, Cloudflare Workers running the app itself — and is now evaluating LLM infrastructure for two different features. The first is a public-facing chatbot with no proprietary data behind it, where caching common questions at the edge and getting cost analytics without deploying anything new is a real, direct win: turning on AI Gateway for that traffic is close to free, operationally, given the Cloudflare account already exists. The second is an internal tool that has to answer from a confidential internal wiki and needs its request logs to stay inside infrastructure the team’s own security review has already audited — the AI Gateway trade-off (no container to run, but data inside Cloudflare’s account boundary) is the wrong fit for that second feature specifically, and a self-hosted gateway with retrieval built in is the one that satisfies it. Nothing about running one for the first feature and the other for the second is a contradiction; they’re answering two different requirements from the same team.

Where Ragmux is not the answer

• PostgreSQL with pgvector is mandatory, and Cloudflare AI Gateway needs no database of your own at all — every deployment shape of Ragmux is more operational work than turning on a Cloudflare feature.
• No edge caching. Ragmux does not cache responses at the edge, which AI Gateway does. Ragmux’s fallback happens between the targets of a route you define for a project, in the priority order you set.
• Ragmux is pre-1.0. The current release is 0.5.0, and SSO/OIDC login and dollar-denominated budgets are listed on the roadmap as not scheduled.
• AGPL-3.0-or-later carries a network-use clause with no equivalent for a proprietary service you never modify or redistribute.
• Reference docs are in English; guides are mostly in English too, with a few in Turkish.