Portus

Portus is an open-source gateway that handles ordinary service traffic, large language model calls, and Model Context Protocol traffic on one Rust data plane. In Kubernetes it implements the Gateway API and gives each Gateway its own deployment, service, and disruption budget. The same installation can also route requests to AI providers and federate MCP tool servers. For teams outside Kubernetes, its data plane can run from a YAML file as a standalone reverse proxy, which makes the project relevant to Docker Compose and virtual-machine environments too.

The Kubernetes side covers HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, ListenerSet, and BackendTLSPolicy from the experimental Gateway API channel. The controller watches those resources and Portus policy resources, compiles them directly into protobuf configuration, and streams only the appropriate slice to each data plane over mutual TLS. There is no intermediate proxy configuration language to generate or debug. Configuration swaps atomically, so a reload is designed to preserve open connections, while terminating pods drain requests that are already in flight. The assigned service address appears in normal Gateway status, so existing Kubernetes tooling can discover it.

Portus includes policies for timeouts, retries, rate limits, circuit breaking, connection caps, active health checks, CORS, IP allow lists, request body limits, and several authentication patterns. Basic credentials, API keys, JWT validation, and forward authorization can all sit at the gateway. Endpoint failures are detected and unhealthy destinations can be removed and later readmitted. In standalone mode, ACME support can obtain and renew Let's Encrypt certificates, backend hostnames are resolved again on a schedule, and changes to the YAML configuration apply without a restart. Weighted backends and redirects can be expressed in the same file.

The AI gateway is aimed at organizations that want provider credentials and usage rules under their own control. Clients can keep speaking the Anthropic Messages or OpenAI chat dialect while Portus reads routing fields from the request body, exchanges the client credential for the provider key, and passes the request onward. Provider keys remain inside the cluster. Portus can issue its own hashed keys, constrain the models they may access, meter input, output, and cached tokens from regular and streamed responses, and enforce budgets by key, user, tenant, route, or other supported subject. Usage endpoints can summarize activity by model, tool, tenant, or route, return time series, expose remaining limits, and export the underlying rows as JSON Lines.

Its MCP gateway applies the same operational approach to tool servers. Several servers can appear behind one endpoint, with tools named by server and tool, and requests can be routed using the JSON-RPC method or tool name. Per-key allow lists and call budgets limit what a client can invoke. OAuth bearer tokens from an OIDC issuer can be checked locally, groups can become tenants, and scopes can control tool access. Sessions remain attached to the backend pod that created them without requiring shared session state between gateway pods. Refused tool calls use JSON-RPC errors while preserving the client session.

The project makes a notable effort to expose engineering evidence. Its official site reports full conformance across 130 Gateway API tests with no skips and publishes benchmark methodology and individual rounds. The displayed comparison uses three proxy pods on the same machine and reports Portus at roughly 224,000 requests per second with a 2.98 millisecond p99 at 256 connections. Those results are useful context rather than universal promises, since the site explicitly says measurements from one machine should only be compared with one another. It also publishes cases where the compared gateway wins, which makes the performance section more useful than a single isolated headline.

Portus fits platform teams that would rather operate one policy layer than separate ingress, AI, and MCP gateways. Installation currently assumes Kubernetes 1.32 or later and Helm 3.8 or later, with images published for amd64 and arm64. That makes it a technical infrastructure choice, not a hosted toggle for a small application. The code is available under Apache 2.0, charts and container images are published through GitHub Container Registry, and the documented quick start installs the controller and gateway resources with Helm. There is no commercial pricing page, so its cost is the infrastructure and expertise required to deploy and maintain it.