1. Introducción: qué es un entorno de verdad

Descripción

Al terminar esta lección vas a poder explicar qué es un entorno en el sentido serio de la palabra, distinguir con precisión qué cambia entre dev, staging y prod —y qué, sobre todo, no cambia—, y reconocer por qué "todo en una sola instancia" es un antipatrón que tarde o temprano rompe producción. Vas a tener el mapa completo de los ocho pasos de este módulo y vas a entender por qué, como la edición Community de n8n no trae la feature de "environments" de forma nativa, vamos a construir ese aislamiento nosotros mismos con Docker Compose, a costo cero.

Esto importa porque es la frontera donde un automatizador deja de ser un aficionado con suerte y pasa a ser alguien en quien una empresa puede confiar su operación. Un constructor de workflows prueba sus cambios contra el sistema real y reza para que nada se rompa. Un dueño del sistema tiene un lugar seguro donde equivocarse —dev—, un lugar donde ensayar en condiciones parecidas a las reales —staging—, y solo entonces toca lo que de verdad importa —prod—. Esa separación es justo lo que las ofertas de trabajo serias piden cuando escriben "experience with staging and production environments". No es un lujo de empresa grande: es la diferencia entre una noche tranquila y una noche en vela.

Conexión con el módulo: esta lección es el mapa, todavía no la técnica. Aquí instalas el problema (por qué una sola instancia no basta) y el vocabulario que vas a usar en los ocho pasos. La lección 2 te da la base reproducible —el Self-Hosted AI Starter Kit— y te explica qué es un contenedor y qué es Docker Compose. La lección 3 convierte esa base en tres stacks aislados. La 4 les pone su .env y su clave de cifrado propias. La 5 y la 6 resuelven las credenciales y los secretos por entorno. La 7 es la decisión honesta sobre cuándo conviene pagar por la feature nativa. Y la 8 es el proyecto: los tres entornos corriendo y una prueba de que están de verdad aislados. Una nota de continuidad: en el Módulo 3 ya sacaste las credenciales del repositorio y conociste la N8N_ENCRYPTION_KEY; este módulo toma ese hilo y lo lleva hasta "una clave y unas credenciales por entorno".

De un solo escenario a tres: el teatro y el ensayo

Piensa en una compañía de teatro que monta una obra. La obra es una sola: el mismo guion, los mismos personajes, las mismas escenas. Pero esa obra se representa en tres situaciones muy distintas antes y durante su vida.

Primero está el ensayo en la sala de prácticas. Ahí los actores se equivocan a propósito: prueban un tono, se saltan una escena, repiten un parlamento diez veces. Si alguien tropieza, no pasa nada: no hay público, no hay boletos vendidos, no hay crítico en primera fila. La sala de prácticas existe para equivocarse.

Después está el ensayo general, con vestuario, luces y escenario de verdad, pero todavía sin público que pagó. Es lo más parecido a la función real que se puede tener sin arriesgar nada. Si algo falla en el ensayo general —una luz que no entra a tiempo, un cambio de escena que se traba—, se corrige esa noche y nadie se entera. Es el último filtro antes de lo que cuenta.

Y por fin está la función de estreno, con la sala llena, los boletos vendidos y el crítico tomando notas. Aquí un error se ve, se paga y se recuerda. Nadie ensaya en el estreno. Al estreno se llega con la obra ya probada en los dos escenarios anteriores.

Esos tres momentos son exactamente dev, staging y prod:

Entorno	Qué es en el teatro	Para qué sirve	Qué pasa si algo falla
dev	La sala de prácticas	Construir y romper sin miedo	Nada: nadie mira
staging	El ensayo general	Ensayar en condiciones casi reales	Se corrige esa noche, sin público
prod	La función de estreno	Correr de verdad, con lo que importa	Se ve, se paga, se recuerda

Fíjate en lo más importante de la analogía, porque es la idea que sostiene todo el módulo: la obra es la misma en los tres escenarios. El guion no cambia entre la sala de prácticas y el estreno. Lo que cambia es el contexto: el público, las luces, las consecuencias. En nuestro mundo, la "obra" es el workflow order-triage, y es idéntico en dev, staging y prod. Lo que cambia entre entornos no es la lógica; es con qué datos corre, con qué credenciales se conecta, y a qué URLs responde.

Esta es la confusión número uno que trae la gente que nunca trabajó con entornos: creen que tener tres entornos significa tener tres versiones del workflow. No. Es un workflow —una obra— que se representa en tres escenarios distintos. Lo grabé desde ya porque de aquí salen la mitad de los errores de este módulo.

Qué cambia, exactamente, entre entornos (y qué no)

Vamos a ser precisos, porque "un entorno" suena abstracto hasta que lo desarmas en sus piezas. Un entorno es el conjunto completo de condiciones bajo las que corre tu workflow: la instancia de n8n que lo ejecuta, la base de datos donde vive, las credenciales que usa, los datos que procesa y las URLs por las que se lo alcanza. Dos entornos son "distintos" cuando esas condiciones son distintas aunque el workflow sea el mismo.

Entre dev, staging y prod cambian cuatro cosas, y conviene nombrarlas una por una:

1. Los datos. En dev procesas datos inventados: pedidos de mentira que armaste para probar. En staging, datos parecidos a los reales pero todavía sin consecuencias. En prod, los pedidos de verdad de las cafeterías que le compran a Cumbre. Un pedido de prueba que se aprueba mal en dev no le cuesta un peso a nadie; el mismo error en prod manda café que nadie pidió.

2. Las credenciales. En dev y staging usas cuentas de prueba y llaves sandbox: un CRM de juguete, una llave de modelo de IA con un límite de gasto bajo. En prod usas las credenciales reales: el CRM que de verdad tiene los datos de los 400 clientes de Cumbre. Esto es la lección 5 completa. Por ahora quédate con que las llaves reales solo viven en prod.

3. Las URLs y los webhooks. Cada instancia de n8n corre en una dirección distinta. La dev en un puerto, la staging en otro, la prod en otro. Y como order-triage empieza con un Webhook, la URL que dispara ese workflow es distinta en cada entorno. Un pedido de prueba entra por la URL de dev; un pedido real entra por la de prod. Si esas URLs se confundieran, un pedido real caería en el entorno de pruebas, o al revés. Esto es la lección 4.

4. La clave de cifrado. Cada entorno tiene su propia N8N_ENCRYPTION_KEY —la llave maestra con la que n8n cifra las credenciales—. Ya la conociste en el Módulo 3. Aquí la idea clave es que la de dev y la de prod son distintas a propósito, para que un secreto cifrado en un entorno no se pueda descifrar en otro. Es una pared entre entornos. Lección 4.

¿Y qué no cambia? Una sola cosa, pero es la más importante: la lógica del workflow. El JSON de order-triage —qué nodos tiene, cómo están conectados, qué decide el AI Agent, a qué endpoint llama el HTTP Request— es idéntico en los tres entornos. Por eso, como viste en el Módulo 3, el workflow se versiona una sola vez en cumbre-automations/workflows/, no una copia por entorno. Lo que difiere vive aparte, en la configuración de cada entorno.

Esta es la línea que ordena todo el módulo, y vale la pena decirla como una regla:

Lo que es igual en todos lados (la lógica) se versiona una vez. Lo que cambia según dónde corra (datos, credenciales, URLs, clave) vive en la configuración de cada entorno.

Separar "lo común" de "lo que varía" no es una idea de n8n ni de esta guía. Es el principio que ordena cualquier sistema que se despliega en más de un lugar, desde una app móvil hasta un satélite. Si lo internalizas aquí, lo vas a reconocer en todos lados el resto de tu carrera.

Ejemplo trabajado: el mismo cambio, con y sin entornos

Veamos la diferencia con un caso concreto de Cumbre, sin tocar todavía ninguna herramienta.

El equipo de Cumbre quiere cambiar order-triage: que los pedidos de más de 5000 pesos vayan a revisión manual en vez de aprobarse solos. Es un cambio pequeño en el workflow. Miremos cómo se hace ese cambio en los dos mundos.

Mundo 1: una sola instancia. Cumbre tiene un solo n8n, el que procesa los pedidos reales. Ahí mismo, alguien edita order-triage, agrega la condición del umbral, y guarda. En el instante en que guarda, el cambio está en producción. Si la condición tenía un error —digamos que puso "mayor a 500" en vez de "5000"—, desde ese segundo todos los pedidos reales de más de 500 pesos empiezan a irse a revisión manual. El equipo de atención se inunda. Nadie lo probó porque no había dónde probarlo: el único n8n que existe es el que atiende a los clientes de verdad. La prueba fue el accidente.

Mundo 2: tres entornos. Cumbre tiene dev, staging y prod. El mismo cambio se hace primero en dev, contra pedidos inventados y un CRM de juguete. Ahí se descubre el error del umbral —"500" en vez de "5000"— porque un pedido de prueba de 600 pesos se va a revisión y no debería. Se corrige, se vuelve a probar en dev, se ensaya en staging con datos parecidos a los reales, y solo cuando el comportamiento es el correcto se promueve a prod. El error existió, pero murió en dev, donde no le costó nada a nadie.

Qué esperar. El cambio en el workflow es idéntico en los dos mundos: la misma condición, el mismo nodo. Lo que cambia no es qué se hace, sino dónde se descubre el error. En el Mundo 1, el error se descubre en producción, con los clientes reales de daño colateral. En el Mundo 2, se descubre en dev, en un cuarto acolchonado donde equivocarse es gratis. Los entornos no evitan que te equivoques —nada evita eso—; hacen que tus equivocaciones sean baratas.

Esa es toda la promesa de este módulo en una frase: te construimos el cuarto acolchonado.

Por qué tres entornos, y no dos (o cinco)

Una pregunta razonable en este punto: si dev es donde construyes y prod es donde corre de verdad, ¿para qué sirve el del medio, staging? ¿No bastarían dos? Vale la pena responderla, porque staging es el entorno que más gente entiende mal, y saltárselo es un error común.

staging existe para cerrar una brecha concreta. dev es tu cuarto de juegos: ahí experimentas, dejas cosas a medias, tienes datos inventados y quizás credenciales de un CRM de juguete que no se parece del todo al real. prod es lo real, con todas sus condiciones. Entre esos dos hay una distancia, y en esa distancia se esconden los errores que "funcionan en dev pero fallan en prod": un dato real con una forma que tus datos inventados no tenían, un volumen de pedidos que tu prueba de tres no reveló, una diferencia sutil entre el CRM sandbox y el real.

staging es el ensayo general que cubre esa distancia. Es un entorno lo más parecido posible a prod —mismos servicios, datos que se asemejan a los reales, credenciales de prueba pero apuntando a sistemas que imitan a los de producción—, pero todavía sin consecuencias. Su trabajo es que, si un cambio pasa por staging sin problemas, tengas alta confianza de que pasará en prod. Es el último filtro antes de lo que importa.

Piénsalo con una regla simple: dev es para que el cambio funcione; staging es para confiar en que va a funcionar en producción. Son dos preguntas distintas. La primera la responde tu cuarto de juegos; la segunda necesita un entorno que se parezca a producción de verdad.

¿Y por qué no cinco, o siete? Porque cada entorno cuesta —memoria, mantenimiento, disciplina para mantenerlos parecidos—, y tres es el punto donde el beneficio deja de crecer para la mayoría de los equipos: uno para romper, uno para ensayar, uno para lo real. Equipos muy grandes a veces agregan más (un entorno de pruebas de rendimiento, uno por equipo), pero para Cumbre —y para casi todos— tres es el número correcto. No sobre-construyas: tres entornos bien aislados valen más que siete a medio mantener.

Dicho esto, una nota práctica honesta: si estás aprendiendo y tu máquina va justa de memoria, empezar con dos entornos bien hechos (dev y prod) y agregar staging después es una concesión razonable. Lo que no es negociable es tener al menos la separación entre "donde pruebo" y "lo real". El tercero mejora la confianza; los dos primeros evitan el desastre.

Por qué "todo en una sola instancia" es un antipatrón

Un antipatrón es una solución que parece razonable, se usa mucho, y sistemáticamente termina mal. Tener una sola instancia de n8n para todo es el antipatrón más común entre quienes recién profesionalizan sus automatizaciones, y vale la pena entender por qué falla, no solo que falla.

La tentación es obvia: una instancia es más simple. Un solo n8n que levantar, una sola URL que recordar, una sola base de datos. ¿Para qué complicarse con tres? La respuesta es que la simplicidad de una sola instancia es real el día que todo funciona, y es una trampa el día que necesitas cambiar algo. Los problemas concretos:

No hay dónde probar sin arriesgar. Ya lo viste en el ejemplo: si el único n8n es el de producción, cada cambio se prueba en producción. No existe un lugar seguro para equivocarse. Esto no es teórico: es la causa número uno de incidentes en automatizaciones pequeñas.

Los datos de prueba contaminan los reales. Si pruebas order-triage en la misma instancia que procesa los pedidos reales, tus pedidos de prueba entran a la misma base de datos, se mezclan con los reales, disparan las mismas notificaciones. Mandas un correo de prueba a un cliente real. Registras un pedido inventado en el CRM real. Limpiar eso después es una pesadilla, cuando se puede.

Un secreto de prueba y uno real conviven peligrosamente. Con una sola instancia, o usas la credencial real para todo —y entonces cada prueba toca el CRM real— o andas cambiando la credencial a mano cada vez que quieres probar, lo cual es lento y propenso a olvidos catastróficos ("se me olvidó volver a poner la llave real y producción lleva dos horas caída").

Un cambio a medias rompe lo que funcionaba. En una sola instancia no puedes tener "la versión estable corriendo mientras pruebo la nueva". La instancia está en un solo estado a la vez. En el momento en que empiezas a editar, lo estable ya no está corriendo intacto: está a medias.

El patrón correcto —el que este módulo construye— es aislar. Tres instancias separadas, cada una en su propio estado, con sus propios datos y secretos, que no se tocan entre sí. El costo es un poco más de setup al principio. El beneficio es que nunca más pruebas contra producción. Ese trato —un poco de complejidad hoy a cambio de no romper producción nunca— es de los mejores que vas a hacer como automatizador.

Community no trae "environments", y por eso lo construimos

Aquí viene la parte de honestidad de planes que atraviesa toda la guía. n8n tiene una feature llamada environments —entornos— que hace justo esto: te deja tener instancias de development, staging y production conectadas y mover trabajo entre ellas desde la interfaz, apoyándose en Git. Es una feature muy buena.

Y es de pago. Según la documentación oficial, la feature nativa de entornos y control de versiones integrado vive en los planes Business y Enterprise (los planes cambian de nombre y de contenido con el tiempo, así que esto conviene confirmarlo siempre en la página de precios de n8n al momento en que lo leas). La edición Community —la gratuita, de código abierto, que instalas en tu máquina— no la incluye.

Esto podría sonar a mala noticia. No lo es, y aquí está el punto que hace valiosa a esta guía: el aislamiento entre entornos no es magia de n8n; es una propiedad que da la infraestructura por debajo. La feature nativa te lo da empaquetado y cómodo, con botones en la interfaz. Pero lo mismo se logra —el aislamiento de verdad, no una imitación— con la herramienta que corre n8n por debajo: Docker Compose. Y Docker Compose es gratis.

Lo que vamos a construir en este módulo es exactamente eso: tres instancias de n8n Community, aisladas con Docker Compose, cada una con su base de datos, su clave de cifrado, sus credenciales y sus URLs. Sin pagar un peso. La feature nativa te ahorra trabajo de setup y te da comodidad en la interfaz; el patrón self-hosted te da el mismo aislamiento a cambio de un poco más de trabajo manual. La lección 7 pone las dos opciones lado a lado con una matriz de decisión honesta para que sepas cuándo vale la pena pagar. Por ahora, la noticia es simple y buena: todo lo que este módulo enseña se hace gratis en Community.

Un cambio, de principio a fin, por los tres entornos

Para que los tres entornos dejen de ser una abstracción, sigamos un cambio concreto en su viaje completo. No vas a hacer esto todavía —es el destino del módulo, e incluso del Módulo 6—, pero verlo entero te da el norte de por qué construimos cada pieza.

El equipo de Cumbre quiere que order-triage mande los pedidos de más de 5000 pesos a revisión manual. El cambio viaja así:

1. Nace en dev. Alguien edita order-triage en la instancia de dev (http://localhost:5678), agrega la condición del umbral, y la prueba contra pedidos inventados y un CRM de juguete. Descubre y corrige errores aquí, donde nada cuesta. Cuando funciona, exporta el workflow y lo versiona en cumbre-automations con Git (Módulos 2 y 3).

2. Se ensaya en staging. El mismo order-triage.json versionado se importa en staging (http://localhost:5679), que se parece a producción: datos como los reales, credenciales de prueba apuntando a sistemas parecidos a los de verdad. Se ejecuta ahí y se confirma que el comportamiento es el correcto en condiciones cercanas a las reales. Este es el filtro que atrapa los errores que dev no reveló.

3. Llega a prod. Solo cuando pasó staging, el mismo workflow se importa en prod (http://localhost:5680), que corre con los pedidos reales de Cumbre y las credenciales reales del CRM. El cambio que llega aquí ya se probó dos veces; llega con confianza, no con esperanza.

4. Si algo sale mal, se revierte. Y si a pesar de todo el cambio rompe algo en prod, como el workflow está versionado, se vuelve a la versión anterior que funcionaba (el rollback del Módulo 6). La red de seguridad final.

Fíjate en lo que hace posible cada paso, porque es el temario de esta guía. El versionado con Git (Módulos 2 y 3) es lo que permite que "el mismo workflow" viaje entre entornos como un artefacto controlado. El aislamiento de entornos (este módulo) es lo que hace que dev sea seguro para romper y prod intocable mientras pruebas. La prueba en sandbox (Módulo 5) es lo que pasa dentro de dev y staging. Y la promoción y el rollback (Módulo 6) son los pasos 2, 3 y 4. Todo el camino que acabas de leer es lo que separa a un dueño del sistema de un constructor: no construye el cambio distinto, lo entrega distinto.

Este módulo, el 4, construye el escenario donde ese viaje ocurre: los tres entornos aislados. Sin ellos, el cambio nace y muere en la misma instancia —el antipatrón—, y no hay viaje posible.

El mapa de este módulo

Estos son los ocho pasos, y el orden no es arbitrario:

Lección	Qué resuelve
2	La base reproducible: el Self-Hosted AI Starter Kit, qué es un contenedor y qué es Docker Compose
3	Definir dev, staging y prod como stacks aislados con Docker Compose; qué no se comparte jamás
4	Un .env por entorno, una clave de cifrado distinta por entorno, y las URLs propias de cada uno
5	Credenciales por entorno: prueba en dev/staging, reales solo en prod
6	Secretos externos y variables: $env, las Variables de n8n, y qué es Enterprise con su alternativa Community
7	La feature nativa de entornos (de pago): matriz de decisión honesta sobre cuándo vale pagar
8	Proyecto: los tres entornos corriendo y una prueba de que están aislados

Primero la base (2): sin entender qué es un contenedor y Docker Compose, el resto no se sostiene. Después la estructura: tres stacks (3), su configuración (4), sus credenciales (5) y sus secretos (6). Luego la verdad económica (7): qué es gratis y qué se paga. Y el proyecto (8) junta todo en algo que corre y que puedes demostrar.

Una nota de límite antes de seguir. Este módulo levanta entornos locales, en tu propia máquina, con Docker Compose. No vamos a desplegar nada en internet, ni a configurar un servidor, ni un reverse proxy, ni a endurecer Linux. Eso es infraestructura de producción de verdad, y es tema de otra guía. Aquí "prod" es un entorno local que representa producción para que aprendas el patrón de aislamiento; no es un servidor expuesto al mundo. Cuando llegue el día de desplegar de verdad, el patrón que aprendes aquí es el mismo; solo cambia dónde corre.

Errores comunes

Creer que tres entornos significan tres versiones del workflow (conceptual). Qué pasa: alguien entiende "dev, staging, prod" como "tres copias de order-triage, una por entorno", y empieza a mantener tres archivos JSON. Al poco tiempo arregla un bug en uno y se le olvida en los otros dos, y los entornos empiezan a divergir. Por qué pasa: la palabra "entorno" sugiere "lugar separado", y de ahí se salta a "cosa separada". Cómo detectarlo: si tienes order-triage-dev.json, order-triage-staging.json y order-triage-prod.json, ya caíste. Cómo corregirlo: un solo order-triage.json versionado, que corre en los tres entornos. Lo que cambia entre entornos no es el workflow, es su configuración —datos, credenciales, URLs—, y esa vive aparte. Un workflow, muchos entornos.

Probar en la instancia de producción "con cuidado" (práctico y peligroso). Qué pasa: alguien sabe que no debería, pero tiene una sola instancia y "solo va a probar una cosita rápida" en producción. La cosita rápida manda un correo real, o corrompe un dato real, o tumba el workflow por diez minutos. Por qué pasa: montar entornos separados se siente como trabajo, y "con cuidado" se siente como suficiente. Cómo detectarlo: si tu plan para probar un cambio incluye la frase "en producción pero con cuidado", tienes el problema. Cómo corregirlo: es justo lo que construye este módulo. No existe el "con cuidado" en producción: existe el entorno de prueba, o existe el accidente. Este módulo te da el entorno de prueba para que nunca dependas del "con cuidado".

Pensar que sin la feature Enterprise no se puede hacer entornos (conceptual). Qué pasa: alguien lee que "environments" es de pago, concluye que en Community no hay forma de tener entornos separados, y se resigna a una sola instancia. Por qué pasa: es fácil confundir "la feature con ese nombre es de pago" con "la capacidad es de pago". Cómo detectarlo: si crees que necesitas Enterprise para separar dev de prod, tienes esta creencia. Cómo corregirlo: la feature nativa es una comodidad, no la única vía. El aislamiento real lo da Docker Compose, gratis. Lo que pagas en Enterprise es la interfaz cómoda y el soporte, no la posibilidad. Este módulo entero es la prueba de que se hace gratis.

Ejercicios

Ejercicio 1 — Clasifica qué cambia y qué no. Para cada uno de estos seis elementos de order-triage, di si es algo que cambia entre dev y prod, o algo que se mantiene igual en los dos, y por qué en una frase: (a) el nodo AI Agent que clasifica el pedido; (b) la llave de API del CRM; (c) el orden en que están conectados los nodos; (d) la URL del webhook que dispara el workflow; (e) la lógica de "pedidos de más de 5000 van a revisión"; (f) los datos de los pedidos que se procesan.

Ver solución

(a) Se mantiene igual. El AI Agent es parte de la lógica del workflow; el mismo nodo, configurado igual, corre en los tres entornos. (Lo que cambia es la credencial del modelo que usa, no el nodo.)

(b) Cambia. En dev es una llave sandbox con gasto limitado o un CRM de juguete; en prod es la llave del CRM real. El valor del secreto es distinto por entorno.

(c) Se mantiene igual. Las conexiones entre nodos son lógica pura; idénticas en los tres entornos.

(d) Cambia. Cada instancia corre en una dirección distinta, así que la URL del webhook es distinta en cada entorno.

(e) Se mantiene igual. El umbral de 5000 y la decisión de mandar a revisión son lógica del workflow; iguales en los tres entornos.

(f) Cambia. En dev son pedidos inventados; en prod, los pedidos reales de las cafeterías de Cumbre.

Por qué funciona: si acertaste los seis, ya internalizaste la línea que gobierna el módulo. La lógica (a, c, e) es común y se versiona una vez; el contexto (b, d, f) cambia por entorno y vive en la configuración. La que más confunde es la (a): "¿el AI Agent no cambia?". El nodo no; su credencial sí. Separar el nodo de su credencial es justo lo que hace posible un workflow para muchos entornos.

Ejercicio 2 — El accidente de la instancia única. Escribe en cuatro o cinco frases una historia realista de algo que sale mal en Cumbre por tener una sola instancia de n8n para todo. Incluye: qué cambio se intentaba hacer, qué salió mal, y qué daño concreto causó por no haber un entorno de prueba. Después responde: ¿en qué momento exacto los tres entornos habrían cortado el problema?

Ver solución

No hay una única historia correcta, pero una típica: el equipo de Cumbre quería que order-triage mandara un correo de confirmación al cliente cuando un pedido se aprueba. Configuraron el nodo de correo en la única instancia —la de producción—, con una plantilla que por error tenía el asunto vacío y el cuerpo con texto de prueba ("TEST TEST"). Al guardar, el workflow ya estaba activo en producción, así que el siguiente pedido real disparó un correo con asunto vacío y cuerpo "TEST TEST" a un cliente real, que llamó confundido. El daño: un cliente real recibió basura y perdió confianza.

Los tres entornos habrían cortado el problema en el primer momento: el correo de prueba se habría mandado a una dirección de prueba en dev, donde el "TEST TEST" es exactamente lo que esperas ver, y el error de la plantilla se habría descubierto ahí, antes de que ningún cliente real recibiera nada.

Por qué funciona: el ejercicio te obliga a conectar la abstracción ("entornos separados") con un daño concreto y humano (un cliente confundido). Esa conexión es lo que hace que el patrón se te quede: no montas entornos por disciplina abstracta, los montas para que el "TEST TEST" nunca le llegue a un cliente de verdad.

Ejercicio 3 — Reconstruye el mapa. Sin volver a mirar la tabla, escribe de memoria qué resuelve cada una de las siete lecciones que siguen (2 a 8), en una frase cada una. Después compara y marca las que se te escaparon.

Ver solución

(2) La base reproducible: el Starter Kit, qué es un contenedor y qué es Docker Compose. (3) Definir dev/staging/prod como stacks aislados y qué no se comparte jamás. (4) Un .env por entorno, una clave de cifrado por entorno y las URLs propias. (5) Credenciales por entorno: prueba en dev/staging, reales solo en prod. (6) Secretos externos y variables: $env, Variables de n8n, qué es Enterprise y su alternativa Community. (7) La feature nativa de entornos (de pago): matriz de decisión sobre cuándo pagar. (8) Proyecto: los tres entornos corriendo y la prueba de aislamiento.

Por qué funciona: si reconstruiste al menos cinco de las siete, ya tienes internalizada la progresión —base, estructura, configuración, economía, proyecto—. Las que más se escapan suelen ser la 4 y la 6, que son las más técnicas y todavía no las viste. No pasa nada: para eso están.

Resumen y siguiente paso

En esta lección viste qué es un entorno de verdad: el conjunto completo de condiciones bajo las que corre tu workflow —instancia, base de datos, credenciales, datos, URLs—, y qué distingue a dev, staging y prod. Usaste la imagen del teatro —sala de prácticas, ensayo general, estreno— para grabar la idea que sostiene todo el módulo: la obra es la misma; lo que cambia es el escenario. Nombraste las cuatro cosas que cambian entre entornos (datos, credenciales, URLs/webhooks, clave de cifrado) y la única que no cambia (la lógica del workflow), y de ahí sacaste la regla: lo común se versiona una vez, lo que varía vive en la configuración de cada entorno. Entendiste por qué "todo en una sola instancia" es un antipatrón que prueba contra producción y contamina los datos reales, y por qué el patrón correcto es aislar. Y viste la verdad de planes: la feature nativa de entornos es de pago, pero el aislamiento real se construye gratis con Docker Compose, que es justo lo que hace este módulo.

Antes de avanzar deberías poder: explicar en una frase por qué la lógica del workflow no cambia entre entornos pero sus credenciales sí; nombrar las cuatro cosas que cambian por entorno; y decir por qué probar en la instancia de producción "con cuidado" no es una estrategia.

La lección 2 baja de la teoría a la primera herramienta concreta. Vas a conocer el Self-Hosted AI Starter Kit, el paquete oficial de n8n que trae n8n, una base de datos, un almacén vectorial y modelos de IA locales, todo listo para levantar con un comando. Y antes de tocarlo, vas a entender de una vez por todas qué es un contenedor y qué es Docker Compose, explicados con manzanas, porque son las dos piezas sobre las que se apoya todo lo que sigue.

Recursos

• Source control and environments — n8n Docs — la sección oficial sobre control de versiones y entornos; útil para ver desde ya qué es la feature nativa que solo traen los planes de pago, tema de la lección 7.
• Environments in n8n — n8n Docs — cómo n8n describe su modelo nativo de development/staging/production conectado por Git.
• Compare editions — n8n Docs — qué trae la edición Community gratis y qué se reserva a los planes de pago; confírmalo aquí porque los planes cambian.
• Self-hosted AI Starter Kit — GitHub — el repositorio oficial de la base reproducible que vas a usar desde la lección 2.