Ragmux vs Portkey: open-source gateway or hosted control plane?

Both Ragmux and Portkey put one API in front of the model providers you actually call, and both publish an open-source gateway you can run yourself. Where they diverge is what sits around that gateway: Ragmux’s governance, retrieval and budgeting are all part of the one binary you self-host. Portkey’s open-source core handles routing and guardrails; the access control, analytics and compliance work a production deployment eventually needs live behind a hosted control plane, not in the code you run.

What each one is

Portkey’s GitHub repository describes itself as “A blazing fast AI Gateway with integrated guardrails. Route to 1,600+ LLMs, 50+ AI Guardrails with 1 fast & friendly API.” The gateway core runs locally with a single command (npx @portkey-ai/gateway) and is MIT-licensed. Its GitHub repository is not archived, but its own commit and release history is worth reading plainly rather than assuming “open source” means “actively shipping”: the most recent commit to its main branch and the most recent tagged release both predate this review by several months, and a “2.0” branch referenced in the repository’s own banner has not, as of this review, shipped as a release. Nothing in the project’s description mentions retrieval or document grounding either; Portkey is a routing and guardrails layer, not a RAG system.

Ragmux is the single Go binary described throughout this site: one OpenAI-compatible API, one PostgreSQL database with pgvector, and retrieval as part of the request path rather than a separate system. See What is an AI gateway? for the fuller version of that story.

A rebrand worth naming plainly

Portkey’s hosted product is now marketed under a different name, and the reason is more than a rebrand: Palo Alto Networks’ own press release states plainly, “Palo Alto Networks Completes Acquisition of Portkey to Secure AI Agents,” and Portkey’s homepage confirms the resulting product name change — “Portkey is now PRISMA AIRS AI Gateway, generally available for all enterprises.” That acquisition applies to the hosted, governed product — the open-source gateway repository this comparison is built on remains published under the Portkey-AI organization on GitHub, under the same MIT license, and its README and docs still refer to the project as Portkey. A reader searching for “Portkey” today will find both names in use for related but distinct things; this page compares Ragmux against the self-hostable gateway core, which the acquisition has not changed as of this review.

Feature comparison

“Via hosted/enterprise plan” means the capability exists in Portkey’s product line but not in the self-hosted, open-source gateway core covered by this table — see the license and governance section below for what specifically moves behind that line, sourced to Portkey’s own pricing page.

Governance: behind the gateway, vs. in the binary

This is the sharpest structural difference between the two projects, and it’s worth being specific rather than waving at “enterprise features.” Portkey’s own pricing page lists what the free, open-source tier includes — “Universal API, Retries & Timeouts, Routing, Guardrails, Automatic Fallbacks, Basic Dashboard, Load Balancing, Community Support” — and what only a paid or enterprise plan adds: role-based access control and service-account API keys, SSO, a PII anonymizer, and SOC2/ISO/HIPAA/GDPR compliance certifications. The gateway’s own README marks three specific items — semantic caching, provider optimization and prompt template management — with a footnote reading “Available in hosted and enterprise versions”; usage analytics itself carries no such footnote and appears to ship in the self-hosted core.

Ragmux takes the opposite shape: role-based access control (three fixed roles, enforced on every request) and a full audit log recording every create, update, delete, login and key rotation ship in the single binary, free, because there is no paid tier to hold them back for. What Ragmux does not have is SSO/OIDC login — listed on its public roadmap as not scheduled, not shipped — and no compliance certification of its own, published or otherwise; a team that needs SOC2 or HIPAA attestation today has to build that program around Ragmux itself, the same way it would around any self-hosted open-source project without a vendor behind it.

Retrieval: still a gap on Portkey’s side

Neither Portkey’s gateway README nor its AI Gateway product docs describe a retrieval-augmented generation feature at any tier, hosted or open source. Its docs mention pairing the gateway with your own retrieval pipeline the same way LiteLLM’s do — a separate system a project owner has to stand up and operate. Ragmux treats that pipeline as part of the gateway: a project linked to a document store gets its query embedded, searched with hybrid vector-plus-full-text ranking, and injected into the system prompt automatically. See Build private document Q&A with your own PDFs for how that works end to end.

Provider breadth vs. translation depth

Portkey’s 1,600+ models is the more meaningful difference for most teams evaluating either project on raw reach: a single unified API in front of a catalog Ragmux’s six provider types don’t try to match. Coverage isn’t only a count, though. Ragmux’s own provider documentation details, per adapter, how Anthropic and Gemini tool calls are translated to and from the OpenAI schema — including a JSON Schema sanitiser for Gemini that strips keywords OpenAI-style tool definitions routinely carry — how streamed tool-call fragments are reassembled where a provider sends them whole, and which image formats each adapter accepts inline versus fetches from a URL itself. Portkey’s own materials describe its provider count and unified-API promise with the same confidence, but the pages this comparison draws from don’t go into per-provider translation specifics at that depth, which may simply mean the detail lives elsewhere in Portkey’s docs rather than that the translation is shallower. custom_openai, Ragmux’s sixth provider type, is also the one that closes part of the gap in practice: it’s documented to work with any server speaking the OpenAI Chat Completions format, which includes a Portkey gateway instance running in front of its own wider catalog.

Deployment: a bundled database vs. none at all

Portkey’s gateway core is a stateless router — nothing in its documentation describes a database it needs to operate, which is a genuinely simpler operational footprint than Ragmux’s. Ragmux needs PostgreSQL with pgvector unconditionally, bundled inside the default container so a single-host install operates nothing separate, but still one more moving part than a stateless proxy needs. Where Ragmux’s shape pays off is at more than one replica: every instance shares rate limits, budgets, sessions and the document ingestion queue through that same PostgreSQL database, with ingestion claimed under a lease and the retention job electing a leader through an advisory lock, so scaling out needs no Redis or other shared cache tier — just more replicas pointed at the same database and a plain round-robin proxy in front. Portkey’s hosted product is where its equivalent multi-instance state and governance would live instead, which is exactly the control-plane trade this comparison keeps returning to.

The admin surface

Ragmux’s own docs describe a role model enforced on every request, not cached on a session: admin gets full access to users, the audit log and every project; editor can create and manage model connections, RAG stores and the projects it belongs to; viewer gets read and search access to those same projects. Every management action — a model connection created, a document deleted, a user’s role changed, a login attempt — is written to an audit log with the actor, target and IP address, exportable as NDJSON and kept for a year by default. None of that requires a paid tier to switch on, because there is no paid tier for the self-hosted binary. Portkey’s own pricing page places the comparable capability — role-based access control, service-account API keys, a PII anonymizer — behind its paid and enterprise plans specifically, which is the same governance-behind-a-paywall shape this comparison’s governance section already lays out for SSO and compliance certifications.

Where Ragmux is not the answer

• PostgreSQL with pgvector is mandatory. Portkey’s gateway core needs no database at all for routing; Ragmux needs one from the first request, RAG or not.
• No SSO/OIDC and no compliance certifications. A team that needs enterprise identity federation or a SOC2/HIPAA attestation gets both from Portkey’s hosted plan today; Ragmux offers neither, and its roadmap lists SSO/OIDC as not scheduled.
• Ragmux is pre-1.0 — the current release is 0.5.0 — against a gateway core with a longer public history, even though its own commit and release activity has slowed in recent months, per its repository.
• AGPL-3.0-or-later carries a network-use clause that Portkey’s MIT-licensed gateway core does not: modifying Ragmux and running that modification as a service your users interact with obligates you to offer them the corresponding source.
• Reference docs are in English; guides are mostly in English too, with a few in Turkish.