Cómo desplegar Next.js en Vercel: ventajas, límites y alternativas

Publicado el 2026-10-26 por frfrand

Guía práctica sobre cómo desplegar next.js en vercel: ventajas, límites y alternativas con ejemplos y comparativa de infraestructura.

Tenés un frontend Next.js y querés ver un enlace público después de cada push. Ahí Vercel es muy cómodo. El problema aparece cuando mezclás esa web con una API que procesa trabajos largos, una base o un bot que debe estar encendido todo el día.

No te voy a vender la idea de que una plataforma es perfecta para todos. Lo útil es entender qué trabajo te ahorra, qué trabajo sigue siendo tuyo y cuánto te puede costar mantenerla cuando el proyecto deja de ser una prueba.

Vercel: qué es lo que realmente te ofrece

Vercel destaca por su integración con Next.js, los previews por rama y la distribución global del frontend. No es simplemente «un VPS con un botón»: su modelo de ejecución y sus límites son distintos. El despliegue puede incluir renderizado en el servidor, funciones y recursos estáticos, pero no te entrega root en una máquina para instalar cualquier servicio.

Un ejemplo que podrías tener mañana

Una plataforma de reservas tiene páginas públicas, un panel para administradores y un backend que confirma pagos. Podés dejar Next.js en Vercel con previews para revisar la interfaz, mientras FastAPI, PostgreSQL y un worker corren en un VPS de ArduMaker. Conectás ambos por api.tudominio.com y HTTPS. No hace falta elegir una plataforma para absolutamente todo.

Cómo empezar sin complicarte de más

Prepará el repositorio y comprobá que npm run build termina sin errores.
Conectá GitHub a Vercel e importá el proyecto Next.js; verificá el directorio raíz si tenés un monorepo.
Definí variables públicas y privadas correctamente. Las NEXT_PUBLIC_* se incorporan al código visible del navegador.
Probá el preview antes de apuntar el dominio, especialmente las rutas SSR y las peticiones de API.
Revisá logs y consumo si una ruta ejecuta consultas lentas o trabajos prolongados.

El quinto paso suele ser el que se saltea: abrir la aplicación desde otro dispositivo, ejecutar una operación que escriba datos, revisar un log y volver a comprobarla después de reiniciar. Eso vale más que una captura donde el panel dice «deployed».

El error que evitaría

No uses localhost en el código que corre en el navegador: allí apunta al equipo de quien abre la web. Tampoco expongas credenciales en variables públicas. Si necesitás WebSockets persistentes o trabajos de larga duración, revisá antes si encajan con el modelo de ejecución de Vercel.

Hay otra regla simple: si el proyecto tiene clientes o pagos, no experimentes con migraciones directamente sobre la única copia de la base. Probá en un entorno separado, guardá una copia verificable y prepará cómo volver atrás.

¿Cómo resolvería lo mismo en ArduMaker?

En ArduMaker podés ejecutar Next.js como servicio Node en un VPS, conectar Git y asociar un dominio. También podés alojar el backend y PostgreSQL en ese entorno. Ganás control de procesos, pero no recibís automáticamente los previews por PR ni la distribución CDN que Vercel ofrece para el frontend.

En un caso típico, podrías crear el VPS en ArduMaker, conectar el repositorio Git, instalar o gestionar PostgreSQL según la aplicación, definir el proceso de ejecución y publicar un dominio HTTPS. Si hay un worker que tarda varios minutos, separalo del servicio HTTP. Y si el proyecto tiene varios clientes, organizalos por Empresa para evitar permisos y recursos mezclados.

Necesidad	Vercel	ArduMaker
Modelo principal	Vercel destaca por su integración con Next	VPS con herramientas de administración, Git, servicios y MCP
Acceso al sistema	Depende de la plataforma o del servidor donde se instala	Administración del entorno VPS
Base de datos y trabajadores	Dependen del producto y su configuración	Pueden ejecutarse en el VPS según los recursos disponibles
Mantenimiento	Compartido o asumido por vos según el servicio	Aplicación y sistema requieren control y mantenimiento

Qué miraría antes de pagar o migrar

No elegiría por una única cifra en la página de precios. Anotá CPU, RAM, almacenamiento persistente, tráfico, copias, soporte y tiempo de mantenimiento. Si tenés que sumar una base gestionada, un servicio de workers o un panel con licencia, incluilos. Si querés redundancia entre servidores, también hay que diseñarla: un VPS por sí solo no es alta disponibilidad.

Entonces, ¿cuál usaría?

Vercel suele ser más directo para frontend Next.js con trabajo colaborativo. ArduMaker tiene sentido si la aplicación necesita servidores y procesos propios; para muchos equipos la combinación es una solución razonable.

Una prueba honesta: publicá una API mínima, conectala a una base, detené el proceso para ver qué registra el sistema y probá recuperarla. La plataforma con la que tu equipo pueda repetir esos pasos sin sufrir suele ser la que más valor te aporta.

Fuentes y lecturas para seguir

La idea final: primero resolvé un problema real con la herramienta. Después compará cuánto esfuerzo te lleva mantenerlo. Ahí aparece la diferencia entre una demo y una aplicación que podés entregar a un cliente.