The NGINX plugin community has always been prolific, and sometimes a contributor builds something that lands at the intersection of a real problem and a clean architectural instinct. That is what Kang did with nginx-markdown-for-agents, a self-hostable NGINX dynamic module described in a recent DEV post. The module returns a Markdown version of an HTML page when a client requests text/markdown in the Accept header. Kang is upfront that this is an early prototype with rough edges. But the idea it represents is timely.
One site, two representations
AI crawlers, retrieval pipelines, and agent frameworks increasingly need to work with public web content, and HTML is a poor substrate for that work. Pages carry navigation, sidebars, scripts, banners, and layout wrappers that serve rendering and are nearly useless for extraction. Markdown, by contrast, is clean, portable, and widely understood by the tools doing the parsing. Kang’s module handles the negotiation at the proxy layer. A browser requesting HTML gets the original page. A crawler requesting Markdown gets a generated Markdown representation. The application behind the proxy does not change, and the site keeps serving its normal web experience while NGINX handles the alternate representation on demand. That keeps the idea cheap to evaluate. Teams do not need to rework their CMS, documentation stack, or blog templates to test whether machine-readable delivery improves downstream parsing. They can enable it on selected routes, examine the output, and decide whether it is worth pursuing further.
Why this belongs at the proxy layer
Content negotiation, caching, routing, and policy enforcement already live at the reverse proxy. Producing a cleaner machine-readable representation is a natural extension of that work, and it avoids pushing every application team to build and maintain a parallel set of templates for human and machine consumers. The module is also self-hostable, which matters for teams that want control over rollout, caching, and access policy without delegating that implementation to a third party. Some routes will be good candidates for alternate delivery. Others will not. A self-hostable NGINX module leaves those choices with the operator.
Built in Rust
The prototype is written in Rust, which aligns with a direction NGINX has been moving for some time. When NGINX shipped native ACME support, it was built on the NGINX Rust SDK and delivered as a Rust-based dynamic module. For greenfield capabilities, Rust offers a strong combination of performance, memory safety, and flexibility. This prototype is a reasonable example of why that matters for new infrastructure work.
A shout-out to Kang
The author is clear about scope. This is aimed at content-heavy pages such as blogs, documentation, news, and knowledge bases, and it is not intended for every workload. Edge cases will exist. That is normal for a project working against the messy reality of HTML in the wild.
Even so, this is the kind of open source experiment worth paying attention to. The problem is real, the implementation is real, and the design fits naturally into how NGINX already operates. Projects like this show how the community keeps adapting the platform to new traffic patterns and new ways of consuming content. So a genuine shout-out to Kang for building it and sharing it.