- Un artículo que trata los problemas de apertura y gobernanza de Next.js: la ausencia de adaptadores, la falta de soporte serverless oficial, las rutas de código exclusivas para Vercel y la forma en que Vercel respondió a un incidente de seguridad
- Elegir un stack tecnológico es una decisión importante que tiene efectos de largo plazo en la velocidad de desarrollo, la calidad del proyecto y la composición del equipo
- El software de código abierto da a los usuarios la libertad de extender y modificar el código, además de la ventaja de evitar el vendor lock-in
- Next.js se ofrece como código abierto, pero está estrechamente entrelazado con la infraestructura de Vercel
- No hay problema en que una empresa obtenga ingresos de software de código abierto que creó, pero para que sea un modelo sostenible, el límite entre el código abierto y la empresa debe estar claramente definido
Antecedentes e intereses del autor
- El autor trabaja en Netlify desde hace más de 4 años, y Netlify compite con Vercel
- Al construir directamente la infraestructura y el tooling para soportar todas las funciones de Next.js en Netlify, adquirió un conocimiento profundo de la estructura interna de Next.js
- Durante mucho tiempo evitó plantear públicamente estos problemas, pero decidió escribir este texto porque consideró que la manera en que Vercel manejó recientemente un problema de seguridad perjudicó a la comunidad
# Problemas de apertura y gobernanza en Next.js
Hecho #1: ausencia de adaptadores
- La mayoría de los frameworks modernos pueden configurarse de forma flexible según el destino de despliegue mediante adaptadores
- Next.js no soporta adaptadores oficialmente, y el formato de salida es una estructura propietaria y no pública que solo se usa en Vercel
- Vercel creó Build Output API, pero Next.js todavía no lo soporta
- Como resultado, los proveedores fuera de Vercel tienen que construir sobre APIs no documentadas, lo que los deja expuestos a cambios inesperados
- Cloudflare y Netlify están colaborando en el desarrollo de adaptadores para Next.js a través de OpenNext, y Vercel también empezó a participar, pero todavía no hay un calendario concreto
Hecho #2: falta de soporte serverless oficial
- El método oficial de self-hosting de Next.js se basa en servidores de larga ejecución, lo que dificulta implementar escalabilidad flexible y reducción de costos en entornos reales de operación
- Antes existía un modo serverless, pero fue eliminado en octubre de 2022 sin mucha explicación
- La documentación oficial de React menciona que el despliegue serverless es posible, pero no existe documentación oficial para implementarlo en la práctica
- Los proveedores de hosting que quieren un entorno serverless tienen que hacer ingeniería inversa de Next.js e implementarlo por su cuenta
Hecho #3: existen rutas de código exclusivas para Vercel
- Next.js incluye rutas de código no públicas que solo funcionan cuando se despliega en Vercel (por ejemplo, minimal mode)
- Mediante este modo, Vercel puede optimizar el rendimiento, como ejecutar middleware en el edge
- El middleware permite ejecutar lógica rápidamente en la ruta previa al caché, pero esta función solo puede usarla Vercel
- Netlify mantuvo un equipo dedicado de ingeniería e hizo una implementación propia para soportar esta función, pero eso exige un nivel de recursos imposible para proveedores pequeños
- La realidad de que solo Vercel sea la única plataforma que ofrece oficialmente todas las funciones de Next.js contradice la filosofía open source del framework
Incidente de seguridad y respuesta de Vercel
- El 21 de marzo de 2025 se divulgó una vulnerabilidad crítica de seguridad en Next.js (CVE con puntaje 9.1) que permitía eludir la autenticación
- La vulnerabilidad consistía en que, al incluir un encabezado específico en la solicitud, se podía desactivar el middleware y acceder a recursos protegidos
- La vulnerabilidad fue reportada el 27 de febrero, pero Vercel no empezó a investigarla sino hasta el 14 de marzo
- Aunque se distribuyó un parche rápidamente tras reconocer el problema, pasaron 8 días antes de informar a otros proveedores como Netlify
- En la publicación inicial del blog se describía la situación como si el firewall de Vercel hubiera protegido a sus clientes, pero en realidad no fue así
- Como consecuencia, varios proveedores y desarrolladores respondieron con información incorrecta o sufrieron confusión, y todavía es posible que muchos sitios sigan siendo vulnerables
La propiedad de Next.js por parte de Vercel y la responsabilidad del código abierto
- No se puede negar que Vercel es propietaria de Next.js, y también es legítimo que lo monetice
- Sin embargo, al ofrecerse como código abierto, otros proveedores también deberían poder usarlo en igualdad de condiciones, y en este punto Vercel no ha estado a la altura de las expectativas
- Redis, Grafana y WordPress también operan servicios comerciales junto con proyectos open source, y aun así mantienen la apertura y la interoperabilidad
Conclusión
- Sea cual sea el framework que elijas, esa es tu decisión, y si Next.js es lo mejor para resolver tu problema, está bien seguir usándolo
- Aun así, es importante elegir conociendo los problemas estructurales y las limitaciones que Next.js tiene actualmente
4 comentarios
Opiniones en Hacker News
El autor trabaja en Netlify y, según sus propias palabras, es un competidor directo de Vercel. Esto me parece un poco carente de objetividad.
Si comparaste recientemente frameworks competidores como TanStack o Remix, el contenido del texto es algo que todos ya conocen, en mayor o menor medida. Por ahora no se ha visibilizado porque la cuota de Next.js sigue siendo muy grande y Vercel tampoco ha mostrado una postura tan descarada.
Afirmar que, por trabajar en una empresa competidora, el texto carece de objetividad respecto de la información que busca transmitir es un ataque personal. ¿Es un texto extraño incluso si se lee omitiendo los antecedentes y los intereses del autor? Yo creo que es información útil.