OpenResty/Lua en nginx: alguien lo usa para logica real, o solo para proxy/config?

Sara
12 de Agosto del 2026

¿Alguien usa OpenResty (Nginx + LuaJIT integrado) para algo más que proxy/config estático? Me refiero a meter lógica real con scripts Lua dentro del propio Nginx: autenticación custom, rate limiting más sofisticado que lo que trae de serie, transformación de respuestas al vuelo, ese tipo de cosas.

Entiendo la teoría (evitar un salto extra a un backend para lógica sencilla, aprovechar el modelo event-driven de Nginx también para tu propio código), pero me da la sensación de que en la práctica la mayoría de la gente prefiere mantener Nginx puramente como capa de proxy/estáticos y meter toda la lógica en el backend de siempre, aunque sea menos "elegante" en teoría.

¿Lo tenéis en producción de verdad, o se quedó más en el terreno de la curiosidad técnica?

Sara


David Carrero
12 de Agosto del 2026

Lo he visto en producción de verdad, aunque para un caso concreto: rate limiting avanzado a nivel de borde, más sofisticado que lo que las directivas nativas de Nginx (limit_req, limit_conn) permiten de serie. Con Lua puedes implementar lógica de límites dinámicos basados en comportamiento (por ejemplo, aplicar un límite distinto según patrones de tráfico detectados, o combinar varias señales antes de decidir si bloquear una petición) directamente en el propio Nginx, sin añadir un salto extra a un servicio backend solo para tomar esa decisión.

También lo he visto para transformación de respuestas al vuelo cuando el backend no puede (o no compensa) cambiarse: reescribir cabeceras o cuerpos de respuesta con lógica algo más compleja que un simple sub_filter, sin tocar el código de la aplicación que hay detrás.

Dicho esto, coincido en que es la minoría, no la norma. La mayoría de equipos con los que he trabajado prefieren mantener Nginx puramente como capa de proxy/estáticos por una razón muy práctica: meter lógica de negocio en Lua dentro de Nginx significa que ahora tienes dos sitios distintos donde puede vivir lógica de aplicación (el backend normal, y el propio servidor web), lo que complica el debugging y el onboarding de gente nueva al equipo. Solo compensa cuando el caso de uso es muy específico de la capa de borde (rate limiting, filtrado, redirecciones complejas), no para lógica de negocio general.

David