El recorrido de la ruta 6: el código sube a la nube (GitHub + Trigger.dev), queda protegido (secretos y RLS) y gana robustez y monetización: el salto final de prototipo a producto.
Mapa de la ruta
Contenido detallado
🚀 GitHub y Trigger.dev
Los dos pilares de una automatización alojada: GitHub como almacenamiento de código en la nube (commit, push, historial) y Trigger.dev como motor de ejecución (sin timeout, retries, traces, alertas). Inicializar el proyecto, programar con cron y leer el dashboard.
Almacenamiento de código en la nube: el deploy lo obtiene de allí (no de tu máquina), puedes acceder desde cualquier lugar y tienes un historial para revertir cambios.
Es un requisito previo para el alojamiento: las plataformas de deploy se integran directamente con el repo.
Repo = carpeta del proyecto; commit = instantánea; push = enviar a la nube.
La herramienta de línea de comandos de GitHub (gh) autentica y conecta el proyecto; el .gitignore enumera lo que nunca debe subirse: la regla de oro es el .env.
Un .env filtrado es un secreto filtrado; el .gitignore es la primera línea de defensa.
gh auth login; .gitignore; secreto fuera del repositorio.
El motor de ejecución en la nube: ejecuta tareas sin timeout, con retries automáticos, trace de cada paso y alertas de fallos. Como un asistente confiable, no como una nota adhesiva.
Es lo que cierra la «brecha agentic»: da visibilidad cuando la IA ya no está asistiendo.
Ejecuta TypeScript (la IA lo escribe); MCP oficial; dev vs prod.
Instalar el MCP oficial, copiar el Project ID y ejecutar el init — que crea el trigger.config.ts y la carpeta de tasks; el dev inicia el worker local.
Con el MCP, gestionas el proyecto conversando; sin él, terminas en la terminal.
init interactivo; reiniciar después de instalar MCP; Project ID.
Un patrón de 5 campos (minuto, hora, día del mes, mes, día de la semana) que define cuándo se ejecuta la tarea. 0 7 * * * = todos los días a las 7 h.
Es lo que hace que la automatización se ejecute sin que estés presente: escala más allá de «aparecer y activarla».
5 campos; * = cualquiera; */5 = cada 5.
La ventana de producción: lista de runs, traces (cada línea = un paso), payload/output, sección de schedules, queues y alertas, y dos entornos (dev y prod).
Como la IA ya no está observando, el dashboard es donde ves lo que pasó.
Run = ejecución; trace = paso a paso; prueba en dev, libera en prod.
La disciplina de construir desde el principio con el deploy en mente: el «prompt inicial para gobernarlos a todos» pide entradas fijas, una salida estructurada, manejo de errores y registros desde el comienzo.
En producción, la IA no lo corrige todo por sí sola; lo que no se pidió en el prompt no viene gratis.
Deploy desde el 1.er prompt; ciclo commit → push → deploy; verifica la run.
🔐 Secrets y seguridad
Cómo mantener las claves y los datos a salvo: variables de entorno (local vs. nube), .env.example y lectura mediante process.env, OAuth y refresh token, las reglas de oro de los secretos, Row-Level Security para aislar datos, auditoría de seguridad y por qué una app abierta supone un riesgo financiero.
El secreto queda almacenado fuera del código y se inyecta solo al ejecutarlo, así que el código nunca contiene la clave.
Es el mecanismo que separa «lo que es público» (código) de «lo que es secreto» (claves).
Secreto externo; inyección en tiempo de ejecución; código sin claves integradas.
En local, los secretos viven en .env; en la nube, en el dashboard de Environment Variables (Trigger.dev/Vercel), que los inyecta en runtime. Trigger.dev no lee el .env local.
Olvidar agregar la clave en producción es el fallo que «solo aparece en prod».
Dos entornos (dev y prod); verifica ambos; la nube no lee el .env local.
Un .env.example enumera las claves SIN valores (seguro para hacer commit); el código lee los valores mediante process.env, nunca los escribe directamente.
Documenta qué secretos necesita el proyecto sin exponer ninguno.
.env.example = solo los nombres; process.env = lectura; nada hard-coded.
OAuth delega el acceso a un servicio (p. ej., Google) sin exponer tu contraseña; el refresh token renueva el acceso automáticamente. Cuando el flujo estándar falla, un script de terminal genera el token.
Es cómo los agentes alojados acceden a Sheets, Drive y Gmail sin que tengas que iniciar sesión cada vez.
Client ID/secret; refresh token; alternativa vía terminal.
Las tres reglas innegociables: nunca pegues claves en el chat de la IA, nunca hagas commit del .env y rota o vuelve a generar las claves (idealmente, usa claves distintas para local y producción).
Una clave de API es como el acceso a una tarjeta de crédito: si se filtra, alguien gasta por ti.
Clave = tarjeta; .gitignore; rotar y separar dev/prod.
Row-Level Security: reglas que residen en la propia base de datos (Supabase) e impiden que un usuario vea los datos de otro, incluso si hay un bug en el frontend.
Es una capa adicional: la base de datos protege los datos independientemente de la app.
Regla en la base de datos; aislamiento por usuario; defensa en profundidad.
Pedirle a la IA que actúe como especialista en seguridad y verifique: rutas protegidas, ninguna clave expuesta en el frontend, secretos solo en env vars y RLS habilitado.
Antes de dejar la app en producción, una auditoría explícita detecta lo que se pasó por alto.
Checklist de 4 puntos; contexto limpio; corregir lo que falle.
Una app sin autenticación en internet puede ser activada por cualquiera que tenga la URL, y cada activación consume tu clave de IA. Pagas por el uso de otras personas.
Justifica agregar inicio de sesión (Supabase) y límites de uso antes de divulgarlo.
URL pública = puerta abierta; autenticación; límite de uso.
🛡️ Confiabilidad y monetización
Lo que separa «funciona una vez» de «confiable y rentable»: el agentic gap revisitado, logging significativo, try/catch en llamadas externas, retries con backoff (vs. bugs de lógica), alertas de fallos, el ciclo humano de debug y monetización con Stripe (producto, webhook, suscripciones, freemium).
Una vez en marcha según una agenda/evento, la IA ya no está leyendo errores y corrigiéndolos: la tarea se ejecuta, pero no se adapta sola. Esa es la brecha agéntica.
Es la razón para incluir errores y logs desde el 1.º prompt: no puedes contar con la autocuración.
Funciona pero no se adapta; visibilidad mediante la plataforma; ciclo humano.
Logs específicos en cada etapa relevante: «la búsqueda devolvió 429 en la fuente 3», no «la tarea falló». El mensaje debe permitir actuar.
Un log vago no sirve; un log con contexto es lo que permite diagnosticar el error.
Específico > genérico; contexto (estado, fuente); cada paso.
Envuelve cada llamada a una API externa en try/catch: registra el error con contexto, continúa cuando sea posible y solo "lanza" (throw) en fallas críticas.
Es lo que hace que la tarea escriba una línea parcial en vez de bloquearse cuando falla una API.
try/catch por llamada; continuar; throw solo en lo crítico.
Configura la tarea para que vuelva a intentarlo (p. ej., hasta 3 veces, con backoff exponencial que empiece en 30s). Los reintentos resuelven problemas transitorios de API, no errores de código.
Saber la diferencia evita repetir eternamente un error que nunca va a pasar.
Backoff exponencial; transitorio vs. lógico; límite de intentos.
Configura alertas de fallas en el dashboard por correo electrónico, Slack o webhook, eligiendo el entorno y el tipo de falla. Toma menos de dos minutos.
Quieres enterarte de la falla antes de que el usuario final la note.
Canal de alerta; por entorno; toda tarea debe tener una alerta.
La IA todavía depura, solo que no automáticamente: abres el trace rojo, copias el error, se lo pegas a la IA ("aquí está el trace que falló, ¿qué está mal?"), aplicas el fix y vuelves a hacer el deploy.
Es el sustituto de la autocuración: diagnóstico rápido, pero con una persona que transmite el error.
Trace rojo; copiar y pegar; redeploy y probar.
Agregar pagos con Stripe y convertirlo en un SaaS freemium: nivel gratis (p. ej., 2 usos/día) y nivel pago (p. ej., $29/mes ilimitado) mediante Stripe Checkout, con un webhook que escucha los eventos de suscripción.
Completa la transición de «solo un workflow» a un producto que genera ingresos y limita tu costo.
4 claves (publishable, secret, price ID, webhook secret); freemium; tabla de suscripciones.