Cómo migrar de Vercel/Netlify a un VPS

Para una transición exitosa de Vercel o Netlify a un VPS, basta con alquilar un servidor virtual con 2-4 GB de RAM y un procesador de al menos 2 núcleos, configurar la contenerización con Docker para su aplicación (Next.js, Nuxt o SvelteKit) y desplegar un reverse proxy como Nginx o Caddy; esto permitirá reducir los costos de hosting entre 5 y 10 veces y eliminar por completo los límites de ancho de banda y tiempo de ejecución de funciones.

¿Por qué migrate from vercel netlify se convierte en una necesidad para proyectos en crecimiento?

La razón principal por la que los desarrolladores inician un migrate from vercel netlify es el sistema de precios impredecible al escalar. Las plataformas PaaS (Platform as a Service) son excelentes al inicio, ofreciendo un nivel gratuito (Hobby/Free tier), pero tan pronto como el proyecto supera los límites, el costo de mantener la infraestructura crece exponencialmente.

Economía de escala y cargos ocultos

En Vercel y Netlify, usted paga por "Seats" (miembros del equipo), por el ancho de banda (Bandwidth) que exceda el límite y por el tiempo de ejecución de las Serverless functions. Por ejemplo, un exceso de tráfico de 100 GB puede costar $40, mientras que en un VPS obtiene terabytes de tráfico incluidos en el precio. Si su proyecto está creciendo activamente, el hosting para una startup MVP en 2026 basado en VPS se convierte en una opción mucho más lógica desde el punto de vista de la unit economics.

Limitaciones técnicas de la arquitectura Serverless

El uso de Edge functions y el procesamiento Serverless impone restricciones severas:

• Límite de tiempo de ejecución (generalmente de 10 a 30 segundos en los planes gratuitos/Pro).
• El problema del "Cold Start" (inicio en frío), donde la primera solicitud después de un periodo de inactividad se procesa con un retraso de varios segundos.
• Memoria RAM limitada para la ejecución de funciones (generalmente entre 128 MB y 1024 MB).
• Dificultad para conectarse a bases de datos tradicionales debido al agotamiento del pool de conexiones.

Comparación de características: Jamstack VPS frente a plataformas PaaS

Al mudarse a un jamstack vps, usted cambia la comodidad de "un solo botón" por un control total sobre los recursos del sistema. A continuación, se presenta una tabla que muestra claramente la diferencia en recursos y costos entre un plan Pro típico de PaaS y un VPS estándar de Valebyte.

Característica	Vercel / Netlify (Pro)	VPS (Valebyte Standard)
Costo mensual	desde $20 por usuario + cargos extra	$10 - $25 (fijo)
Ancho de banda (TB)	1 TB (luego $40 por cada 100GB)	De 5 TB a 32 TB o Unmetered
Memoria RAM	Compartida (Serverless)	4 GB - 16 GB (Dedicada)
Tiempo de ejecución (Timeout)	10-60 segundos	Sin límites
Acceso al SO (Root)	No	Acceso SSH total

Es importante tener en cuenta que al elegir un servidor vale la pena prestar atención al tipo de tráfico. Puede leer más sobre esto en el artículo Bandwidth VPS: TB/mes vs unmetered — qué elegir.

Vercel migration: particularidades del traslado de aplicaciones Next.js

El proceso de vercel migration para Next.js es el más solicitado, ya que Vercel es el hogar "nativo" de este framework. Sin embargo, Next.js funciona perfectamente en cualquier servidor Linux gracias al modo standalone.

Configuración del modo standalone en Next.js

Para que una aplicación Next.js funcione de manera eficiente en un VPS, es necesario modificar el archivo next.config.js. Esto permitirá que el framework compile solo los archivos necesarios, minimizando el tamaño de la imagen Docker o de la carpeta del proyecto.

module.exports = {
  output: 'standalone',
}

Después de ejecutar el comando npm run build, Next.js creará una carpeta .next/standalone, que se puede ejecutar mediante node server.js. Esto elimina la necesidad de instalar todos los node_modules en el servidor de producción, lo que ahorra espacio en disco y acelera el despliegue.

Sustitución de Vercel Image Optimization

En Vercel, la optimización de imágenes funciona de forma nativa a través de su API propietaria. Al mudarse a un VPS, debe asegurarse de que la biblioteca sharp esté instalada en el sistema. Next.js comenzará a usarla automáticamente para redimensionar y convertir imágenes a WebP/AVIF sobre la marcha.

npm install sharp

Netlify migration: traslado de SvelteKit y Nuxt

Al realizar una netlify migration, los desarrolladores a menudo se encuentran con que utilizaban complementos específicos de Netlify (Forms, Identity, Functions). En un VPS, estas funciones deberán reemplazarse por alternativas Open Source o microservicios propios.

Adaptadores para SvelteKit y Nuxt

En el ecosistema Jamstack, los frameworks utilizan adaptadores para el despliegue. Para mudarse de Netlify a un VPS, es necesario cambiar el adaptador:

1. En SvelteKit: reemplace @sveltejs/adapter-auto o @sveltejs/adapter-netlify por @sveltejs/adapter-node.
2. En Nuxt: asegúrese de que la compilación esté configurada con el preset node-server en nuxt.config.ts.

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    preset: 'node-server'
  }
})

Si anteriormente utilizaba Heroku para el backend de su aplicación Jamstack, le será útil nuestra guía sobre cómo mudarse de Heroku a un VPS en 2026, ya que los principios de gestión de procesos Node.js son similares.

Configuración de la infraestructura en el VPS: Docker y Nginx

Para crear un entorno jamstack vps completo, se recomienda utilizar Docker. Esto garantiza que su aplicación funcione de la misma manera en su máquina local que en el servidor de Valebyte.

Ejemplo de Dockerfile para un framework JS moderno

A continuación se muestra un Dockerfile universal, optimizado para Next.js o Nuxt:

FROM node:20-alpine AS base

FROM base AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM base AS runner
WORKDIR /app
ENV NODE_ENV production
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

EXPOSE 3000
CMD ["node", "server.js"]

Configuración de Nginx como reverse proxy

Nginx recibirá el tráfico entrante por los puertos 80/443 y lo redirigirá al contenedor Docker. Esto también permite configurar fácilmente SSL a través de Let's Encrypt.

server {
    listen 80;
    server_name tudominio.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Para proyectos que requieren una alta potencia de cálculo, por ejemplo, para procesamiento de datos o inferencia de ML, vale la pena considerar Bare-metal vs VPS para inferencia de ML en CPU, para obtener el máximo rendimiento del hardware.

Automatización CI/CD: reemplazando el "Push to Deploy"

Una de las principales ventajas de Vercel es el despliegue automático al hacer push en GitHub. En un VPS, esto se implementa a través de GitHub Actions o GitLab CI. El proceso funciona así:

1. Usted sube el código al repositorio.
2. GitHub Action compila la imagen Docker.
3. La imagen se sube a un Docker Registry (por ejemplo, GitHub Packages).
4. La Action se conecta a su VPS por SSH y ejecuta docker-compose pull && docker-compose up -d.

Esto toma entre 1 y 2 minutos más que en Vercel, pero le otorga un control total sobre el proceso de compilación y pruebas. Ya no dependerá de las colas de compilación del proveedor PaaS, que pueden estar saturadas en horas pico.

Rendimiento: Edge vs VPS Centralizado

A menudo se dice que las Edge functions de Vercel son más rápidas debido a su proximidad al usuario. Sin embargo, en la práctica, esto solo es cierto para el contenido estático. Si su aplicación trabaja activamente con una base de datos ubicada en una región específica (por ejemplo, en Alemania o EE. UU.), una Edge function desde Singapur seguirá teniendo que hacer una solicitud a esa base de datos, creando una latencia enorme (TTFB).

Alojar la aplicación en un VPS potente en el mismo centro de datos donde se encuentra su base de datos a menudo ofrece mejores resultados para aplicaciones dinámicas. Se eliminan las latencias de red entre la "función" y los "datos". Si está migrando desde soluciones en la nube como AWS, le recomendamos consultar el material sobre cómo mudarse de AWS Lightsail a un VPS en 2026.

Seguridad y monitoreo después de la migración

Al pasar a un VPS, usted asume la responsabilidad de la seguridad del SO. El conjunto mínimo de acciones incluye:

• Desactivar el inicio de sesión por contraseña en SSH (solo mediante llaves).
• Configurar el firewall (UFW o iptables), abriendo solo los puertos 22, 80 y 443.
• Instalar Fail2Ban para protegerse contra ataques de fuerza bruta.
• Actualizar regularmente los paquetes (apt update && apt upgrade).

Para el monitoreo, puede utilizar soluciones sencillas como Uptime Kuma (alternativa self-hosted a UptimeRobot) o la combinación de Prometheus + Grafana para rastrear la carga de CPU y RAM en tiempo real.

Conclusiones

La migración de Vercel o Netlify a un VPS está justificada para cualquier proyecto con un tráfico superior a 500 GB al mes o cuando sea necesario utilizar software de sistema específico. La opción óptima para este traslado es un VPS con 4 GB de memoria RAM y disco NVMe, lo que garantizará un funcionamiento estable de las aplicaciones Next.js/Nuxt sin las limitaciones de la arquitectura Serverless.