Hasta aquí, la automatización se ejecutaba en tu máquina cuando tú lo indicabas. Para que se ejecute sola en internet, se combinan tres piezas: el código está en el GitHub, o Trigger.dev se ejecuta, y el disparador es un agenda (cron) o un evento (webhook). El diagrama muestra cómo se conectan.
Diagrama ilustrativo — recreación conceptual de la infraestructura de deploy, no es una captura de pantalla real.
☁️ Automatizaciones alojadas
Qué es
Una automatización alojada es un script que se ejecuta por su cuenta en Internet, sin que tengas que abrir nada ni hacer clic en "ejecutar". En vez de que la automatización viva en tu máquina y dependa de que estés presente, pasa a vivir en la nube y se activa sola: por agenda (cron) o evento (webhook). Es el paso de "ejecutar cuando yo lo ordeno" a "ejecutar por sí solo".
Por qué aprender
La gran limitación de la automatización activada por una persona es sencilla: solo escala a la velocidad a la que una persona puede presentarse y hacer clic. Si la tarea tiene que ejecutarse cada mañana a las 7h o en el momento en que se envía un formulario, depender de ti es un cuello de botella. Alojarla elimina ese cuello de botella.
- •Se ejecuta sin supervisión: la tarea se realiza incluso mientras duermes o estás de vacaciones.
- •Escala de veracidad: la frecuencia deja de depender de tu disponibilidad.
- •Confiabilidad: con retries y logs, los errores se gestionan y quedan visibles.
Conceptos clave
✓ Qué cambia al alojar
- ✓El código sale de la máquina y va a la nube.
- ✓El activador pasa a ser una agenda o un evento, no un clic.
- ✓Un motor (Trigger.dev) se encarga de la ejecución, los retries y los logs.
✗ Lo que NO es alojar
- ✗Deja la computadora encendida con el editor abierto toda la noche.
- ✗Ejecutar la tarea manualmente «cuando me acuerdo».
- ✗Depender de ti para hacer clic antes de que pase algo.
🎯 Consejo práctico
Dos builds sirven de base para esta ruta: uno agente de investigación programado (cron, cada mañana) y un generador de informes por webhook (activado por evento). Tenerlos en cuenta ayuda a entender por qué existe cada pieza de infraestructura.
🕳️ La «brecha agéntica»
Qué es
En una sesión interactiva, la IA observa cada error, lo diagnostica y lo corrige: el famoso bucle de autocuración. Cuando la tarea empieza a ejecutarse sola en la nube, este loop desaparece: la IA ya no está ahí observando. El agentic gap es esa brecha: el sistema se ejecuta, pero no se adapta por sí solo, y tanto la IA como tú pueden pasar por alto un error.
Por qué aprender
✓ Cómo cerrar la brecha
- ✓Retries automáticos con términos configurables.
- ✓Trazas completas de cada paso de la ejecución.
- ✓Alertas de fallo (correo electrónico/Slack) y sin timeout.
✗ Lo que deja de existir
- ✗La IA lee el error y lo corrige en el momento.
- ✗Adaptación espontánea a un escenario nuevo.
- ✗Garantía de que alguien notará el error.
Conceptos clave
Como la IA no se va a autocurar en producción, los builds sin supervisión requieren cuatro cosas desde el primer prompt: entradas fijas, salidas estructuradas y previsibles, manejo de errores integrado y logs en cada paso. Las palabras clave "se ejecuta solo" y "cada mañana" indican a la IA que diseñe para una agenda, sin intervención humana.
Sin preguntas en medio.
Formato predecible.
Manejo desde el inicio.
Visibilidad total.
⏰ Cron
Qué es
O cron es un patrón de temporización de cinco campos que indica cuando una tarea debe activarse. Los campos, en orden, son: minuto, hora, día del mes, mes y día de la semana. Un asterisco (*) significa "cualquier valor". El clásico 0 7 * * * se lee como «en el minuto 0 de la hora 7, todos los días, todos los meses, todos los días de la semana»; es decir, 7h de la mañana, todos los días.
# ┌───────── minuto (0-59) # │ ┌─────── hora (0-23) # │ │ ┌───── dia do mês (1-31) # │ │ │ ┌─── mês (1-12) # │ │ │ │ ┌─ dia da semana (0-6) # │ │ │ │ │ 0 7 * * * # 7h todo dia 0 8 * * 1 # 8h toda segunda */15 * * * * # a cada 15 minutos
Por qué aprender
Cron es el lenguaje universal de programación de tareas: aparece en Trigger.dev y en prácticamente todas las plataformas de automatización. Saber leer y escribir estos cinco campos te permite controlar cuándo se activa la tarea, sin depender de conjeturas ni de una interfaz gráfica limitada.
🎯 Consejo práctico
No necesitas memorizar la sintaxis: describe el horario en lenguaje natural («todas las mañanas a las 7 h») y deja que la IA genere la expresión cron. Pero reconocer los cinco campos te ayuda a comprobar si lo que generó coincide con lo que querías.
Min, hora, día, mes, día de la semana.
Comodín en cada posición.
Se activa en ciclo.
7h todos los días.
🗄️ GitHub como almacenamiento de código
Qué es
O GitHub es almacenamiento de código en la nube. En vez de que el código viva solo en tu máquina, está en un repositorio (la carpeta del proyecto dentro de GitHub), accesible desde cualquier computadora, con un historial completo de versiones para hacer rollback y solucionar problemas. Las plataformas de deploy, como Trigger.dev, toman el código directamente de allí.
Por qué aprender
Para que una automatización se ejecute en la nube, el código debe existir en un lugar al que la nube pueda acceder. GitHub es ese lugar: la única fuente de lo que va a producción. Además, el historial de commits permite volver a una versión que funcionaba cuando algo sale mal.
- •Acceso desde cualquier lugar: el código no queda vinculado a un dispositivo.
- •Historial + rollback: cada commit es un punto de restauración.
- •Integración de deploy: Trigger.dev lo obtiene directamente del repositorio.
Conceptos clave
Vocabulario de Git
Repositorio (repo)
La carpeta del proyecto en GitHub, que guarda todos los commits. Créala como privada e inicialízala con un README.
Commit
Una instantánea guardada del código, con una descripción de los cambios. Es tu punto de restauración en el historial.
Push
La acción de enviar los commits de tu máquina a GitHub. El asistente conecta la carpeta local con el repo y hace el primer commit por ti.
🎯 Consejo práctico
Prefiere una ruta local limpia (p. ej., Documentos) y evita colocar el proyecto dentro de una carpeta sincronizada con la nube. Verás varias solicitudes de permiso para comandos bash; aprobarlas es normal, no es un error.
🔒 gh CLI y .gitignore
Qué es
O gh (GitHub CLI) es la herramienta de línea de comandos que autentica y conecta el proyecto local con GitHub. El .gitignore es un archivo que enumera lo que nunca debe subirse al repositorio. Juntos, te permiten subir el código de forma segura y mantienen los secretos fuera de la nube pública.
Por qué aprender
⚠️ La regla de oro: el .env nunca se sube
El archivo .env guarda las claves de API. Si termina en un repositorio (aunque sea privado), tus claves quedan expuestas. El asistente agrega el .env a .gitignore automáticamente — pero revísalo.
- ✗Nunca hagas commit del
.env— el punto de partida ayuda, pero confía en el.gitignore. - ✗Nunca pegues claves de API en el chat.
- ✗No asumas que "repo privado" = seguro para guardar secretos.
Conceptos clave
Instalar y autenticar gh
Requisito previo del gestor de paquetes
En macOS, instala primero Homebrew; en Windows, WinGet. Después, brew install gh (o el equivalente).
Autenticar con gh auth login
Elige GitHub.com, HTTPS y autenticación mediante el navegador; pega el código de un solo uso y autoriza.
Conectar y verificar
El asistente conecta la carpeta local al repo, trae el README y escribe el .gitignore y confirma la sincronización.
🎯 Consejo práctico
Elige un nombre de usuario público y profesional: aparece en tu perfil. Y recuerda: es normal que te pidan permiso repetidamente para ejecutar comandos bash durante la conexión; lee cada solicitud para entender cada paso.
🚀 Trigger.dev
Qué es
O Trigger.dev es el motor de ejecución en la nube, como un asistente firme y confiable, no un recordatorio pegado en el refrigerador. Ejecuta las tareas sin timeouts (todo el tiempo que sea necesario), con reintentos automáticos, traces completos de cada paso, soporte para agendas y webhooks, y alertas de fallo. Se ejecuta en TypeScript, pero la IA escribe el TypeScript, así que el enfoque de vibe coding no cambia.
Por qué aprender
✓ Lo que ofrece Trigger.dev
- ✓Sin timeout: las tareas largas se ejecutan hasta terminar.
- ✓Retries automáticos para fallas transitorias.
- ✓Traces + alertas + MCP oficial para que la IA lo gestione.
📊 Por qué TypeScript no es un problema
- •La IA genera todo el código TypeScript a partir de la conversación.
- •Sigues describiendo el resultado, no escribiendo código.
- •El flujo de prompting es exactamente el mismo que en las fases anteriores.
Conceptos clave
La división de responsabilidades es clara: el GitHub almacena el código; el Trigger.dev ejecuta — programación, webhooks, reintentos, registro y alertas. El dashboard de Trigger.dev es tu ventana a lo que sucede en producción, lo que ayuda precisamente a cerrar la brecha agentic, ya que la IA ya no está observando los errores.
Ejecuta el tiempo que necesites.
Inténtalo de nuevo por tu cuenta.
Cada paso queda registrado.
Ventana de producción.
🧰 Inicializar proyecto + MCP de Trigger.dev
Qué es
Inicializar el proyecto significa instalar el MCP oficial de Trigger.dev (que permite a la IA gestionar el proyecto mediante una conversación), ejecutar el init (crea el trigger.config.ts y la carpeta de tasks) y subir el worker de desarrollo para que las tareas se registren y se ejecuten. La cuenta de Trigger.dev se crea con GitHub, y el proyecto recibe el mismo nombre que el repositorio.
Por qué aprender
La secuencia de configuración inicial
Instalar el MCP y reiniciar
Pídele a la IA que instale el MCP de Trigger.dev; aprueba los comandos. Reinicia el asistente después — si no, puede que el server no aparezca (causa común de error).
Copiar el Project ID y ejecutar el init
Obtén el Project ID en Project Settings > General. El init es interactivo y puede que tengas que ejecutarlo en la terminal; elige el ejemplo "hello world".
Inicia el worker de dev y confirma
Ejecuta el worker de desarrollo para registrar la task; confirma que «hello world» aparece en el dashboard. Pídele a la IA que la dispare y revisa el run, los traces, el payload y el output.
Conceptos clave
✓ Anatomía del dashboard
- ✓Task view, lista de Runs y trazas por ejecución.
- ✓Timeline, paneles de payload y output.
- ✓Secciones de Schedules, Queues y Alerts.
✗ Trampas comunes
- ✗Olvidar reiniciar después de instalar el MCP.
- ✗Espera a que termine el init no interactivo (a veces se necesita la terminal).
- ✗Confundir el entorno de desarrollo con el de producción al probar.
🎯 Consejo práctico
Abre siempre la carpeta del proyecto en el editor para que la IA pueda gestionarlo mediante una conversación, en vez de recurrir a la terminal. Construye y prueba en dev; promuévelo a producción cuando esté listo para salir al aire.
🗝️ Gestión de secretos
Qué es
Las claves y los secretos nunca pueden estar en el código público, y Trigger.dev no puede leer el .env local. La solución es guardar los secrets en el dashboard de Environment Variables de Trigger.dev: quedan fuera del código y están inyectados en tiempo de ejecución, solo cuando se ejecuta la tarea. Localmente, mantienes un .env (ignorado por git) para desarrollo.
Por qué aprender
Sin los secrets en la nube, la tarea funciona localmente, pero falla en producción, porque allí no tiene acceso a tu .env. El asistente crea el .env, garantiza que esté en el .gitignore, genera un .env.example seguro para versionar y actualiza el código para leer de process.env.
- •Local:
.enven la máquina, para desarrollar. - •Nube: Environment Variables de Trigger.dev, inyectadas en runtime.
- •Versionable: solo el
.env.example(sin valores reales) se sube al repo.
Conceptos clave
⚠️ Las tres reglas de oro
- ✗Nunca pegues claves de API en el chat del asistente.
- ✗Nunca hagas commit del
.enven GitHub. - ✗No olvides agregar la variable también en el entorno de producción, no solo en el de desarrollo.
🎯 Consejo práctico
Al agregar cada clave (p. ej., Anthropic, Firecrawl, Google Sheets mediante OAuth), marca dev Y prod — olvidar el entorno de producción es uno de los motivos más comunes por los que una tarea funciona en la prueba y falla cuando se publica. Considera rotar las claves y usar claves distintas para local y producción.
Autocuración (opcional): la tarea funciona en la prueba local, pero falla en producción e indica que falta una clave de API. ¿Dónde está probablemente el problema?
📌 Resumen del módulo
0 7 * * * = 7h todos los días.Próximo Módulo:
3.2 — Agentes en producción: programados & webhooks