Cómo migrar de Cloudflare Workers a un VPS

Para una migración exitosa de Cloudflare Workers a un VPS, es necesario trasladar la lógica de las aplicaciones al entorno de ejecución de Node.js o Bun, reemplazar los almacenamientos propietarios KV, D1 y R2 por análogos open-source (Redis, PostgreSQL, MinIO) y configurar un reverse proxy, lo que permite eliminar las restricciones de tiempo de ejecución de CPU y reducir los costos al escalar en servidores con precios desde $5 al mes.

La transición de soluciones Serverless a servidores propios es una etapa natural en el desarrollo de un proyecto cuando las limitaciones de la plataforma comienzan a obstaculizar el crecimiento o el presupuesto. Cloudflare Workers atrae por su facilidad de inicio, pero a medida que la lógica se vuelve más compleja, los desarrolladores se enfrentan a límites estrictos de uso de CPU (50ms en el plan gratuito y hasta 30s en el de pago), la falta de soporte para muchos paquetes NPM y una API específica. En este artículo, analizaremos cómo realizar una migrate from cloudflare workers a un VPS, manteniendo el rendimiento y la fiabilidad.

Razones para migrate from cloudflare workers a recursos dedicados

El principal motor de la migración suele ser la viabilidad económica y las limitaciones técnicas del entorno de ejecución V8 Isolates. A diferencia de las máquinas virtuales estándar, los Workers funcionan en un entorno restringido donde no hay acceso al sistema de archivos ni a una conexión de socket completa sin capas adicionales.

Límites de CPU y memoria

En Cloudflare Workers, el tiempo de ejecución del código (CPU time) está estrictamente limitado. Si su script realiza cálculos matemáticos complejos, procesamiento de imágenes o criptografía pesada, alcanzará rápidamente el límite de 50ms. En un VPS, obtiene acceso total a los recursos del procesador (por ejemplo, 2-4 núcleos a 3.0+ GHz) sin interrupciones artificiales. Esto es especialmente crítico si planea usar el servidor para tareas de aprendizaje automático, sobre lo cual puede leer más en el artículo Bare-metal vs VPS para ML inference en CPU: qué es más rentable.

Costo con tráfico elevado

Cloudflare cobra por el número de solicitudes. Al alcanzar millones de solicitudes por día, las facturas comienzan a crecer exponencialmente. El alquiler de un VPS con un precio fijo ($10–$20 al mes) permite procesar un tráfico prácticamente ilimitado, restringido solo por el ancho de banda de la red (generalmente 1 Gbps) y la potencia del hardware. Esta situación también es común al usar otras soluciones PaaS, por lo que muchos buscan formas de cómo mudarse de Railway a VPS en 2026.

Elección del stack: Node.js o Bun como workers alternative

Cuando busca una workers alternative adecuada, la elección del entorno de ejecución (runtime) se vuelve un punto clave. Cloudflare Workers utiliza un subconjunto de API cercano al del navegador (Fetch API), por lo que su código no se ejecutará "tal cual" en un Node.js estándar sin adaptación.

Bun: la experiencia más cercana a Workers

Bun es un runtime moderno que admite de forma nativa Fetch API, Request y Response. Esto lo convierte en el candidato ideal para la migración. Un ejemplo sencillo de un servidor en Bun que reemplaza la lógica de un Worker:

Bun.serve({
  port: 3000,
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/api") {
      return new Response(JSON.stringify({ status: "ok" }), {
        headers: { "Content-Type": "application/json" },
      });
    }
    return new Response("Not Found", { status: 404 });
  },
});

Node.js y Fastify/Hono

Si necesita la máxima estabilidad y un ecosistema gigante de librerías, Node.js sigue siendo el estándar. Para minimizar los cambios en el código, se recomienda utilizar el framework Hono. Fue desarrollado originalmente para entornos Edge (Workers), pero funciona perfectamente en Node.js mediante adaptadores. Esto facilita significativamente la workers migration, ya que el enrutamiento y el middleware permanecen idénticos.

Reemplazo de la infraestructura de Cloudflare (KV, D1, R2) en un VPS

La parte más difícil de la mudanza es reemplazar los servicios de almacenamiento propietarios de Cloudflare por sus equivalentes open-source. En un VPS, usted mismo gestiona los datos, lo que ofrece más flexibilidad pero requiere configurar respaldos.

Alternativa a Workers KV: Redis o Dragonfly

Workers KV es un almacenamiento de clave-valor con consistencia eventual (eventual consistency). En un VPS, la mejor opción será Redis. Proporciona una latencia de menos de 1 ms y admite tipos de datos complejos (listas, conjuntos), algo que no existe en KV.

• Instalación: sudo apt install redis-server
• Volumen de memoria: Depende de su plan de VPS (desde 2 GB de RAM).
• Rendimiento: Hasta 100,000+ operaciones por segundo en un solo núcleo.

Reemplazo de D1 por PostgreSQL o SQLite

Cloudflare D1 se basa en SQLite. Si su aplicación es pequeña, puede seguir usando SQLite localmente en el VPS. Sin embargo, para sistemas de alta carga, es mejor pasar a PostgreSQL. Esto le dará transacciones completas, funciones de ventana y alta fiabilidad. El proceso de migración de bases de datos a menudo coincide con el descrito en la guía sobre cómo mudarse de Fly.io a VPS.

R2 → MinIO o almacenamiento compatible con S3

Cloudflare R2 es S3 sin cargos por transferencia de datos salientes (egress). En un VPS, puede desplegar MinIO. Es un almacenamiento de objetos self-hosted que es totalmente compatible con la API de AWS S3. Si su VPS tiene discos NVMe de 50-100 GB, obtendrá un aumento colosal en la velocidad de lectura/escritura en comparación con una nube remota.

Plan paso a paso para la workers migration: del código al despliegue

El proceso de workers migration requiere un enfoque sistemático para evitar tiempos de inactividad (downtime). Recomendamos usar Docker para empaquetar la aplicación, lo que la hará portátil e independiente del entorno del servidor.

1. Adaptación del código: Reemplace los objetos globales de Cloudflare (por ejemplo, env.MY_KV) por variables de entorno o archivos de configuración. Use la librería dotenv para Node.js.
2. Creación del Dockerfile: Escriba la configuración para construir la imagen. Ejemplo para Bun:

   
   FROM oven/bun:latest
   WORKDIR /app
   COPY package.json .
   COPY bun.lockb .
   RUN bun install
   COPY . .
   EXPOSE 3000
   CMD ["bun", "run", "index.ts"]
           

3. Configuración de la base de datos: Despliegue PostgreSQL o Redis en contenedores Docker o instálelos directamente en el SO.
4. Transferencia de datos: Exporte los datos de KV a través de Wrangler CLI e impórtelos en Redis. Para D1, use un volcado SQL (dump).

Muchos desarrolladores que deciden migrate from cloudflare workers notan que el uso de Docker facilita la vida no solo en el despliegue, sino también en el desarrollo local. Se toman pasos similares cuando la tarea es cómo mudarse de Vercel/Netlify a VPS.

Configuración del nivel de red al pasar de cloudflare to vps

Al usar Cloudflare Workers, no tenía que preocuparse por los certificados SSL, la protección DDoS y el equilibrio de carga. Al pasar de cloudflare to vps, estas tareas recaen sobre sus hombros (o sobre la configuración de Nginx).

Nginx como Reverse Proxy

Nginx recibirá las solicitudes entrantes y las redirigirá a su aplicación (Node.js/Bun) que se ejecuta en un puerto local. Esta es una práctica estándar para garantizar la seguridad y la posibilidad de escalado horizontal.

server {
    listen 80;
    server_name api.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

SSL y seguridad

Para obtener certificados SSL gratuitos, use Certbot (Let's Encrypt). También se recomienda dejar Cloudflare en modo "Proxy" (nube naranja) para usar su protección DDoS y CDN, pero dirigiendo el tráfico a la IP de su nuevo VPS. De esta manera, conserva las ventajas de la red global de Cloudflare, pero se deshace de las limitaciones de los Workers.

Comparación de costo y rendimiento

A continuación se presenta una tabla comparativa de características y costos al usar Cloudflare Workers y un VPS típico de Valebyte. Los datos se basan en promedios para proyectos con una carga de 5-10 millones de solicitudes al mes.

Característica	Cloudflare Workers (Paid)	VPS (Standard Plan)	Ventaja
CPU Time Limit	30 segundos	Sin límites	VPS
Memoria RAM	128 MB	2 GB - 16 GB	VPS
Costo (10M req)	~$5.00 + costos KV/D1	$5.00 - $12.00 (fijo)	VPS (al crecer)
Almacenamiento	KV / D1 (límites de pago)	SSD/NVMe (incluido)	VPS
Cold Starts	0-50ms	0ms (siempre activo)	VPS

Como se ve en la tabla, con un precio base comparable, el VPS ofrece órdenes de magnitud más de recursos. Esto es especialmente importante para aplicaciones que requieren una conexión constante (WebSockets), que en Workers cuestan significativamente más o tienen limitaciones en el tiempo de vida de la sesión.

Monitoreo y logging después de la migración

En Cloudflare Workers, los logs están disponibles a través del panel de control o wrangler tail. En un VPS, necesitará configurar su propio sistema de monitoreo. Para empezar, es suficiente con PM2 para gestionar los procesos de Node.js y ver los logs en tiempo real.

• PM2: Reinicia automáticamente la aplicación en caso de fallos y permite ver los logs con el comando pm2 logs.
• Grafana + Prometheus: Para un monitoreo profundo de la carga de CPU, RAM y tráfico de red.
• Uptime Kuma: Una herramienta self-hosted sencilla para verificar la disponibilidad de su API.

No olvide que ser dueño de la infraestructura le da control total sobre los datos. Puede almacenar logs durante años para auditorías de seguridad sin pagar de más por el volumen de almacenamiento en la nube. Si anteriormente usó Heroku, el proceso de configuración de monitoreo en un VPS le resultará familiar; más detalles sobre esto en el artículo Cómo mudarse de Heroku a VPS en 2026: guía paso a paso.

Latency y geodistribución

Uno de los principales argumentos a favor de Workers es el "Edge": la ejecución del código lo más cerca posible del usuario. Al mudarse a un solo VPS, la latencia (latency) para los usuarios del otro lado del mundo puede aumentar. Sin embargo, para la mayoría de las aplicaciones, una latencia de 100-150 ms no es crítica, mientras que la velocidad de la base de datos en el mismo servidor (localmente) es significativamente mayor que consultar un KV o D1 remoto desde una Edge-function.

Si la baja latencia es crítica, puede alquilar dos VPS económicos en diferentes regiones (por ejemplo, Europa y EE. UU.) y configurar GeoDNS a través del mismo Cloudflare. Esto seguirá siendo más barato y potente que usar planes Enterprise de plataformas Serverless.

Conclusiones

La migración de Cloudflare Workers a un VPS está justificada si su aplicación requiere más de 50 ms de tiempo de CPU, acceso al sistema de archivos o costos predecibles con grandes volúmenes de tráfico. La opción óptima para trasladar el código será el entorno Bun o Node.js con el framework Hono, y como base de datos, una combinación de PostgreSQL y Redis en un servidor con disco NVMe.