6. Git nativo (Enterprise) vs el flujo CLI: la decisión

Descripción

Al terminar esta lección vas a poder decidir, con criterio y sin marketing, entre las dos formas de hacer todo lo que aprendiste en este módulo: el flujo CLI + Git + Docker a costo cero de esta guía, y el source control nativo de n8n (Enterprise), con sus botones de push y pull integrados en la interfaz. Vas a tener una matriz de decisión por tamaño de equipo, presupuesto y cumplimiento, aplicada específicamente a la promoción entre entornos que es el tema de este módulo. Y vas a confirmar lo único que no cambia en ningún caso, pagues o no pagues: el repositorio sigue siendo la fuente de verdad.

Esto importa porque ahora tienes toda la imagen para decidir de verdad. En el Módulo 1 y en el Módulo 3 tocaste esta decisión, pero en abstracto: sabías versionar, pero todavía no habías promovido, revertido ni construido con IA. Ahora sí. Sabes exactamente qué implica cada pieza del ciclo, así que puedes juzgar con precisión qué te ahorra la versión de pago y qué no. La decisión "gratis o Enterprise" deja de ser una corazonada sobre precios y se vuelve un cálculo informado sobre tu escala real. Es la diferencia entre pagar por miedo y pagar —o no— con los ojos abiertos.

Conexión con el módulo: las lecciones 2 a 5 te enseñaron a promover, revisar, construir con IA y revertir a mano, con la CLI y Git. Esta lección pone ese trabajo manual frente a su alternativa automatizada de pago, ahora que ya sabes exactamente en qué consiste. Es la lección de la decisión, no de una técnica nueva: cierra la honestidad de planes que la guía prometió desde el Módulo 1 —declarar con transparencia qué es gratis y qué se paga—, aplicada al momento en que más pesa, la promoción entre entornos. La lección 7 vuelve a lo práctico con el chequeo de CI; esta es la pausa para elegir el camino con conocimiento de causa.

Lo que ya sabes de esta decisión, y lo que falta

No empezamos de cero. En el Módulo 1 (lección 7) y en el Módulo 3 (lección 7) ya trazaste la distinción de fondo, y conviene traerla a la memoria antes de afinarla, porque el error sería repetir lo que ya sabes en vez de construir encima.

Lo que ya tienes claro, con la imagen de la transmisión del auto: la capacidad de versionar existe en las dos ediciones. En Community (el "manual"), tú operas la palanca —exportas con la CLI, commiteas con Git, gestionas entornos con Docker—; en Enterprise (el "automático"), n8n opera la palanca con botones en la interfaz. Los dos autos hacen los mismos cambios de velocidad; el automático solo hace por ti lo que en el manual haces a mano. La feature integrada es de pago; la capacidad de versionar es gratis. Y la regla de decisión que sacaste: paga por comodidad y por escala, no por capacidad.

Eso sigue siendo cierto, palabra por palabra. Lo que falta —y lo que esta lección agrega— es la dimensión que en aquellos módulos todavía no habías vivido: la promoción entre entornos. Cuando trazaste la comparación en el Módulo 3, promover a prod era todavía una idea. Ahora lo hiciste: sabes lo que es sacar la versión del repo, mapear credenciales, importar inactivo, verificar y activar (lección 2); sabes lo que es revisar el diff antes (lección 3) y revertir con un runbook después (lección 5). Con esa experiencia en las manos, la pregunta "¿vale la pena pagar por el source control nativo?" tiene, por fin, una respuesta que puedes razonar en concreto, porque sabes exactamente qué pasos automatizaría la versión de pago.

Qué es, exactamente, el source control nativo de n8n

Precisemos qué hace la feature de pago, porque decidir sobre ella requiere saber qué automatiza.

El source control nativo de n8n —la feature de "environments / source control" de los planes Business y Enterprise— conecta tu instancia directamente a un repositorio de Git, y te deja hacer, desde botones en la interfaz de n8n, lo que en esta guía haces con la CLI:

• Push: enviar tus workflows de la instancia al repositorio Git, sin exportar por CLI ni docker cp. Aprietas un botón y n8n commitea los workflows al repo por ti.
• Pull: traer los workflows del repositorio a la instancia, sin import:workflow a mano. Aprietas un botón y n8n importa por ti.
• Entornos por rama: la feature asocia cada entorno (dev/staging/prod) a una rama de Git, de modo que promover un cambio es, en esencia, mover el cambio de una rama a otra y hacer pull en la instancia del entorno de destino. La herramienta gestiona esa correspondencia entre ramas y entornos.

Lo que la feature envía al repositorio, según la documentación, son los workflows, las etiquetas, y stubs —esqueletos vacíos— de credenciales y variables; los secretos reales no viajan al repo, igual que en el export manual. Ese pilar de seguridad es el mismo en los dos flujos: pagues o no, los secretos no se versionan.

Fíjate en el patrón: cada botón del source control nativo reemplaza un comando que tú corres a mano. El botón de push reemplaza tu export:workflow + commit; el botón de pull reemplaza tu import:workflow; la promoción por rama reemplaza tu ritual de la lección 2. La feature no hace nada que tú no puedas hacer; hace lo mismo, con menos pasos manuales. Eso es, exactamente, la transmisión automática: no cambia el destino, cambia cuánto trabajo pones para llegar.

La comparación aplicada a la promoción

Pongamos los dos flujos lado a lado, específicamente en el gesto de este módulo: promover un cambio de staging a prod.

Paso de la promoción	Flujo CLI (Community, gratis)	Source control nativo (Enterprise, de pago)
Sacar la versión del origen	export:workflow + git commit	Botón de push (o ya está en la rama)
Revisar el cambio	git diff / pull request en GitHub	Diff en la UI de n8n, o pull request en GitHub
Llevar la versión al destino	docker cp + import:workflow	Botón de pull en la instancia de destino
Mapear credenciales del entorno	Credenciales por entorno (Módulo 4)	Credenciales por entorno + gestión integrada
Activar en el destino	A mano, tras verificar	A mano, tras verificar
Revertir si falla	Runbook con git revert + re-import	Pull de la versión anterior desde la rama

Mira la columna de la derecha con atención: produce el mismo resultado que la de la izquierda, con menos comandos. Donde tú corres export, docker cp e import, la feature de pago aprieta botones. Pero el estado final —el workflow versionado en un repo, promovido a prod, reversible— es idéntico. Un evaluador que mire el repositorio de un equipo "automático" y el de uno "manual" no sabría cuál es cuál: los dos tienen el JSON versionado, la historia de commits, la estructura limpia.

Donde la feature de pago sí aporta algo real, y conviene reconocerlo con honestidad, es en la fricción de coordinar a varias personas promoviendo seguido. Si tu equipo hace decenas de promociones al día entre tres entornos, cada export/docker cp/import manual cuesta segundos que se acumulan y, peor, admite errores humanos —el contenedor equivocado, el paso saltado—. Los botones integrados reducen esa fricción y esos errores. Para una persona que promueve una vez por semana, esa fricción no existe; para un equipo de ocho que promueve treinta veces al día, es real y se paga en tiempo.

Ejemplo trabajado: dos equipos promueven el mismo cambio

Veamos a los dos equipos del Módulo 1 —el "Automático" (Enterprise) y el "Manual" (Community)— promover exactamente el mismo cambio de order-triage: el umbral de revisión manual a 5000. El objetivo es ver que llegan al mismo lugar por caminos distintos.

El Equipo Automático (Enterprise). El cambio ya está en la rama de staging, probado. Para promoverlo a prod, una persona abre la interfaz de n8n, revisa el diff en la propia UI, aprieta el botón de "push" para llevar el cambio a la rama de prod, y en la instancia de prod aprieta "pull". n8n importa el workflow por ellos. Verifican las credenciales, activan, listo. Qué obtienen: la promoción en unos clics, sin abrir una terminal.

El Equipo Manual (Community). El mismo cambio está commiteado y revisado en un pull request. Para promoverlo, siguen su runbook de la lección 2: git diff para confirmar el cambio, docker cp del order-triage.json al contenedor de prod, import:workflow para importarlo inactivo, verifican las credenciales en el editor, activan a mano. Qué obtienen: la misma promoción, con tres o cuatro comandos en la terminal en vez de botones.

Qué esperar si comparas el estado final de los dos: es indistinguible. En los dos, prod corre la versión con el umbral de 5000; en los dos, el repositorio de Git tiene el commit del cambio, con su diff y su historia; en los dos, el rollback está disponible volviendo al commit anterior. Un evaluador que abriera los dos repositorios no sabría cuál equipo pagó y cuál no. La diferencia no está en el resultado —es el mismo entregable—; está en que el Equipo Automático compró comodidad para producir ese resultado, y el Manual la cambió por unos comandos y por un entendimiento más profundo de qué pasa por dentro.

Ahora extiende el ejemplo mentalmente: ¿y si en vez de una promoción fueran treinta al día, hechas por ocho personas? El Equipo Manual empieza a sentir la fricción —coordinar quién exporta qué, evitar pisarse, no equivocarse de contenedor—, y ahí el botón del Equipo Automático empieza a pagarse. Con una promoción semanal, la fricción es cero y el botón es un lujo; con treinta diarias entre ocho personas, la fricción es real y el botón es una inversión. El mismo ejemplo, dos escalas, dos respuestas.

Lo que Enterprise trae de más, con honestidad

Para que la comparación no suene a "todo es igual, no pagues nunca", conviene ser justo con lo que la edición de pago sí agrega y el flujo CLI no replica del todo. No es la capacidad de versionar ni de promover —eso lo tienes gratis—, sino un conjunto de garantías de gobierno que importan a cierta escala:

• Control de acceso por roles (RBAC). Quién puede promover a prod, quién solo a staging, quién solo mira. En Community, el control de acceso vive en los permisos del repositorio de Git y en quién tiene acceso a cada contenedor; funciona, pero es menos granular y menos centralizado que un RBAC integrado.
• Registro de auditoría integrado. Quién promovió qué y cuándo, dentro de la propia herramienta. El flujo CLI deja ese rastro en la historia de Git (los commits tienen autor y fecha), que es un registro real y sólido, pero no es lo mismo que un log de auditoría corporativo con garantías de cumplimiento.
• External secrets. Leer secretos desde un gestor corporativo (Vault, AWS Secrets Manager). Para organizaciones con esa infraestructura y una política que la exige, es cumplimiento, no comodidad.

Reconocer esto con honestidad es parte de decidir bien. Para la enorme mayoría de los casos —quien aprende, el freelance, el equipo pequeño—, ninguna de estas garantías es necesaria, y el flujo CLI cubre todo. Para una organización grande con requisitos de cumplimiento, son exactamente lo que inclina la balanza. La regla no cambia: paga por lo que tu escala y tu gobierno de verdad piden, no por lo que suena profesional.

La matriz de decisión

Aquí está el criterio, afinado con la experiencia de promoción y rollback que ahora tienes. La pregunta no es "¿cuál es mejor?" —los dos producen el mismo entregable—, sino "¿cuál conviene para mi situación?".

Tu situación	Qué conviene	Por qué
Aprendiendo, proyecto personal, o portafolio	Flujo CLI	Gratis, produces el mismo artefacto, y entiendes cada pieza —lo que te hace evaluar la versión de pago con criterio si algún día la necesitas. Un repo hecho a mano demuestra más en una entrevista.
Freelance o cliente chico, promociones ocasionales	Flujo CLI	El runbook y el script automatizan lo tedioso; la comodidad de los botones no justifica el costo cuando promueves pocas veces.
Equipo pequeño (2–4), presupuesto ajustado	Flujo CLI, con repo compartido	La colaboración vive en el repo de GitHub (Módulo 1, lección 7), no en la instancia. Coordinan por pull requests; no necesitan pagar por multiusuario.
Equipo mediano/grande, muchas promociones al día	Considera Enterprise	Cuando la fricción de coordinar promociones manuales entre varias personas supera el costo de la licencia, los botones se pagan en tiempo ahorrado y errores evitados.
Requisitos de auditoría, control de acceso fino (RBAC), cumplimiento	Evalúa Enterprise	El source control nativo, el multiusuario con roles y external secrets traen garantías de gobierno que el flujo manual no da por sí solo.
Ya usan un gestor de secretos corporativo (Vault, AWS) con política obligatoria	Enterprise (external secrets)	Ahí external secrets deja de ser comodidad y pasa a ser cumplimiento; el flujo manual con .env no satisface la política.

Fíjate en dónde cae la línea: el flujo CLI cubre desde el que aprende hasta el equipo pequeño-mediano coordinado por repo; Enterprise empieza a valer cuando la escala, el gobierno o el cumplimiento entran en juego. No hay una respuesta universal; hay un cálculo. Y la variable que más lo mueve, en el contexto de este módulo, es cuántas promociones haces y cuánta gente las hace: la promoción manual escala mal cuando muchas personas la hacen muchas veces, y ese es el punto donde la comodidad integrada empieza a pagarse.

El cálculo honesto, en una frase

Si quieres una regla para llevarte, es esta: paga cuando el costo del tiempo manual, multiplicado por la frecuencia y el número de personas, supere el costo de la licencia —y ni un momento antes.

Un equipo de una persona que promueve una vez por semana: el tiempo manual es de minutos al mes; ninguna licencia se justifica. Un equipo de ocho que promueve treinta veces al día: el tiempo manual es de horas a la semana, repartido entre personas que además se pisan y se equivocan; ahí la licencia puede salir barata. El número exacto depende de tus sueldos y del precio del plan —que cambia, así que verifícalo en la página de precios de n8n antes de decidir—, pero la forma del cálculo es estable: tiempo × frecuencia × personas, contra el costo de la licencia. Todo lo demás es ruido.

Hagamos el cálculo con números de ejemplo, para que la fórmula deje de ser abstracta —y con la advertencia de siempre: son hipótesis para ilustrar el método, no datos de mercado—. Supón que cada promoción manual cuesta cinco minutos de trabajo cuidadoso. En el equipo de una persona con una promoción semanal, eso son veinte minutos al mes: un costo insignificante frente a cualquier suscripción. En el equipo de ocho con treinta promociones diarias, son treinta × cinco = 150 minutos al día, dos horas y media diarias repartidas, unas cincuenta horas al mes de trabajo que la feature integrada reduciría. Cincuenta horas mensuales de tiempo de gente técnica es, casi con seguridad, más caro que la licencia —y eso sin contar los errores que el trabajo manual introduce a ese volumen—. El primer caso no cruza el umbral ni de lejos; el segundo lo cruza con holgura. La fórmula no te da un "sí" o un "no" universal; te da el punto donde tu situación concreta cambia de respuesta.

Lo único que no cambia: el repositorio es la fuente de verdad

Aquí está el mensaje que quiero que te lleves por encima de la matriz, porque es el que sobrevive a cualquier decisión de plan.

Elijas el flujo que elijas, el repositorio de Git es la fuente de verdad. No la instancia de n8n, no los botones, no la feature de pago: el repositorio. En el flujo CLI, llegas al repo con comandos; en el source control nativo, llegas con botones; pero en los dos casos, el lugar donde vive la versión canónica de tus workflows —con su historia, sus diffs y sus versiones buenas para el rollback— es el repositorio de Git. Los dos flujos son dos puertas a la misma casa, y la casa es el repo.

Esto tiene tres consecuencias que valen para siempre:

El rollback funciona igual en los dos mundos. El runbook que escribiste en la lección 5 —volver al último JSON bueno del repo y re-importarlo— es válido pagues o no. En Enterprise, "re-importar" es un pull; en Community, es un import:workflow; pero "volver al último JSON bueno del repo" es idéntico, porque el repo es la fuente de verdad en ambos. Aprender el rollback a mano no fue tiempo perdido si algún día pagas: es el mismo concepto, con otra interfaz.

El conocimiento se transfiere; la comodidad, no. Git y Docker son estándares de la industria; funcionan con cualquier herramienta, no solo con n8n. Lo que aprendiste en el flujo CLI —versionar, promover, revisar diffs, revertir— se transfiere a cualquier plataforma que uses mañana. La feature integrada de pago te ata un poco más a la forma en que n8n hace las cosas: es más cómoda mientras estés en n8n, y menos transferible el día que no. No es un argumento para no pagar nunca —la comodidad es real—; es un factor más a pesar, y otra razón por la que, para aprender, el flujo manual invierte mejor tu tiempo.

Entender el manual te hace mejor con el automático. Si algún día administras el source control nativo de Enterprise, vas a entender exactamente qué hace cada botón por dentro —el push es un export + commit, el pull es un import— porque lo hiciste a mano. Eso te vuelve alguien que no solo aprieta botones, sino que sabe qué pasa cuando algo falla y el botón no basta. El que aprendió el manual opera el automático con criterio; el que solo conoció el automático se queda sin recursos el día que la abstracción se rompe.

Y las abstracciones se rompen. Un push que falla a medias, un conflicto entre dos ramas de entorno, un pull que trae una versión inesperada: cuando eso pasa, el botón no te dice qué hacer. Ahí, quien entiende el flujo CLI por debajo abre la terminal, mira el estado real del repositorio con git status y git log, y resuelve; quien solo conoce los botones abre un ticket de soporte y espera. Esa es la razón más práctica de aprender el camino manual aunque termines pagando: no es nostalgia por lo difícil, es que el día del problema, entender lo que hay debajo de la abstracción es la diferencia entre resolverlo tú en diez minutos y depender de que otro lo resuelva por ti.

Errores comunes

Creer que la versión de pago te da una capacidad que la gratis no tiene (conceptual). Qué pasa: alguien mira los botones de push/pull de Enterprise y concluye que sin ellos "no se puede promover bien". Después de este módulo, ya sabes que sí se puede: promoviste order-triage a prod con la CLI, revisaste el diff, escribiste el runbook. Por qué pasa: la interfaz pulida da la impresión de una capacidad exclusiva. Cómo detectarlo: si tu razón para considerar Enterprise es "para poder promover", revisa —ya sabes promover sin pagar—. Cómo corregirlo: separa capacidad de comodidad. La capacidad de promover, revisar y revertir la tienes gratis y la usaste en este módulo. Enterprise automatiza los pasos manuales; no agrega la capacidad. Paga por la comodidad si tu escala la justifica, no por una capacidad que ya tienes.

Pagar Enterprise "para hacerlo bien" siendo un equipo chico (práctico). Qué pasa: un equipo de dos o tres paga una suscripción cara convencido de que el source control nativo es "la forma profesional", cuando un repo de GitHub gratis y la CLI les daban el mismo artefacto. Por qué pasa: comprar comodidad se siente como "hacerlo en serio", y el flujo manual parece "de principiantes". Es al revés: el repo hecho a mano demuestra más dominio. Cómo detectarlo: si estás por pagar y tu equipo cabe en una sala chica y promueve pocas veces, revisa si de verdad necesitas la comodidad o solo te falta confianza en el flujo manual. Cómo corregirlo: usa el flujo CLI hasta que la fricción real —medida en tiempo × frecuencia × personas— supere el costo de la licencia. Pagar antes de ese punto es pagar por una sensación, no por una necesidad.

No pagar Enterprise cuando la escala o el cumplimiento sí lo piden (práctico, el error opuesto). Qué pasa: un equipo grande, con promociones constantes y una política corporativa de secretos, se aferra al flujo manual por principio ("todo gratis") y termina perdiendo más en tiempo coordinando y en riesgo de cumplimiento que lo que costaría la licencia. Por qué pasa: convertir "gratis" en ideología ciega el cálculo. Cómo detectarlo: si tu equipo pierde horas a la semana en promociones manuales que se pisan, o si incumples una política de secretos por usar .env, el flujo manual ya te está costando más de lo que ahorra. Cómo corregirlo: la decisión es un cálculo, no una bandera. Cuando tiempo × frecuencia × personas supera la licencia, o cuando el cumplimiento lo exige, pagar es la decisión correcta —y saber hacerlo a mano te deja administrar la versión de pago con criterio—.

Olvidar que el repositorio es la fuente de verdad en los dos flujos (conceptual). Qué pasa: alguien que migra a Enterprise empieza a tratar la instancia de n8n como la verdad —"lo que está en la UI es lo que vale"— y descuida el repositorio, perdiendo la historia, los diffs y la capacidad de rollback limpio. Por qué pasa: los botones hacen sentir que la instancia y el repo son lo mismo, y es fácil olvidar cuál manda. Cómo detectarlo: si tu plan de rollback depende de la instancia y no del repo, perdiste el norte. Cómo corregirlo: en los dos flujos, el repositorio es la fuente de verdad; la instancia es donde corre. El rollback vuelve al repo, el diff se lee del repo, la versión canónica vive en el repo. La feature de pago cambia cómo llegas al repo, no que el repo sea la verdad. No pierdas eso al ganar comodidad.

Ejercicios

Ejercicio 1 — Traduce botón a comando. Para cada acción del source control nativo de Enterprise, di qué comando o pasos del flujo CLI de esta guía hace lo mismo: (a) el botón de "push" de un workflow; (b) el botón de "pull" en la instancia de prod; (c) promover un cambio moviéndolo de la rama de staging a la de prod.

Ver solución

(a) El push equivale a export:workflow (con la CLI) + git commit: sacar el workflow de la instancia a un archivo y registrarlo en el repositorio. El botón hace los dos pasos de una vez.

(b) El pull en prod equivale a import:workflow --input=... contra el contenedor de prod (con el docker cp previo si hace falta): traer la versión del repo a la instancia. El botón importa por ti.

(c) Promover moviendo de rama equivale al ritual de la lección 2: sacas la versión buena del repo (de la rama correspondiente), la revisas con git diff / pull request, la re-importas al contenedor de prod con import:workflow, verificas las credenciales y la activas a mano. Enterprise encadena eso en botones y correspondencia rama-entorno; el resultado es el mismo.

Por qué funciona: traducir cada botón a su comando te demuestra en concreto que la feature de pago no hace nada nuevo —hace lo mismo con menos pasos manuales—. Y te confirma que aprender el flujo CLI no fue tiempo perdido: es entender qué hace el automático por dentro, que es justo lo que te deja administrarlo con criterio si algún día lo usas.

Ejercicio 2 — Aplica la matriz. Para cada equipo, decide "flujo CLI" o "considera Enterprise" y justifica con el cálculo tiempo × frecuencia × personas (o el cumplimiento): (a) tú solo, automatizando para tres clientes chicos, promoviendo cada uno una vez por semana; (b) una empresa con un equipo de diez que promueve entre tres entornos unas veinte veces al día y tiene una política corporativa que obliga a usar HashiCorp Vault; (c) un equipo de tres en una startup, presupuesto ajustado, promociones un par de veces por semana.

Ver solución

(a) Flujo CLI. Una persona, promociones semanales: el tiempo manual es de minutos al mes por cliente. Tiempo × frecuencia × personas es minúsculo; ninguna licencia se justifica. El runbook y el script cubren lo tedioso. Recomendación clara: gratis.

(b) Considera/evalúa Enterprise, con fuerza. Diez personas × veinte promociones al día es un volumen alto de trabajo manual que se pisa y admite errores; ahí los botones ahorran horas a la semana. Y la política obligatoria de Vault convierte external secrets de comodidad en cumplimiento: el flujo manual con .env no satisface esa política. Dos frentes de la matriz —escala de promoción y cumplimiento— apuntan a pagar.

(c) Flujo CLI, todavía. Tres personas, un par de promociones por semana: el tiempo manual es bajo y se coordina bien por pull requests en un repo compartido. El presupuesto ajustado y la baja frecuencia inclinan la balanza a gratis. Si la startup crece y las promociones se multiplican, se revisa la decisión —pero se revisa con el cálculo, no antes—.

Por qué funciona: los tres casos activan distintas partes de la matriz. El (a) y el (c) no cruzan el umbral de tiempo × frecuencia × personas; el (b) lo cruza por dos lados a la vez. La decisión no es ideológica —"gratis siempre" o "pagar es más pro"—; es un cálculo que ahora puedes hacer porque sabes exactamente qué pasos manuales estarías automatizando.

Ejercicio 3 — Defiende el repo como fuente de verdad. Un compañero que acaba de migrar a Enterprise te dice: "Con los botones de n8n ya no necesito preocuparme por el repositorio; la instancia es la que manda ahora". Escríbele una respuesta de tres o cuatro frases que le explique por qué el repositorio sigue siendo la fuente de verdad incluso con la feature de pago, y qué pierde si lo olvida.

Ver solución

Una respuesta posible:

"Cuidado con eso: los botones de Enterprise cambian cómo llegas al repositorio, no que el repositorio sea la fuente de verdad. El push y el pull siguen escribiendo y leyendo del repo de Git; la instancia es solo donde corre. Si empiezas a tratar la instancia como la verdad y descuidas el repo, pierdes justo lo que hace seguro el sistema: la historia de cambios, los diffs para revisar, y —lo más importante— la capacidad de rollback, que consiste en volver al último JSON bueno del repo y re-importarlo. El día que un cambio rompa prod, tu salida de emergencia es el repositorio, no la instancia. Los botones son comodidad para llegar al repo; el repo sigue siendo la casa."

Por qué funciona: la respuesta corrige la confusión más peligrosa de migrar a Enterprise —creer que la feature de pago mueve la fuente de verdad de lugar—. No lo hace: en los dos flujos, el repo manda. Perder eso al ganar comodidad es cambiar una red de seguridad por unos botones, que es un mal trato.

Resumen y siguiente paso

En esta lección tomaste, con toda la información en la mano, la decisión entre el flujo CLI a costo cero de esta guía y el source control nativo de Enterprise. Recordaste la distinción de fondo de los Módulos 1 y 3 —la capacidad de versionar es gratis, la feature integrada es de pago; paga por comodidad y escala, no por capacidad— y la afinaste con la dimensión que ahora sí viviste: la promoción entre entornos. Viste qué hace el source control nativo —push, pull y entornos por rama, cada botón reemplazando un comando que corres a mano— y comparaste los dos flujos paso a paso en la promoción, confirmando que producen el mismo entregable con distinta cantidad de trabajo manual. Aplicaste una matriz de decisión por tamaño de equipo, frecuencia de promoción, presupuesto y cumplimiento, con el cálculo honesto en una frase: paga cuando tiempo × frecuencia × personas supere el costo de la licencia, y ni un momento antes. Y grabaste lo que no cambia en ningún caso: el repositorio es la fuente de verdad en los dos mundos —el rollback funciona igual, el conocimiento se transfiere, y entender el manual te hace mejor con el automático—.

Antes de avanzar deberías poder: traducir cada botón del source control nativo a su comando del flujo CLI; aplicar la matriz de decisión a un equipo concreto usando el cálculo tiempo × frecuencia × personas; y explicar por qué el repositorio sigue siendo la fuente de verdad pagues o no.

La lección 7 vuelve a las manos y añade la última pieza automática del ciclo, esta vez gratis. Vas a poner un chequeo de CI en GitHub Actions que valida el JSON de tu workflow en cada commit, sin que nadie tenga que acordarse de revisarlo: un inspector automático en la puerta del repositorio. Y vas a armar el artefacto de portafolio —la captura del workflow más su export JSON versionado— que las ofertas piden como filtro de contratación, con la guía de cómo defenderlo en una entrevista. Es la penúltima parada antes del proyecto final que cierra la guía.

Recursos

• Source control and environments — n8n Docs — la documentación oficial de la feature de pago: push, pull y entornos por rama; léela para saber exactamente qué automatiza el "camino automático".
• Environments in n8n — n8n Docs — cómo n8n asocia entornos a ramas de Git en el source control nativo, la pieza específica de la promoción de pago.
• Community edition features — n8n Docs — la comparación oficial de qué trae Community gratis y qué es de pago; la fuente para verificar el estado actual de cada feature.
• n8n pricing — la página de precios, fuente de verdad sobre qué feature está en qué plan y a qué costo; verifica aquí antes de aplicar el cálculo de la matriz, porque los planes cambian.
• Pro Git — About Version Control — por qué Git es el estándar de la industria y transferible a cualquier herramienta; el fundamento de "el conocimiento se transfiere, la comodidad no".