OpenResty compatibility
xin is not OpenResty and does not provide a dynamic nginx module ABI. OpenResty directives are accepted only when their xin feature is compiled in and the directive has a concrete lowering and runtime implementation.
Build-time features, not a runtime module loader
The normal xin build does not enable the OpenResty feature bundle. A custom Rust build can select individual features on xin-proxy and xin-facade-nginx; the openresty feature is a convenience bundle, not a claim of complete OpenResty behavior. A directive for a disabled feature fails configuration loading with the feature name.
Implemented subset
| Feature | Implemented behavior |
|---|---|
openresty-echo | The supported echo directives lower to ordered response output. |
openresty-xss | The xss-nginx JSONP response wrapper is implemented for its supported response shape. |
openresty-set-misc | Supported URI, Base64, SQL/JSON quoting, hashing, random and secure-random setters lower to rewrite operations. |
openresty-iconv, openresty-rds-json, openresty-form-input, openresty-memc, openresty-drizzle, openresty-postgres | Feature gates exist where the facade and runtime have a matching implementation. Test the exact directives your configuration uses. |
Explicitly not an OpenResty replacement
There is no Lua VM, cosocket API, coroutine scheduler, shared dictionaries, timer API, worker lifecycle API, dynamic module loader, or stream-Lua execution environment. Lua HTTP, Lua upstream, and stream-Lua directives are refused even when the feature name is present. The same conservative rule applies to unimplemented families such as srcache, Redis/Redis2, encrypted-session, array-var, and modules that only expose a feature placeholder.
Use xin -t -c your.conf against the exact build you intend to deploy. A clean result means the directives were understood; it does not turn xin into a byte-for-byte OpenResty substitute, so compare representative traffic before cutover.