Publicar tu web en internet: las 4 rutas

Tenés una web funcionando en tu compu —la armaste con IA, con un builder o a mano— y ahora querés que cualquiera la vea con un link. En este tutorial vas a entender las 4 rutas reales para publicarla y elegir la que te corresponde según tu proyecto y tu bolsillo. Es para vos si nunca deployaste nada ("deployar" = subir tu web a un servidor para que viva en internet).

Antes de empezar

• Una web que ya funciona en tu máquina, aunque sea un index.html suelto.
• Una cuenta de GitHub (gratis). Varias rutas la usan y te ordena la vida.
• Opcional pero recomendado: un dominio propio. Se compra aparte y cuesta unos dólares al año.
• No necesitás saber programar. Necesitás saber qué armaste, y eso lo vemos en el paso 1.

Paso 1 — Identificá qué tipo de proyecto tenés

Antes de elegir ruta, contestá una pregunta: ¿tu web necesita un servidor corriendo o son solo archivos?

• Estática: HTML, CSS y JavaScript. No guarda datos, no tiene login, no habla con una base de datos. Prueba rápida: si abrís el index.html con doble clic y todo anda, es estática.
• Dinámica: tiene un backend (Node, Python, lo que sea) que tiene que estar corriendo todo el tiempo, o guarda datos de usuarios.

Con esa respuesta, seguí leyendo: las rutas 1 y 2 son para estáticas, la 3 y la 4 aguantan cualquier cosa.

Paso 2 — Ruta 1: plataformas de sitios estáticos (la gratuita)

Vercel, Netlify, Cloudflare Pages o GitHub Pages. El flujo es siempre el mismo:

1. Subís tu proyecto a un repositorio de GitHub.
2. Conectás ese repo a la plataforma.
3. Cada vez que hacés un cambio y lo subís, se publica solo.

Tienen capa gratuita generosa para proyectos personales y te dan HTTPS (el candadito) automático. La letra chica honesta: los planes gratis tienen límites de uso y condiciones para proyectos comerciales, y no sirven para backends pesados. Para la gran mayoría de las webs de un no-dev, esta ruta alcanza y sobra.

Paso 3 — Ruta 2: hosting compartido (la clásica)

El hosting de toda la vida: pagás unos dólares al mes, te dan un panel (tipo cPanel) y subís archivos con el administrador de archivos o por FTP. Suele incluir dominio con descuento y correos con tu marca.

¿Cuándo tiene sentido? Webs de clientes tipo WordPress, o cuando querés todo en un solo proveedor con soporte humano. ¿Cuándo no? Si tu proyecto es una app moderna con backend en Node o Python: ahí el hosting compartido te va a pelear.

Paso 4 — Ruta 3: plataformas de apps (PaaS)

Railway, Render, Fly.io y similares. Conectás tu repo, la plataforma detecta qué tipo de app es, la construye y la deja corriendo. Es la ruta natural para tu primera app con backend: la que tiene login, base de datos o un bot atrás.

Honestidad: pagás por uso, y las capas gratis o baratas suelen "dormir" tu app cuando nadie la visita (el primer visitante espera unos segundos mientras despierta). Para un proyecto serio, contá con pagar algo todos los meses.

Paso 5 — Ruta 4: VPS propio (la de control total)

Un VPS es un servidor alquilado que nunca se apaga: una compu tuya en un datacenter. Precio fijo por mes, corrés todos los proyectos que entren, nadie te duerme la app, nadie te limita.

El costo real no es la plata: es que vos sos el responsable de todo —seguridad, actualizaciones, backups. Es la ruta que más libertad da y la que más te exige. Si recién empezás, no arranques acá; llegá acá.

Paso 6 — Conectá tu dominio

Cualquiera sea la ruta, el remate es el mismo:

1. Comprá el dominio en un registrador (Namecheap, Cloudflare, el que sea).
2. En la configuración DNS del dominio, apuntá a tu plataforma: un registro A (una IP) o un CNAME (un nombre), según lo que te indique cada servicio.
3. Esperá la propagación: puede tardar de minutos a horas.
4. Activá HTTPS. En las rutas 1 y 3 es automático; en hosting compartido suele ser un clic; en VPS lo configurás vos.

Errores comunes

• Elegir VPS para un sitio estático simple. Es matar una mosca a cañonazos: más plata, más riesgo, cero beneficio. Arreglo: ruta 1 y listo.
• Subir archivos con claves. El .env con tus API keys nunca va al repo ni al hosting público. Arreglo: agregalo al .gitignore antes del primer push.
• Pagar un año de hosting antes de probar. Arreglo: validá primero en una capa gratuita; el hosting pago se contrata cuando el proyecto lo pide.
• Creer que "publicar" es una sola vez. Tu web va a cambiar mil veces. Arreglo: elegí una ruta donde actualizar sea fácil (por eso GitHub + ruta 1 o 3 es tan cómodo).

Siguiente paso

Cuando la ruta 1 o 3 te quede chica, el paso natural es aprender a manejar tu propio VPS: qué es SSH, cómo se asegura un servidor y cómo se publica ahí con Docker. También te conviene entender DNS a fondo, porque los dominios son el punto donde todas las rutas se cruzan.