Vercel hizo que desplegar una aplicación sea algo sencillo y cómodo. Todos valoramos la comodidad y la sencillez. Cómo no va a resultar atractivo que un proyecto esté funcionando en producción en minutos, sin ocuparse directamente de servidores, redes, escalado o buena parte de la operación de infraestructura. Y encima ofrece un generoso free tier, con lo cual el costo para iniciar el proyecto es bajo.
Y acá aparece un límite: Vercel es genial para comenzar, pero las dificultades y los costos aumentan a medida que el proyecto empieza a crecer. Escalar comienza a presentar un desafio.
Vercel es una plataforma sólida: no necesitás configuración, se optimiza de forma automática, ofrece analytics y monitoreo, Edge Functions, ISR a escala y despliegue multi-región. No solo es robusta en infraestructura, sino que también hace que trabajar como desarrollador sea más fácil.
¿Por qué migrar a un VPS?
Así como es una herramienta maravillosa para empezar, el modelo de costos de Vercel puede volverse menos conveniente a medida que una aplicación crece y aumenta su consumo de infraestructura.
Vercel factura distintos componentes según su consumo, y uno de ellos es el Fast Data Transfer: la transferencia de datos hacia los usuarios. Supongamos que una visita genera 400 KB de transferencia. Con 100.000 visitas estamos hablando de 100.000 × 400 KB ≈ 40 GB. Hasta ahí, todo bien.
El desafio aparece cuando el tráfico crece considerablemente. En el plan Pro, Vercel incluye actualmente 1 TB mensual de Fast Data Transfer. Superado ese consumo, el precio publicado parte de $0,15 por GB adicional, aunque puede variar según la región. Como referencia, 1 TB adicional al precio base representaría unos $150 de consumo. El costo final depende además del resto de los servicios y créditos incluidos en el plan. (Vercel Pricing).
En términos de negocio, esto significa que parte del costo de operar la aplicación puede crecer junto con el tráfico. Cuando el tráfico es pequeño, probablemente no sea relevante. Cuando la aplicación empieza a tener cientos de miles o millones de visitas, conviene revisar cuánto cuesta realmente servir ese tráfico
Está todo bien los primeros meses, pero si estás en medio de una campaña de marketing el tráfico aumenta diez veces y la aplicación incorpora workers, generación de reportes, Redis y procesos en segundo plano.
En un VPS es diferente: contratás una determinada capacidad de CPU, memoria, almacenamiento y red. Si la aplicación crece, aumentás los recursos del servidor o agregás infraestructura adicional. Eso hace que el costo sea más previsible, aunque no necesariamente menor desde el primer día.
Pero el costo no es la única diferencia. La otra tiene que ver con qué podés ejecutar dentro de esa infraestructura. Vercel está diseñado alrededor de una infraestructura administrada y un modelo de ejecución basado principalmente en Functions. Actualmente permite ejecutar tareas de mayor duración y ofrece soporte para WebSockets en determinados escenarios, pero estas capacidades siguen sujetas a los límites y al modelo operativo de la plataforma (Vercel Functions). En un VPS, en cambio, podés correr directamente procesos persistentes: workers, servidores WebSocket, Redis, cron jobs, APIs internas o el propio servidor Node.js de Next.js, sin que estén condicionados a un modelo de funciones.
La diferencia, entonces, no es simplemente qué plataforma «puede» ejecutar una determinada tecnología. La diferencia está en quién administra la infraestructura y cuánto control tenés sobre ella.
Tener mayor control significa poder decidir dónde corre la aplicación, qué servicios ejecuta el servidor, cómo se almacenan los datos, qué procesos funcionan en segundo plano y cómo se configura la seguridad.
Vercel vs. VPS
Vercel ofrece muchas cosas excelentes: escalado administrado, infraestructura global, CDN, optimización y despliegues sin fricción. Un VPS también puede ofrecer buena parte de esto, pero tenés que construirlo y administrarlo vos.
| Aspecto | Vercel | VPS |
|---|---|---|
| Primer deploy | Muy rápido, con poca configuración | Requiere servidor y configuración |
| Escalado | Administrado por la plataforma | Debe planificarse |
| CDN global | Integrada | Requiere CDN adicional |
| Procesos persistentes | Dentro del modelo de ejecución de la plataforma | Naturales en procesos o contenedores |
| Control de infraestructura | Limitado a la plataforma | Alto |
| Observabilidad | Herramientas integradas | Debe configurarse |
| Alta disponibilidad | Infraestructura administrada | Requiere arquitectura redundante |
| Costos | Plan + consumo | Capacidad contratada + operación |
Ahí aparece el punto que al principio asusta cuando contratás un VPS: la infraestructura pasa a ser responsabilidad tuya. Actualizaciones, seguridad, firewall, backups, monitoreo, logs, deployments, certificados, recursos, recuperación ante fallos — todo eso queda de tu lado. Un VPS individual, además, es un punto único de falla: si ese servidor se cae, la aplicación queda fuera de servicio. La alta disponibilidad no se obtiene solo contratando un servidor; se construye con redundancia, backups probados, monitoreo y un plan de recuperación real.
Un VPS ofrece más control, pero también más responsabilidad. En cambio, un VPS administrado permite delegar la operación del servidor mientras tu equipo continúa trabajando sobre la aplicación
La alternativa: VPS administrado
Hay un punto medio entre la comodidad de una plataforma como Vercel y la complejidad de administrar un servidor propio: el VPS administrado. La idea es sencilla — vos te ocupás de tu aplicación, nosotros nos ocupamos del servidor.
En la práctica, esto implica auditar la aplicación y sus dependencias de Vercel, elegir y configurar el VPS adecuado, preparar Linux, Docker y contenedores, poner un reverse proxy con HTTPS y firewall, dejar los despliegues automatizados, monitorear disponibilidad y recursos, tener logs y alertas, backups programados con pruebas de restauración, actualizaciones de sistema y runtime, revisión de capacidad, health checks y un plan de rollback y recuperación. Todo eso es lo que hace que un VPS deje de sentirse como «un servidor más» y empiece a comportarse como una infraestructura administrada.
Y acá vale la pena volver a algo que mencionamos al principio: gran parte de lo que hace atractivo a Vercel para un desarrollador es que un git push alcanza para ver los cambios en producción, sin pensar en servidores. Esa comodidad no es exclusiva de Vercel — es el resultado de tener un pipeline de CI/CD bien armado. En un VPS administrado vos podes tener ese flujo funcionando: conectamos el repositorio, armamos el pipeline de build y deploy (por ejemplo con GitHub Actions), y dejamos un entorno de staging para probar antes de pasar a producción. Para el equipo de desarrollo el día a día no cambia demasiado: seguís haciendo push a una rama y el despliegue ocurre solo. Lo que cambia es quién construyó y sostiene ese pipeline por debajo.
El objetivo no es solamente que la aplicación funcione. Es que funcione sin que tengas que estar pendiente del servidor todos los días.
Cómo hacemos la migración
Migrar una aplicación de Vercel no consiste en copiar el proyecto a otro servidor y correr npm run start. Hay que entender qué parte de lo que hace funcionar tu app es Next.js, y qué parte depende específicamente de la infraestructura de Vercel. Así lo encaramos:
- Auditoría. Identificamos qué usa la aplicación hoy: Functions, Edge Runtime, ISR, cron jobs, Storage/KV, bases de datos, Analytics, Image Optimization, variables de entorno, webhooks y servicios externos.
- Preparación de la aplicación. Next.js puede desplegarse como servidor Node.js o mediante Docker; también existe la exportación estática cuando la app no necesita funcionalidades de servidor. Para Docker, Next.js ofrece
output: "standalone", que genera una salida de producción más liviana con solo los archivos y dependencias necesarios para correr (Next.js – Self-hosting):
const nextConfig = {
output: "standalone",
};
export default nextConfig;- Configuración del VPS. Docker, reverse proxy, HTTPS, firewall, usuarios con permisos mínimos, variables de entorno, logs, backups, health checks y monitoreo. Next.js recomienda explícitamente un reverse proxy delante del servidor cuando se hace self-hosting.
- Staging. Antes de tocar producción, desplegamos una instancia de prueba y validamos SSR, Route Handlers, autenticación, formularios, imágenes, WebSockets, cron jobs, webhooks y conexiones a base de datos.
- DNS y corte de tráfico. Preparamos el DNS, verificamos el certificado TLS y mantenemos Vercel disponible como plan de retorno. Después apuntamos el dominio al nuevo servidor y monitoreamos disponibilidad, errores y consumo de recursos. Si aparece un problema relevante, se ejecuta el rollback.
- Estabilización. Confirmamos que los backups funcionen y puedan restaurarse, que las alertas estén operativas, y recién ahí retiramos la infraestructura anterior.
Un punto que suele pasarse por alto es la caché. Con una única instancia, Next.js puede usar almacenamiento local para ciertos datos de caché de ISR. Cuando la aplicación pasa a correr en varias instancias, esa caché ya no se comparte sola — hay que diseñarla para ese escenario, y Next.js permite configurar manejadores de caché personalizados para eso (Next.js – Cache Handlers).
La mayoría de lo que ofrece Vercel tiene un equivalente razonable fuera de la plataforma: SSR y Route Handlers corren igual en Next.js sobre Node.js o Docker; next/image sigue disponible en self-hosting y puede realizar la optimización de imágenes en runtime; el middleware funciona igual, siempre que no uses exportación estática; los cron jobs se resuelven con cron, systemd timers o un scheduler externo; y para CDN global simplemente sumás Cloudflare u otra por delante del VPS. Lo único que no se replica con configuración es la alta disponibilidad real — esa requiere réplicas y un balanceador, no solo un servidor más grande.
¿Cuándo deberías migrar?
La pregunta que deberías hacerte es: ¿cuándo tiene sentido evaluar una migración?
No tiene sentido migrar solo porque tu aplicación esté alojada en Vercel. Para prototipos, MVPs, equipos chicos o proyectos que priorizan previews y despliegues rápidos, Vercel sigue siendo una excelente opción.
Vale la pena evaluar una migración cuando el costo variable empieza a ser difícil de predecir, cuando necesitás procesos persistentes, workers, Redis o servicios auxiliares, cuando querés más control sobre la infraestructura y el sistema operativo, cuando buscás consolidar varias aplicaciones en un mismo lugar, o cuando tu arquitectura ya no encaja cómodamente con el modelo de Vercel.
¿Tu aplicación está creciendo?
En AXR Global nos encargamos de administrar VPS. Podemos analizar tu aplicación actual, identificar sus dependencias de Vercel, estimar los requerimientos de infraestructura y decirte honestamente si una migración tiene sentido para tu caso. Si es así, nos encargamos del proceso completo: preparación del VPS, Docker, deployment, seguridad, monitoreo, backups, DNS y puesta en producción.
Vos seguís concentrado en tu aplicación. Nosotros nos ocupamos del servidor.
Solicitá una evaluación de tu infraestructura →
O escribinos a nuestro WhatsApp: 1155249506
Si querés tener una idea de costos, podés ver nuestros planes de VPS Server