3 formas de desplegar tu proyecto web que debes conocer

Hablar de despliegue de aplicaciones es un término bastante genérico, porque dependiendo del proyecto que estés desarrollando puede que necesites solamente hosting de archivos estáticos, alojamiento de un Platform as a Service, o quizás solo un servidor en blanco al que tengas que configurarle todo desde cero.

Si nunca has escuchado estos términos, o has escuchado hablar de funciones serverless, hosting estático, Platform as a Service, Infrastructure as a Service y crees que son conceptos muy ajenos a lo que estás desarrollando, este artículo es para ti. Voy a explicarte de qué trata cada uno y, muy probablemente, cuando despliegues tu próximo proyecto vas a terminar usando uno de estos enfoques.

Por qué necesitas entender esto

En internet hay decenas de servicios que tratan de venderte hosting de aplicaciones, pero no todas las aplicaciones tienen los mismos requerimientos. Si estás enfocado en aprender desarrollo, este es uno de los temas vitales que debes conocer al momento de pasar a producción, porque escoger mal la plataforma puede salirte caro, lento o, peor aún, ambos.

Existen tres enfoques comunes con los que prácticamente puedes desplegar cualquier tipo de proyecto:

1. Hosting de archivos estáticos
2. Platform as a Service (PaaS)
3. Infrastructure as a Service (IaaS)

Hay más variantes en base a estos, pero estos tres son los que más te van a ayudar a terminar la mayoría de proyectos. Veamos cada uno.

1. Hosting de archivos estáticos

Este enfoque consiste, básicamente, en alojar archivos como HTML, CSS y JavaScript. Algunos servicios típicos en esta categoría son:

• Netlify
• Cloudflare Pages
• AWS S3

El alojamiento de este tipo de archivos es muy barato y es una de las razones principales por las que se escoge. De hecho, hay servicios que prácticamente te lo regalan o te dan mucha capacidad gratuita para alojar proyectos de este estilo.

¿Qué es un CDN?

Si miras los servicios anteriores vas a notar que casi todos mencionan algo llamado CDN, abreviado de Content Delivery Network. Una CDN es una red que se encarga de servir tu contenido lo más cercano posible a tu usuario.

Es decir, tú subes tus archivos estáticos a la plataforma, y estos se replican en varias ubicaciones del mundo. Cuando alguien accede a tu sitio, no lo descarga del servidor más lejano, sino del más cercano que tenga una copia. Esto hace dos cosas importantes:

• El contenido se sirve mucho más rápido.
• Consume menos recursos para distribuirlo.

Las CDN no solo sirven páginas web. Servicios de streaming como Spotify o Netflix también las utilizan para servir audio, video y otros contenidos. Pero cuando hablamos de sitios web, este tipo de hosting suele ser el más barato.

Limitación principal

Con este enfoque solo estamos hablando de código de frontend. No estás alojando lógica de backend ni una base de datos directamente. Si tu proyecto necesita un backend, vas a necesitar combinar este hosting con otra cosa (lo veremos más adelante con las funciones serverless), o saltar al siguiente enfoque.

2. Platform as a Service (PaaS)

Los Platform as a Service son plataformas que se encargan de ejecutar tu código de backend e instalar todo lo necesario por ti. Algunas de las más populares son:

• Railway
• Vercel
• Render
• Fly.io
• Cloudflare Workers

Todas estas tienen algo en común: te conectas con tu cuenta de GitHub, seleccionas el proyecto que quieres desplegar, y la plataforma se encarga del resto. Puedes incluso crear bases de datos dentro de la misma plataforma.

Costos

El costo aproximado de muchas de estas plataformas ronda los $20 mensuales como punto de partida. Si bien algunas tienen planes gratuitos, por lo general tienen un costo casi desde el primer día si quieres usarlas en serio.

Ventaja: escalado automático

Algo bueno de los PaaS es que cuando tu proyecto crece y consume más recursos, la plataforma escala por ti. Te dan más memoria RAM, más CPU, más espacio en disco o más tráfico de red sin que tengas que configurar nada manualmente.

Desventaja: el precio escala contigo

Estas plataformas pueden empezar baratas, pero a medida que tu proyecto va creciendo (tus primeros 1.000 usuarios, luego 10.000, después 100.000) no solo escalan los recursos, también escala el precio. Pueden volverse caras cuando creces mucho.

El "vendor lock-in"

Algo a considerar es que muchos de estos proveedores buscan que dependas de ellos. Si tu proyecto se vuelve exitoso, es probable que termines usando varios de sus servicios integrados, y migrar después se vuelve un trabajo enorme.

Lo que hacen muchos proveedores es ofrecerte una especie de partnership o contrato cuando llegas a cierto volumen, en el que reduces el costo a cambio de seguir creciendo dentro de su infraestructura. Esto te fideliza más y hace que tu aplicación dependa enteramente de esa plataforma. Es algo que vale la pena tener en mente desde el inicio.

Diferencias entre las plataformas

Aunque suelen agruparse, no son idénticas. Por ejemplo:

• Railway te permite desplegar bases de datos como PostgreSQL, Redis, MySQL y MongoDB junto con tu aplicación.
• Vercel se enfoca más en el frontend y en backend serverless, pero tiene integraciones con servicios externos como MongoDB Atlas, Upstash Redis o Neon para la base de datos.
• Cloudflare Workers despliega lógica de backend dentro de la nube de Cloudflare, pero con su propio modelo de ejecución.

Para proyectos pequeños o que están empezando con una base de datos (que es la mayoría), recomiendo usar un PaaS. Personalmente uso bastante Railway, aunque Vercel también es muy popular.

3. Infrastructure as a Service (IaaS)

Este enfoque es lo que comúnmente se conoce como VPS, abreviado de Virtual Private Server. Si te suena complicado, piénsalo simplemente como un computador virtual al que tú le instalas todo: el sistema operativo, los programas, las dependencias, todo.

Algunos proveedores comunes:

• AWS EC2
• Azure
• Digital Ocean (sus droplets)
• Google Cloud
• OVH
• Vultr
• Akamai

Cuándo usar un VPS

Este es el enfoque más común cuando necesitas:

• Control total sobre el entorno.
• Lenguajes o entornos poco comunes (Rust, C, C++ o variaciones de intérpretes que no son típicos en PaaS).
• Workers, cron jobs o sistemas de notificaciones que necesitan estar ejecutándose constantemente.
• Múltiples aplicaciones en un mismo servidor, compartiendo recursos.

Sobre este último punto: los PaaS están diseñados para "escuchar y responder", por lo que tareas en segundo plano que se quedan corriendo permanentemente no encajan bien en su modelo. Para eso es preferible un VPS.

Por qué los PaaS no soportan todos los lenguajes

Los Platform as a Service se basan en archivos de configuración para construir tu proyecto. Railway tenía un proyecto llamado Nixpacks (ahora Railpack) que detectaba automáticamente el lenguaje y construía el entorno por ti. Esto funciona muy bien para Node, Python, Ruby, .NET, Deno y similares.

Pero si tu proyecto está en un lenguaje menos popular, vas a notar que desplegarlo en un PaaS no es tan sencillo. La razón es que el PaaS trata de ser un entorno común para todos, y cuando sales de lo común, te conviene un VPS.

Mi enfoque personal con clientes

Llevo bastantes años haciendo desarrollos para clientes y desplegar en VPS para múltiples proyectos puede volverse tedioso: conflictos de puertos, distintas bases de datos, escalado manual, costos cuando un cliente crece...

Por eso, en los últimos años, mi enfoque ha sido no ocuparme de la infraestructura y usar un PaaS donde el propio cliente paga su hosting. Si usa poco, paga poco. Si usa mucho, paga más.

Yo siempre lo comparo con construir una casa: a ti te pagan por construirla, pero no le cobras al cliente la luz, el agua o el mantenimiento. Eso ya viene incluido por la persona que vive ahí dentro.

Funciones serverless: el complemento de los estáticos

Si tu frontend está en un hosting estático y necesitas algo de lógica de backend (un formulario, enviar un correo, guardar algo en una base de datos), no necesitas crear un backend completo. Para eso existen las funciones serverless.

Una función serverless es básicamente una pequeña porción de código (típicamente JavaScript, aunque puede ser otros lenguajes) que se ejecuta solo cuando alguien la llama. Algunas plataformas:

• Netlify Functions
• Cloudflare Functions
• Supabase Edge Functions (que por debajo usa Deno Deploy)

Casos de uso típicos

• Un formulario HTML que envía datos a algún lado.
• Generar una imagen aleatoria.
• Enviar un correo cuando alguien se registra.
• Guardar algo en una base de datos y responder.

Cada plataforma tiene su propia forma de escribir estas funciones, así que no son intercambiables: una función de Netlify no la puedes mover a Cloudflare directamente.

Combinando estáticos + Supabase

Un patrón muy común hoy en día es desarrollar el frontend en React, Vue, Angular o cualquier framework de JavaScript, generar archivos estáticos y conectarlo directamente a Supabase. Supabase actúa como tu backend (base de datos, autenticación, almacenamiento) y, si necesitas lógica personalizada, usas sus Edge Functions.

Generadores de sitios estáticos y JAMStack

¿Por qué alguien querría crear un sitio estático cuando casi todo es dinámico? La respuesta es simple: hay veces en las que solo necesitas mostrar información. Documentación, blogs, landing pages, portfolios... no requieren login ni base de datos.

Algunos generadores populares:

• Docusaurus (creado originalmente por Facebook, ideal para documentación).
• Hugo (en Go, súper rápido).
• Jekyll (en Ruby).
• Astro (moderno, muy versátil).

Y frameworks como Next.js, Nuxt o SvelteKit también pueden generar sitios estáticos cuando lo necesitas.

Esto fue lo que dio origen al concepto de JAMStack (JavaScript, APIs y Markup): tu frontend en estático, tu backend a través de APIs (propias o de servicios), y todo se sirve desde una CDN.

¿Cuál escoger según tu proyecto?

Te doy algunos escenarios típicos:

Si estás haciendo un proyecto en React + Supabase: Probablemente solo necesitas un hosting estático más las Edge Functions de Supabase. Es lo más barato y rápido de poner en producción.

Si estás haciendo un backend en Python, frontend en React y base de datos PostgreSQL: Es un proyecto bastante común y un PaaS como Railway o Render es la elección recomendada. Lo despliegas fácilmente y no te tienes que preocupar por la infraestructura.

Si tu proyecto tiene workers, cron jobs, sistemas de notificaciones, envío masivo de correos, o usa un lenguaje poco común: Vete por un VPS. Vas a tener mucho más control y es donde mejor se acomodan este tipo de cargas de trabajo.

Más allá: Docker y Kubernetes

Solo mencioné las plataformas, pero por debajo del código también podrían estar contenedores Docker, que es otra forma de despliegue (más avanzada). Y luego entran los clústeres de Kubernetes, ideales para escalar a una cantidad enorme de usuarios.

A medida que vas escogiendo opciones más potentes, te vas alejando de la facilidad de uso:

• Estático → muy fácil
• PaaS → fácil
• VPS → un poco más difícil
• Docker → complejo
• Kubernetes → muy complejo

Para la gran mayoría de desarrolladores que trabajan en proyectos pequeños o medianos, los tres enfoques que cubrimos son más que suficientes. Si quieres profundizar, el siguiente paso natural es aprender Docker y luego Kubernetes, pero ahí ya hablamos menos de desarrollo y más de arquitectura e infraestructura.

Conclusión

Si estás empezando, esto es realmente todo lo que necesitas saber sobre despliegue. Con estos tres enfoques (estático, PaaS y VPS) puedes desplegar prácticamente cualquier proyecto: backend, frontend y base de datos.

¿Cuál es el mejor? Depende del tipo de aplicación. Pero ahora ya tienes la base para tomar una decisión informada e incluso para pedirle a una IA que te diseñe una arquitectura: ese diseño va a funcionar en cualquiera de estas plataformas porque ya entiendes los fundamentos.

Si conoces alguna otra forma de despliegue común que no haya mencionado, me encantaría escucharla. Y si tienes dudas sobre qué enfoque escoger para tu proyecto, déjamelo saber.

¡Nos vemos en el próximo artículo!