Cómo migrar de Vercel a tu propio servidor (2026)

En pocas palabras: Para dejar Vercel por un servidor propio, anotá primero la configuración del panel (variables, dominios, crons, add-ons), desplegá en una URL de prueba, bajá los TTL de DNS a 60-300 segundos y corré ambas plataformas en paralelo. Vercel no tiene importador automático: el traspaso es manual.

Para migrar de Vercel a un servidor propio, anotá primero la configuración que vive en el panel, desplegá en una URL de prueba, bajá los TTL de DNS a 60-300 segundos y corré ambas plataformas en paralelo. Así lo describe un runbook publicado el 10 de octubre de 2026.

Un runbook de migración es una guía operativa paso a paso. Este lo escribió Gagan Deep Singh, fundador de GLINR STUDIOS, y usa como destino Levelrail: una plataforma de despliegue autoalojada y de código abierto (Apache 2.0) que corre en tus propios servidores Linux y da HTTPS, logs, métricas y rollback después de un push a git. Ojo: es la plataforma que desarrolla el propio autor.

¿Qué configuración de Vercel hay que inventariar antes de migrar?

Hay que inventariar todo lo que Vercel guarda en su panel y no en tu repositorio: variables por entorno, dominios, DNS, crons, configuración de funciones y add-ons. Según el runbook, lo difícil es la configuración y no el código. Como no hay importador, cada ítem se anota y se recrea a mano.

• Variables por entorno. Están en Project Settings, Environment Variables. Vos decidís cómo Production, Preview y Development pasan al destino.
• Variables NEXT_PUBLIC_*. Se compilan en el build y nunca se leen en runtime.
• Dominios y redirects. Están en Project Settings, Domains, y los recreás uno por uno.
• Proveedor de DNS y TTL. Viven en tu registrar; los TTL se bajan antes del cambio.
• Cron jobs. Están en vercel.json y en la pestaña Cron, y el cron de Vercel golpea una ruta HTTP.
• Configuración de funciones. Está en vercel.json y en runtime = "edge" dentro del código; nada reemplaza el edge runtime.
• Storage y add-ons. Salen de Integrations, y el almacenamiento administrado no se muda con la app.

Ponele que hay un cron de limpieza cargado en la pestaña Cron por alguien que ya no trabaja en la empresa. Si no está en el repo, nadie lo va a extrañar hasta que la base empiece a crecer (spoiler: casi siempre hay uno).

¿Qué equivalente tiene cada concepto al migrar de Vercel a un servidor propio?

En el runbook casi cada concepto de Vercel tiene su par en Levelrail: proyecto, deploy por push, build, entornos, secretos, previews, rollback, cron y Postgres. Es un mapeo del autor sobre su propia plataforma, así que usalo como lista de preguntas aunque elijas otra herramienta (esa extrapolación es nuestra, no de la fuente). Ya lo cubrimos antes en migrar tu proyecto a Cloudflare Pages.

Vercel	Levelrail
Project	Una app con uno o más servicios
Git deploy on push	Fuente git con trigger por push
Framework preset build	Build tipo railpack o dockerfile
Static export	Build tipo static, servido por Caddy sin contenedor
Environments	Entornos opcionales con promote
Sensitive env vars	Secretos cifrados, de solo escritura
Preview deployments	Previews por pull request, opt-in por app
Instant Rollback	Rollback por deploy id, fijado por digest
Cron Jobs	Tareas programadas que ejecutan un comando en el contenedor
Vercel Postgres	Postgres administrado donde restaurás un dump

Dos filas esconden diferencias. El cron de Vercel llama a una ruta HTTP, mientras que la tarea programada corre un comando dentro de tu contenedor, y ese comando tiene que usar una herramienta que la imagen realmente trae. Las previews, además, son por pull request y nunca por branch.

Ejemplo hipotético (inferencia nuestra, no de la fuente): si tu cron pegaba a /api/cron/limpieza y tu imagen es mínima, la tarea necesita un comando que haga ese pedido, y si la herramienta no está en la imagen, falla.

La trampa del build merece un párrafo aparte. next build incorpora los valores NEXT_PUBLIC_* en el bundle, pero la plataforma inyecta las variables recién cuando arranca el contenedor, o sea que nunca llegan al build. La solución del runbook es commitear un .env.production con los valores públicos.

¿Qué funciones de Vercel se pierden al migrar a un servidor propio?

Según el runbook, no tienen reemplazo directo las Edge Functions, el CDN global, la optimización de imágenes en CDN, las analíticas del navegador, Blob/KV/Edge Config y el autoscaling. Tampoco hay redirección automática de HTTP a HTTPS en el ingress, según el runbook del 10 de octubre de 2026. Si alguna es imprescindible para vos, mejor enterarte antes de empezar. Relacionado: desplegar una app React con Vite.

Función de Vercel	Estado en el destino del runbook
Edge Functions y Middleware	Sin reemplazo. El middleware compatible con Node funciona; el código solo-edge pasa al runtime Node
Image Optimization CDN	next/image corre en tu contenedor, con tu CPU
CDN global y caché en el edge	No hay. Caddy sirve desde tus nodos
Web Analytics y Speed Insights	Sin analíticas del navegador; hay métricas de requests del servidor
Blob, KV, Edge Config	Sin equivalente directo. Hay Redis administrado, pero reescribís el cliente
Autoscaling y scale to zero	Solo réplicas fijas
Redirección HTTP a HTTPS	No la hace el ingress, según el runbook del 10 de octubre de 2026; se agrega en el DNS o en un CDN delante

La lectura práctica: tu app queda más lenta para usuarios lejanos si dependías del edge de Vercel, y la factura deja de escalar sola porque las réplicas son fijas. El runbook no trae mediciones de latencia ni de costo, así que no hay cifra que citar sobre cuánto cambia.

El propio autor lo resume: si alguna fila es un deal breaker, te ahorraste la migración.

¿Cómo cambiar el DNS de Vercel a mi servidor y poder volver atrás?

Bajá los TTL a 60-300 segundos al menos un TTL viejo antes del cambio, tené el certificado listo, probá con curl --resolve y anotá los registros A y AAAA actuales antes de tocarlos. Para volver atrás restaurás esos valores; con TTL bajo, la mayoría de los clientes regresa en minutos, según el runbook.

1. Desplegá sin dominios reales. Usá una URL de prueba para que nada compita con Vercel por tu hostname.
2. Cargá variables y secretos. Importá el env plano con dry run primero y después los secretos, con los valores de la columna Production, no los de Preview.
3. Agregá una ruta de readiness. Que no dependa de servicios externos.
4. Probá lo que rompe. Páginas, API routes, callbacks de auth, imágenes y respuestas en streaming.
5. Cambiá el DNS. Agregá los dominios reales y el redirect de www, probá con host override, cambiá A y AAAA y mirá logs y métricas desde fuera de tu red.

levelrail-cli apps env import your-app --file prod.env --dry-run
levelrail-cli apps secrets set your-app --env-file secrets.env
levelrail-cli apps apply your-app
curl --resolve YOUR_DOMAIN:443:SERVER_IP YOUR_DOMAIN_URL

El certificado es el punto flojo para pretender cero caída: la emisión pública exige que el dominio ya apunte al servidor, así que el runbook anticipa una ventana corta, salvo que subas tu propio certificado de antemano. Esto se conecta con lo que analizamos en publicar tu web gratis en Vercel.

Cambiás los registros, el sitio carga bárbaro desde tu notebook, lo mirás desde el celular con datos y también anda, pero el webhook de pagos sigue pegándole a Vercel, el callback de OAuth rebota porque nadie actualizó la URL en el proveedor y a la media hora te escribe el primer cliente. Por eso el dominio no se saca de Vercel hasta que la corrida en paralelo salga limpia.

¿Qué verificar antes de apagar Vercel y confiar en el nuevo servidor?

Corré las dos plataformas durante un ciclo de negocio completo, incluidos los crons semanales o mensuales, y apagá Vercel recién cuando pasen estos controles del runbook. Hasta entonces, Vercel es tu plan de rollback.

• Un deploy roto falla a propósito mientras el contenedor viejo sigue sirviendo.
• El rollback funciona desde la CLI y desde el dashboard.
• Están todas las claves de Production que existen en Vercel.
• Los NEXT_PUBLIC_* son correctos en el bundle desplegado.
• Los callbacks OAuth se actualizaron en cada proveedor.
• Los webhooks de pago apuntan a la URL nueva.
• Cada tarea programada corrió a horario.
• El certificado llegó y tiene alertas de vencimiento.
• Hay backup de la base y ensayaste el restore.
• Errores y latencia se comparan de forma aceptable con Vercel.

Propuesta editorial, no de la fuente: antes de dar por bueno el punto de los NEXT_PUBLIC_*, abrí el bundle desplegado en el navegador y buscá a mano un valor público conocido (por ejemplo, tu ID de analytics). Si aparece vacío o con el valor de otro entorno, el problema está en el build y no en el runtime.

Si el servidor va a estar en Argentina, un VPS o cloud de donweb.com es una opción a evaluar para el hosting; la fuente no lo prueba ni lo menciona, así que validá vos que cumpla lo que tu app necesita.

Si querés profundizar en esto, tenemos un artículo sobre migración a servidor propio con el paso a paso para hacerlo.

Si querés profundizar en esto, tenemos una guía para migrar Next.js a servidor propio y optimizar las imágenes con URLs presignadas.

Si el costo de los ISR writes te preocupa, mirá cómo es migrar fuera de Vercel y qué implica para tu proyecto.

Qué está confirmado y qué no

• Confirmado: Vercel no tiene importador automático, según el runbook.
• Confirmado: la lista de funciones sin reemplazo y la advertencia de que la emisión pública de certificados tuvo menos pruebas en campo.
• Confirmado: el README de Levelrail dice que no tiene versión estable y que no conviene correr cargas de producción todavía.
• Sin verificar: la malla WireGuard entre hosts figura sin comprobar en el README.
• Sin datos: no hay mediciones de costo ni de rendimiento frente a Vercel, ni migraciones de terceros documentadas.

Errores comunes

• Tratar NEXT_PUBLIC_* como variable de runtime. Se hornean en el build; commiteá un .env.production con los valores públicos.
• Copiar la columna Preview. Los valores válidos son los de Production.
• Sacar el dominio de Vercel temprano. Esperá a que la corrida paralela salga limpia.
• Asumir que el cron se traduce solo. Pasa de una ruta HTTP a un comando dentro del contenedor.
• Olvidarse de terceros. OAuth y webhooks de pago siguen apuntando a la URL vieja.

Preguntas Frecuentes

¿Cómo migro mi proyecto Next.js de Vercel a mi propio servidor?

Inventariá la configuración del panel, desplegá en una URL de prueba, cambiá el DNS con TTL bajo y corré ambas plataformas en paralelo. Vercel no tiene importador automático, así que todo es manual. Complementá con comparación de costos entre Vercel y Amplify.

¿Qué funciones de Vercel no puedo reemplazar en un servidor propio?

Según el runbook, no tienen reemplazo directo las Edge Functions, el CDN global y la optimización de imágenes en CDN, las analíticas del navegador, Blob/KV/Edge Config y el autoscaling. El middleware compatible con Node sí funciona.

¿Por qué mis variables NEXT_PUBLIC_ no funcionan después de migrar?

Porque next build las incorpora en el bundle durante la compilación, y la plataforma del runbook inyecta el env recién al iniciar el contenedor. Commiteá un .env.production con los valores públicos.

¿Cómo reemplazo los cron jobs de Vercel en un servidor propio?

Con tareas programadas que ejecutan un comando dentro del contenedor, no una ruta HTTP. El comando debe usar una herramienta que exista en tu imagen.

¿Cómo cambio el DNS de Vercel a mi servidor sin dejar el sitio caído?

Bajá los TTL a 60-300 segundos, probá con curl --resolve y tené el certificado listo. Si usás emisión pública, esperá una ventana corta; para evitarla, subí tu propio certificado antes del cambio.

Conclusión

Migrar de Vercel es un trabajo de inventario más que de código. Lo útil del runbook es la lista de lo que el panel hacía sin que lo notaras y el criterio de no apagar nada hasta pasar los chequeos. El autor lo cierra así: dejar una plataforma es fácil cuando anotás todo lo que hacía por vos sin que lo notaras.

Qué hacer: armá la tabla de inventario esta semana y revisá la lista de funciones sin reemplazo. Si ninguna te frena, probá en una URL de prueba, con Vercel como respaldo. Y mientras Levelrail siga sin versión estable (al 10 de octubre de 2026, según el runbook y su README), no lo pongas en producción sin esa corrida paralela.

Fuentes

• Leave Vercel for Your Own Server: A Next.js Migration Runbook – runbook original en dev.to
• glincker/levelrail – repositorio y README de Levelrail en GitHub
• Levelrail – sitio y documentación del proyecto