Despliegue para solopreneurs: Cloudflare, Vercel o Railway

El panel de despliegue muestra cuatro servicios: blog, tool-api, dashboard y worker-daily-report. Los dos primeros se ejecutan en Cloudflare, el tercero en Vercel y el último sigue entre Railway y Workers. Cada uno choca con algo distinto: builds, CPU de Workers, facturación de Vercel o la elección entre contenedor y función.

Un negocio de una sola persona suele combinar sitio de contenido, herramienta, panel SaaS y tareas programadas. La comparación útil no busca un ganador, sino el runtime adecuado para cada servicio y sus umbrales de costo y mantenimiento.

1. Cuatro servicios, cuatro límites diferentes

blog es un sitio Astro estático en Cloudflare Pages. Los cambios de contenido, estilo o configuración disparan builds y acercan el proyecto a los 500 mensuales del plan Free. Los 20 000 archivos aún no son problema, pero comentarios y búsqueda mediante Pages Functions consumen cuotas de Workers.

tool-api es una API ligera en Workers para acceso y persistencia. Con más tráfico, 100 000 solicitudes diarias pueden no bastar y las solicitudes intensivas pueden superar 10 ms de CPU. Workers Paid parte de 5 dólares mensuales, con solicitudes y CPU separados del hosting estático.

dashboard es una aplicación Next.js full-stack en Vercel. Los previews son cómodos, pero la página de uso separa Functions, Images, Builds, Analytics y otros productos. Cada asiento pagado adicional cuesta 20 dólares al mes. Hobby incluye 4 horas de Active CPU, 360 GB-hours de memoria provisionada y 1 millón de invocaciones.

worker-daily-report genera y envía un informe diario. Workers ejecuta código programado, pero una tarea larga o intensiva puede no caber en CPU y memoria. Railway ejecuta un proceso Node, aunque exige vigilar RAM, CPU, egress y volúmenes. Hobby cuesta 5 dólares e incluye 5 dólares de uso.

La regla común es separar por forma de carga. Contenido estático, funciones ligeras, aplicaciones completas y tareas largas no tienen que vivir en el mismo proveedor.

2. Límites principales de las cuatro plataformas

2.1 Cloudflare Pages: assets estáticos gratis, funciones en Workers

Cloudflare Pages sirve principalmente para alojar y distribuir assets estáticos. Los límites Free actuales incluyen:

• 500 builds al mes; los push de Git y builds manuales consumen la cuota.
• 20 000 archivos por sitio; vigila proyectos con muchas imágenes o páginas generadas.
• 25 MiB por asset; coloca videos y datos grandes en object storage.
• 100 custom domains por proyecto en Free.
• Timeout de build de 20 minutos.

Las solicitudes y CPU de Pages Functions cuentan en Workers, no en la cuota estática de Pages:

• Los assets estáticos se distribuyen dentro de los límites de Pages.
• Comentarios, búsqueda y proxies API usan cuotas y precios de Workers.
• Astro y Hugo encajan bien; en Next.js revisa el adapter y runtime actuales.

Pages es un buen inicio para sitios de contenido y herramientas estáticas. Muchas solicitudes dinámicas o cálculos complejos deben estimarse como una carga Workers aparte.

2.2 Cloudflare Workers: funciones ligeras con límites de solicitudes y CPU

Workers es el runtime de Cloudflare para API ligeras, lógica edge y backends de herramientas. Sus límites actuales incluyen:

• 100 000 solicitudes diarias en Free.
• 10 ms de CPU por solicitud HTTP en Free; esperar I/O de red no consume CPU.
• Suscripción Workers Paid de 5 dólares al mes.
• 10 millones de solicitudes mensuales incluidas en Standard.
• 30 millones de milisegundos CPU mensuales incluidos.
• 128 MB de memoria por isolate en Free y Paid.

Usos adecuados:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

• API ligeras para autenticación, consultas y lógica de negocio simple.
• Pages Functions para comentarios y búsqueda.
• Proxies API con caché, routing y autorización.

Usos inadecuados:

• Informes largos y procesamiento batch.
• Cálculo pesado, grandes datos en memoria o inferencia ML.
• Connection pools tradicionales que no encajan con isolates.

Workers sirve para el backend de una herramienta pequeña. Planea el crecimiento en solicitudes y CPU; procesos persistentes y tareas pesadas requieren otro runtime.

2.3 Vercel: excelente para Next.js, con más que un asiento en la factura

Vercel integra Next.js y preview deployments. Hobby incluye recursos de funciones, mientras otros consumos se controlan por separado:

• 4 horas de Active CPU.
• 360 GB-hours de Provisioned Memory.
• 1 millón de invocaciones de Functions.
• 0,0035 dólares por minuto CPU de build con on-demand concurrency o Elastic build machines.
• 20 dólares mensuales por asiento pagado adicional.
• 100 deployments diarios en Free y 6 000 en Pro.
• 5 000 uploads diarios en Free y 40 000 en Pro.

La factura puede contener varias categorías:

• Functions: CPU, memoria e invocaciones.
• Images: transformaciones, cache reads y cache writes.
• Builds: CPU bajo configuraciones facturables.
• Analytics: Web Analytics y Speed Insights.
• Observability: monitoreo por eventos y complementos.

Señales de alerta:

• Muchos previews aumentan builds y deployments; máquinas o concurrencia facturables añaden costo.
• Image Optimization tiene su propio uso incluido y precios bajo demanda.
• Analytics y Observability también se revisan por separado.

Vercel es un inicio práctico para un producto Next.js full-stack, pero el plan no equivale a la factura total. Controla cada categoría y asiento.

2.4 Railway: runtime de contenedores con cobro por recursos

Railway es un PaaS para servicios, workers y bases. Separa suscripción y uso de recursos:

• Hobby cuesta 5 dólares y Pro 20 dólares al mes.
• Hobby incluye 5 dólares de uso.
• Pro incluye 20 dólares de uso.
• RAM cuesta 10 dólares por GB-mes.
• CPU cuesta 20 dólares por vCPU-mes.
• Network egress cuesta 0,05 dólares por GB.
• Volume storage cuesta 0,15 dólares por GB-mes.
• Free permite por defecto 0,5 GB RAM, 1 vCPU y un volumen de 0,5 GB por servicio.

Aún hacen falta decisiones operativas:

• Vigilar RAM, CPU, egress y volúmenes reales.
• Configurar alertas de recursos y logs.
• Conocer la ventana de image retention para rollback y rebuild.
• Definir health checks, reinicios y copias.

Umbrales de costo:

• El uso por encima del crédito de 5 o 20 dólares se cobra como diferencia.
• Un servicio activo sigue consumiendo RAM, CPU y almacenamiento.
• Egress y volúmenes persistentes crecen de forma independiente.

Railway sirve para servicios Node, tareas de fondo y bases. Reduce el trabajo de infraestructura, no la responsabilidad del servicio.

3. Tabla de decisión por tipo de carga

3.1 Sitios de contenido y documentación

Un sitio de contenido usa sobre todo assets estáticos y pocas funciones dinámicas.

Para Astro o Hugo, Pages ofrece distribución global y límites suficientes al inicio. Consulta la guía de Cloudflare Pages y los límites de Cloudflare Free.

En Next.js SSG, revisa el soporte actual en vez de repetir una afirmación antigua. Vercel ofrece el flujo nativo; Cloudflare sigue siendo atractivo para una salida principalmente estática.

Comentarios y búsqueda pueden usar Pages Functions, pero solicitudes y CPU pertenecen a Workers. Separa entrega estática y ejecución dinámica.

3.2 Herramientas estáticas y dinámicas

Un generador o convertidor puede funcionar en el navegador; acceso y datos persistentes lo convierten en producto dinámico.

Una herramienta de navegador encaja en Pages. Una API pequeña encaja en Workers si las solicitudes son ligeras y compatibles con isolates.

Una herramienta Next.js full-stack aprovecha Vercel, pero previews, imágenes, runtime de función y monitoreo necesitan presupuestos separados.

3.3 Paneles SaaS

Un panel SaaS necesita lógica, autorización, acceso a datos y a menudo colaboración.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Vercel es el inicio directo para Next.js. Revisa Functions, Images, preview Builds, Analytics, Observability y asientos sin considerar Pro como todo incluido. La comparativa de precios de Cloudflare añade contexto.

Para otros frameworks, compara adapters y funciones runtime actuales. Workers favorece lógica edge; Vercel, frameworks serverless compatibles.

La base de datos es otra decisión. Supabase, Postgres gestionado, D1 y Railway Volumes tienen sus propios límites de costo y fiabilidad.

3.4 Tareas largas y servicios en contenedores

Informes, archivos, consumers de colas y API persistentes necesitan otro runtime que una función corta.

Railway ejecuta procesos Node persistentes en un runtime completo. A cambio, gestiona límites, logs, health checks, reinicios y copias.

Un Railway Volume conserva datos, pero el precio no sustituye una estrategia de base. Se necesitan backups y pruebas de restauración.

Para tareas programadas, define alerta y perfil máximo de recursos. Un worker permanente o intensivo puede superar el crédito Hobby.

4. Modelos de costo y umbrales de alerta

4.1 Modelo de Cloudflare

Cloudflare separa la entrega estática de Pages y la ejecución dinámica de Workers.

Assets estáticos de Pages:

• Se distribuyen sin costo de transferencia por uso dentro de los límites de Pages.
• Cerca de 500 builds mensuales, reduce deployments innecesarios.
• Cerca de 20 000 archivos, mueve assets grandes a object storage.
• Pages Functions usa cuotas Workers, no un cupo dinámico ilimitado aparte.

Ejecución Workers:

• Free incluye 100 000 solicitudes/día y 10 ms CPU por solicitud HTTP.
• Workers Paid comienza con 5 dólares de suscripción mensual.
• Standard incluye 10 millones de solicitudes al mes.
• Standard incluye 30 millones de milisegundos CPU al mes.

Umbrales:

• Los límites duros de Pages pueden bloquear nuevos builds.
• Más solicitudes o CPU requieren pasar de Workers Free a Paid.
• Pages estático gratis no significa Pages Functions ilimitado.

Un inicio común combina Pages con Workers Free. Define el cambio a Paid antes de que tráfico o CPU lo impongan.

4.2 Modelo de Vercel

Vercel separa varios recursos de infraestructura y experiencia de desarrollo.

Recursos Function de Hobby:

• 4 horas de Active CPU.
• 360 GB-hours de Provisioned Memory.
• 1 millón de invocaciones.
• 0,0035 dólares por minuto CPU con on-demand concurrency o Elastic build machines.

Categorías de uso:

• Functions: Active CPU, memoria provisionada e invocaciones.
• Images: transformaciones, cache reads y cache writes.
• Builds: preview y producción bajo configuraciones facturables.
• Analytics: Web Analytics y Speed Insights.
• Observability: eventos y monitoreo.

Asientos:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

• Cada asiento pagado adicional cuesta 20 dólares al mes.
• El asiento no absorbe excesos de infraestructura o complementos.

Umbrales:

• Los previews frecuentes aumentan builds y deployments.
• Las imágenes tienen cupos y precios propios.
• Analytics y Observability se revisan por separado.
• CPU, memoria e invocaciones se comparan con el plan vigente.

Lee la página de uso categoría por categoría. Ahorrar tiempo con Next.js puede coexistir con una factura de varias líneas.

4.3 Modelo de Railway

Railway combina suscripción y recursos medidos.

Planes y uso incluido:

• Hobby cuesta 5 dólares e incluye 5 dólares de uso.
• Pro cuesta 20 dólares e incluye 20 dólares de uso.
• Free ofrece hasta 0,5 GB RAM, 1 vCPU, volumen de 0,5 GB y un pequeño crédito mensual.

Tarifas:

• RAM: 10 dólares por GB-mes.
• CPU: 20 dólares por vCPU-mes.
• Network egress: 0,05 dólares por GB.
• Volume storage: 0,15 dólares por GB-mes.
• Las imágenes eliminadas solo permanecen durante la retention del plan.

Umbrales:

• El uso sobre el crédito se cobra como diferencia.
• Un servicio sin detener sigue consumiendo RAM, CPU y almacenamiento.
• Egress y volúmenes pueden crecer sin relación con la suscripción.

Railway evita parte de la configuración de un VPS, no el monitoreo. Configura alertas y conoce el rollback antes de producción.

5. Mantenimiento: frecuencia, logs, rollback y colaboración

Las cuotas de build y deployment importan en proyectos con cambios frecuentes. La colaboración añade asientos y permisos.

Frecuencia de deployments y builds

• Cloudflare Pages Free permite 500 builds mensuales y uno simultáneo; los preview builds de Git consumen la cuota.
• Vercel permite 100 deployments/día en Free y 6 000 en Pro; muchos previews también elevan los builds.
• Railway no publica aquí un contador equivalente, pero las imágenes eliminadas solo siguen disponibles durante la ventana de rollback del plan.

Vigila builds de Pages y deployments de Vercel antes de frenar iteraciones. Comprueba también si la máquina o concurrencia de Vercel es facturable.

Logs, rollback y acceso del equipo

• Cloudflare Pages ofrece build logs, historial y rollback; revisa las condiciones actuales de cuentas y permisos.
• Vercel ofrece previews, historial, logs, Analytics y asientos pagados; cada asiento adicional cuesta 20 dólares al mes.
• Railway ofrece logs y métricas; health checks, reinicios, copias y colaboración deben configurarse de forma explícita.

Elige el flujo que quite más trabajo repetitivo del servicio principal. En Next.js importan los previews; en un sitio de contenido, los builds estáticos previsibles.

6. Siguiente paso: bases de datos, almacenamiento y CI/CD

La plataforma de despliegue es solo una capa. Base de datos, almacenamiento, CI/CD, monitoreo y alertas necesitan decisiones propias. El siguiente artículo compara Supabase, Postgres, Railway Volumes y object storage.

El objetivo no es reducir el número de proveedores, sino colocar cada carga en un runtime cuyos límites, factura y responsabilidad sean claros antes de crecer.