🌐 Qué es publicar
Creaste la solución, funciona de maravilla en tu computadora y, aun así, no resuelve el problema de nadie. ¿Por qué? Porque está bloqueada en tu máquina. Publicar es poner la solución en el mundo: dejarla en un lugar que permanece conectado, con una dirección, para que las personas y otros sistemas la usen de verdad. Es la diferencia entre una maqueta en tu mesa y una tienda abierta en la calle.
🚪 "En línea" significa tres cosas
Una solución está «en línea» cuando: (1) está en un lugar que se queda conectado por sí solo, sin tu computadora encendida; (2) tiene un dirección a las que otras personas pueden acceder; y (3) está conectada a los canales por los que el cliente se comunica con ella. Todo en este módulo gira en torno a estos tres puntos.
✓ Publicado (en línea)
- ✓Funciona incluso con tu computadora apagada
- ✓Tiene una dirección a la que cualquiera puede acceder
- ✓El cliente lo usa cuando quiere, por su cuenta
- ✓Resuelve el problema de verdad
✗ Solo local (atrapado)
- ✗Solo funciona con tu computadora encendida
- ✗Nadie de afuera puede acceder
- ✗Te conviertes en el «servidor humano» del proyecto
- ✗Se queda como prototipo eterno, nunca como solución
🖥️ Alojamiento de sitios web
La forma más sencilla de publicar es alojar. Alojar es alquilar un pequeño espacio de una computadora que permanece conectada a internet (un "armario" en un edificio que nunca apaga las luces) y dejar ahí tu página o sitio web. Para muchos prototipos, eso basta: los servicios listos para usar ponen un sitio en línea en minutos, gratis o casi gratis. Es tu primer "en línea" posible: rápido, barato y suficiente para validar la idea.
💡 Consejo práctico
No empieces comprando un servidor caro. Para una página, una carpeta o una demostración, usa un alojamiento gratuito para sitios estáticos. Funciona, cuesta cero y ya te da un enlace para enviarle al cliente. La complejidad puede venir después, solo cuando la solución lo requiera.
🧱 Sitio estático × dinámico (la diferencia en una frase)
- Estático: páginas listas, iguales para todos (una carpeta, un catálogo). Barato y fácil de alojar.
- Dinámico: el contenido cambia según quién accede y qué hace (un panel, un chat con memoria). Necesita un servidor que "piensa" — el siguiente tema.
☁️ VPS y servidor
Cuando la solución crece más allá de una página, cuando necesita quedarse pensando, recordando y respondiendo todo el tiempo, como un Jarvis — necesitas un servidor. Un servidor es solo una computadora que permanece encendida para servir a las demás. Un VPS (servidor privado virtual) es la forma más común de tener uno: alquilas una computadora en la nube, solo para ti, encendida las 24 horas, y allí ejecutas los servicios de tu sistema.
💡 Consejo práctico
No necesitas «ser de TI» para tener un VPS. Hoy puedes alquilar un servidor pequeño por unos pocos reales al mes, en minutos y con un panel visual. Lo importante es entender el concepto: hay una computadora en la nube, encendida para ti, donde vive Jarvis.
🔗 Dominio
Tu servidor tiene un número: una secuencia poco atractiva, difícil de recordar, que nadie va a escribir. El dominio es el nombre elegante que señala ese número: inema.club en lugar de una fila de dígitos. Es la identidad pública y profesional de la solución: el nombre por el que la encuentran y la recuerdan. Detrás, un sistema llamado DNS funciona como la agenda de contactos de internet: escribes el nombre y encuentra el número.
La traducción que hace el DNS (ilustrativa)
Número ficticio, solo para mostrar el concepto: nombre → DNS → dirección real.
💡 Consejo práctico
El dominio es barato y vale la pena tenerlo desde temprano: transmite profesionalismo y es tuyo. Puedes cambiar de servidor después y el dominio seguirá siendo el mismo; basta con redirigirlo. El nombre es de la marca; el servidor es solo donde vive hoy.
🗄️ Base de datos, API y webhook
Una solución publicada rara vez funciona por sí sola: se comunica con otros sistemas. Hay tres integraciones que aparecen todo el tiempo, y solo necesitas entender el concepto de cada uno para diseñar el flujo: el base de datos guarda la información (la memoria organizada), la API es la forma estándar en que se comunican dos sistemas (el «mostrador de atención» de un programa), y el webhook es una alerta automática que se activa cuando pasa algo («avísame cuando se acredite el pago»).
Base de datos
Dónde se guarda y organiza la información — clientes, pedidos, historial. La memoria del sistema.
API
El mostrador por donde otros sistemas solicitan y entregan cosas al tuyo, de forma estandarizada.
Webhook
El aviso automático: "ocurrió X, te avisé de inmediato". Se activa solo, sin que nadie pregunte.
🔄 API × webhook (la diferencia que confunde a todo el mundo)
API eres tú preguntando: «oye, ¿hay novedades?» — tú buscas la información cuando quieres. Webhook es el sistema avisando: «mira, acaba de pasar» — la información llega sola. Tú buscas una; la otra te llega. Es la diferencia entre llamar para preguntar y recibir una notificación.
🚀 Deploy: del código al aire
Hiciste un cambio en la solución. ¿Cómo llega al servidor donde la usa el cliente? Ese acto —llevar la versión actual al lugar donde funciona de verdad— se llama deploy. Es el paso que conecta «está listo en mi computadora» con «está funcionando para el cliente». En el flujo del arquitecto, el deploy es el puente: desde el control de versiones (que viste en el módulo anterior) hasta el sistema en funcionamiento.
🛤️ La línea del deploy
1. Commit
Guardas el cambio en el control de versiones: una foto de «ahora está como quiero».
2. Enviar (push)
El cambio llega al repositorio central, donde el servidor puede acceder a él.
3. Deploy
El servidor toma la nueva versión y la pone en marcha, automáticamente o con un clic.
4. En línea (producción)
El cambio ya está activo para el cliente. Lo que era código se convirtió en una solución en uso.
💡 Consejo práctico
El mejor deploy es el que ni siquiera notas: muchos servicios hacen deploy automático con cada envío. Guardas y envías; el sistema se despliega solo. Cuanto menos manual sea el deploy, menos errores humanos habrá y más libre estará el arquitecto para pensar en la intención, no en apretar botones.
🧪 Prueba × producción
Aquí tienes una de las reglas de oro de quien publica: nunca experimentes donde está el cliente. El entorno de prueba es donde puedes romper, equivocarte y descubrir cosas sin riesgos; el de producción es donde el cliente realmente lo usa y donde un error cuesta caro. Se mantienen separados a propósito. Mezclarlos es una de las mayores fuentes de accidentes; por eso, la separación entre pruebas × producción es también una regla de seguridad.
🧪 Prueba (borrador)
- •Puede fallar sin problema
- •Datos falsos, sin consecuencias
- •Lugar para experimentar y aprender
- •El cliente nunca ve
🌐 Producción (en línea)
- •El cliente usa de verdad
- •Datos reales, consecuencias reales
- •Solo se incluye lo que ya se probó
- •Aquí los errores cuestan caro
⚠️ El accidente clásico
"Solo fue una pruebita rápida en producción." Así es como se borra la base de datos de clientes, se envían mil mensajes equivocados o se le cobra dos veces a alguien. Una prueba es una prueba; producción es producción. Cuando la IA ejecuta acciones reales, esa frontera deja de ser un detalle técnico y pasa a formar parte de la arquitectura de seguridad.
Autoevaluación (opcional): ¿por qué las pruebas y producción se mantienen en entornos separados?
🎯 Resumen del módulo
Siguiente módulo:
1.5 — Canales de entrada y salida: por dónde el mundo se comunica con Jarvis y por dónde responde él.