[Sandbox] Praxis

### Project summary

The cloud and AI-native proxy server and framework

### Project description

Praxis is a proxy server and extensible proxy framework built in Rust. It provides a composable filter pipeline where routing, load balancing, security, observability, and traffic management are all implemented as filters that can be mixed, matched, and extended at compile time.

Praxis fills a gap in the cloud native ecosystem: there is no other proxy server/framework that is deliberately designed from the ground up to be both cloud-native and "AI-native" (e.g. the architecture is fundamentally geared for AI-native capabilities like [payload-processing](https://github.com/kubernetes-sigs/wg-ai-gateway/blob/main/proposals/7-payload-processing.md) and other needs established by the [Kubernetes AI Gateway WG](https://github.com/kubernetes-sigs/wg-ai-gateway/)). Praxis uniquely separates these concerns as well, serving both standard networking use cases and AI networking use cases distinctly. More generally, there is no dedicated proxy server framework.

Being a framework is core to Praxis' identity: historical proxy servers have had one build that tried to serve a litany of different use cases, often ending up with several varied extension mechanisms and ultimately leading to complexity and costs. Praxis does provide a couple of "core builds", but the project early on was inspired by Cloudflare's project [Pingora](https://github.com/cloudflare/pingora/) which flipped the script. We take the position that it's better to have a framework and build the proxy servers you need for your special use cases rather then to try to attach everything to the core build. This is a design principle the project has adopted and extended upon.

Praxis puts security first. Praxis has close monitoring and control of its dependencies and supply chain. Praxis uses Rust to guarantee memory safety at compile time, and follows a significant strict dialect of Rust inspired by functional programming to reduce side effects and make code easier to maintain, test and secure. We work with OWASP, OpenSSF and others in the security community to ensure we're on top of best practices.

### Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/praxis-proxy

### Project repo URL in scope of application

https://github.com/praxis-proxy/praxis

### Additional repos in scope of the application

Wish to submit the entire org, including all the demos and tooling repos, etc.

### Website URL

https://praxis.fast

### Roadmap

https://github.com/praxis-proxy/praxis/projects

### Roadmap context

Our roadmap is organized by Github Projects and milestones. Projects represent "themes" which may have multiple epics, which have subtasks to resolve the epic. Projects can span multiple milestones, but milestones _tend_ to focus on a single project.

### Contributing guide

https://github.com/praxis-proxy/praxis/blob/main/CONTRIBUTING.md

### Code of Conduct (CoC)

https://github.com/praxis-proxy/praxis/blob/main/CODE_OF_CONDUCT.md

### Adopters

https://github.com/praxis-proxy/praxis/blob/main/ADOPTERS.md

### Maintainers file

https://github.com/praxis-proxy/praxis/blob/main/MAINTAINERS.md

### Security policy file

https://github.com/praxis-proxy/praxis/blob/main/SECURITY.md

### Standard or specification?

N/A

### Business product or service to project separation

At Red Hat this is intended to be part of our AI product offerings but Red Hat does not do proprietary software and we intend to develop everything fully upstream as usual. We're committed to sharing this with others and growing a community around it, as upstream first community software development is a core part of our business model and personal convictions.

### Why CNCF?

We considered AI foundations, because Praxis serves AI, but that was not a good fit because the base product of the project is a core proxy server build with nothing AI-specific in it.

CNCF fits the best because deploying on Kubernetes and integrating with other CNCF projects (e.g. Kubernetes, kube-virt, Prometheus, llm-d, Kuadrant, Envoy, etc) is at the core of the project and a primary focus.

### Benefit to the landscape

Providing a high-performance, memory-safe proxy server builds based on Rust and modern technologies is one differentiator. Add onto that the fundamental framework approach to provide other projects the flexibility to make their own proxy servers for potentially very bespoke use cases provides great value to the community given the ubiquity and demand for proxy technology in the CNCF landscape. Topping that off with AI needs being not just a use case but supporting those use cases as part of the fundamental architecture helps others adapt to the rapidly developing AI ecosystem.

### Cloud native 'fit'

* Composable/Extensible - As a framework first (the core builds are built using the framework in the same way anyone else would) community members can avoid getting stuck when they have special use cases and build their own proxy supporting that use case natively. They can get what they need immediately and _then_ work with the community to incorporate it as necessary.
* Container-first - One of the primary things our project produces are container images for running in containerized environments
* Kubernetes-native - The operator implements the Gateway API for declarative ingress management
* llm-d compatible - We support llm-d for distributed inference
* Observability - Native Prometheus and OpenTelemetry integration
* Standards-based networking - Supporting protocol standards such as HTTP/1.1, HTTP/2, HTTP/3, gRPC, Sent Events, WebSocket, etc

### Cloud native 'integration'

Kubernetes, Kube-rs, Prometheus, Operator Framework, llm-d, Kuadrant, we use tools like Kind for development and testing, etc

### Cloud native overlap

Envoy in that we provide proxy server builds, but significantly different in approach.

### Similar projects

N/A

### Landscape

N/A

### Insights

N/A

### Trademark and accounts

- [x] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

### IP policy

- [x] If the project is accepted, I agree the project will follow the CNCF IP Policy

### Will the project require a license exception?

We'll be [Apache 2.0](https://github.com/orgs/praxis-proxy/discussions/837) and will not require any license exceptions.

### Project "Domain Technical Review"

_No response_

### Application contact email(s)

sutt@redhat.com

### Contributing or sponsoring entity signatory information

| Name | Address | Type (e.g., Delaware corporation) | Signatory name and title | Email address |
|-----------|-----------|-----------|-----------|-----------|
| Red Hat Inc. | 100 East Davie Street Raleigh, NC 27601 United States | Delaware Corporation | Shane Utt (Senior Principal Software Engineer) | sutt@redhat.com |

### CNCF contacts

@brandtkeller, @caniszczyk, @GenPage, @angellk have been acquainted with the project to different degrees

### Additional information

_No response_