7. Source control: Community vs Enterprise, con honestidad

Descripción

Al terminar esta lección vas a saber, sin ambigüedad, qué features de control de versiones y entornos trae n8n gratis y cuáles solo en los planes de pago, y vas a tener un criterio claro para decidir cuándo vale la pena pagar. Vas a poder ubicar en la interfaz de n8n 2.0 dónde vive el export/import que ya conoces y dónde aparece —bloqueada o disponible según tu plan— la superficie de source control integrada. Y, lo más importante, vas a salir con la certeza de que todo lo que enseña esta guía se puede hacer a costo cero con n8n Community.

Esto importa porque hay mucha confusión, y la confusión cuesta dinero o cuesta oportunidades. Unos creen que "n8n no versiona" y abandonan la herramienta (la queja del foro de la lección 3). Otros creen que necesitan Enterprise para versionar y pagan sin necesitarlo, o se rinden pensando que no tienen presupuesto. Las dos creencias son falsas. La verdad tiene un matiz que esta lección te da entero: la feature integrada de source control es de pago, pero la capacidad de versionar es gratis y es exactamente la que vas a aprender. Saber distinguir la feature de la capacidad es lo que te deja decidir con la cartera y no con el miedo.

Conexión con el módulo: las lecciones anteriores construyeron el problema (3, 4, 5) y el modelo que lo resuelve (6). Esta lección le pone precio a ese modelo: cada pieza del ciclo editar → exportar → commit → revisar → promover existe en dos versiones, una gratis que haces con tus manos y una de pago que la herramienta hace por ti. Es también la lección que define el camino por defecto de toda la guía —self-hosted Community a costo cero— y explica por qué ese camino es una decisión pedagógica y económica, no una limitación. El proyecto de la lección 8 se hace enteramente en Community, sin pagar nada, como todo lo que sigue.

Automático o manual: la misma capacidad, dos formas

Piensa en la diferencia entre un auto de transmisión manual y uno automático.

Los dos hacen exactamente lo mismo: mover el auto, cambiar de velocidad según la necesidad. En el manual, tú operas el embrague y la palanca: decides cuándo cambiar, lo haces con tus manos y tus pies, tienes control total y el auto cuesta menos. En el automático, el auto cambia de velocidad solo: aprietas el acelerador y la máquina se encarga de lo demás. Es más cómodo, más suave, y cuesta más —tanto al comprarlo como al mantenerlo—.

Nadie diría que un auto manual "no puede cambiar de velocidad". Cambia perfectamente; lo cambias tú. La transmisión automática no agrega una capacidad nueva —los dos autos hacen los mismos cambios—; agrega comodidad: hace por ti lo que en el manual haces a mano.

n8n y el control de versiones funcionan igual. La capacidad de versionar tus workflows con Git existe en las dos ediciones. La diferencia es quién opera la palanca:

• En Community (gratis), tú operas la palanca: exportas con la CLI, haces los commits con Git, gestionas los entornos con Docker. Control total, cero costo, un poco más de trabajo manual. Es el "manual". Es lo que enseña esta guía.
• En Enterprise/Business (de pago), n8n opera la palanca: hay botones en la interfaz que hacen push y pull a Git, que crean entornos, que sincronizan todo. Más cómodo, más suave, cuesta una suscripción mensual. Es el "automático".

Guarda esta distinción, porque es la que deshace toda la confusión: la feature integrada de source control es de pago; la capacidad de versionar es gratis. Cuando alguien dice "n8n no tiene control de versiones en Community", está diciendo, en realidad, "el auto no tiene transmisión automática" —lo cual es cierto y no significa que el auto no cambie de velocidad—.

Qué NO trae Community (y qué significa cada ausencia)

Seamos precisos sobre qué features viven detrás del muro de pago, porque cada una tiene una historia distinta y una consecuencia distinta para esta guía. Con la advertencia de siempre: los planes y sus límites cambian, así que confirma en la página de precios de n8n el estado actual antes de tomar una decisión de dinero.

Feature de pago	Qué hace	Qué usamos en su lugar (gratis)
Source control (Git) integrado	Botones en la UI para push/pull a un repo Git, entornos por rama	La CLI de n8n + Git a mano (Módulos 2 y 3)
Entornos nativos	dev/staging/prod gestionados por la herramienta	Un Docker Compose por entorno (Módulo 4)
External secrets	Leer secretos desde un gestor externo (Vault, AWS, etc.)	Variables de entorno y archivos .env por entorno (Módulo 4)
Variables	Variables de proyecto configurables desde la UI	Variables de entorno vía Docker (Módulo 4)
Multiusuario y compartir	Varios usuarios en una instancia, compartir workflows/credenciales	El repo Git compartido coordina al equipo (Módulos 2 y 3)

Vamos una por una, porque entender la ausencia es entender por qué la alternativa gratis funciona.

Source control integrado. Es la feature estrella y la que da nombre a la lección. En los planes de pago, n8n conecta tu instancia a un repositorio Git y te da botones para enviar (push) tus workflows al repo y traerlos (pull) de vuelta, todo desde la interfaz. Lo que envía al repo, 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. En Community, este puente automático no existe, pero tú puedes construir el mismo puente a mano: exportas con la CLI y haces el commit con Git. El resultado en el repo es equivalente; lo que cambia es que aprietas los botones tú. Está disponible en los planes Business y Enterprise.

Entornos nativos. En los planes de pago, la herramienta gestiona dev/staging/prod respaldados por ramas de Git: cambias de entorno y n8n sincroniza. En Community, montas cada entorno como una instancia separada con su propio Docker Compose (Módulo 4). Es más manual —levantas contenedores— pero te da un aislamiento total y real entre entornos, y no cuesta nada. De hecho, para aprender, el camino manual enseña más: ves de verdad qué es un entorno aislado en vez de que la herramienta te lo esconda.

External secrets. Esta es la más exclusiva: leer secretos desde un gestor externo profesional (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, y otros) está disponible solo en Enterprise, ni siquiera en los planes intermedios. Es una comodidad de seguridad para organizaciones grandes que ya tienen un gestor de secretos corporativo. En esta guía manejamos los secretos con variables de entorno y archivos por entorno, que es el estándar gratuito y perfectamente sólido para casi todos los casos (Módulo 4).

Variables. Las variables de proyecto configurables desde la interfaz son de pago. En su lugar usamos variables de entorno vía Docker, que hacen el mismo trabajo —darle al workflow valores de configuración que cambian por entorno— sin costo. La restricción de n8n 2.0 sobre cómo el nodo Code accede a variables de entorno es un tema aparte que trata el Módulo 4; por ahora basta saber que hay un camino gratuito.

Multiusuario y compartir. Community es, en esencia, de un solo usuario: tener varios usuarios en una instancia y compartir workflows o credenciales entre ellos es de pago. Aquí hay un matiz importante que resuelve el modelo de la lección 6: no necesitas multiusuario en la instancia para colaborar, porque la colaboración vive en el repositorio, no en la instancia. Dos personas pueden trabajar sobre order-triage compartiendo el repo cumbre-automations en GitHub —eso es gratis y es donde Git brilla—, cada una con su propia instancia de dev. La coordinación pasa por el repo (source), no por la instancia (runtime), exactamente como dice el modelo. El multiusuario de pago es una comodidad para equipos que quieren compartir la misma instancia; el repo compartido resuelve la colaboración sin él.

Fíjate en el patrón de las cinco: en ningún caso la ausencia de la feature de pago te impide hacer la cosa. En todos, hay un camino gratuito que hace lo mismo con más trabajo manual. Eso es lo que significa que Community traiga "casi todo n8n": lo que falta son comodidades y features para organizaciones grandes, no la capacidad de versionar, aislar entornos y probar.

Qué SÍ puedes hacer gratis: todo lo de esta guía

Démosle la vuelta a la tabla, porque este es el mensaje que importa. Con n8n Community, gratis, self-hosted en tu máquina, puedes hacer todo el ciclo del dueño del sistema:

• Versionar tus workflows con Git, con historial completo, revisión por diff y rollback (Módulos 2 y 3).
• Estructurar un repositorio documentado, con las credenciales fuera y el JSON normalizado para diffs limpios (Módulo 3).
• Aislar entornos dev/staging/prod de verdad, cada uno con sus credenciales y su clave de cifrado (Módulo 4).
• Probar en sandbox con datos sintéticos, credenciales de prueba, dry runs y aserciones, incluso probando workflows con nodos AI Agent a costo cero con modelos locales (Módulo 5).
• Promover entre entornos y revertir con un runbook, más un chequeo automático que valida el JSON en cada cambio con GitHub Actions gratis (Módulo 6).

Ese es el proyecto final de la guía, el artefacto de portafolio de la lección 2, y se produce entero sin pagar una suscripción. La única "cuenta" que vas a abrir es la de GitHub, que es gratis para repositorios como este, y opcionalmente la de un proveedor de IA para el nodo AI Agent —y en el Módulo 5 vemos cómo probar incluso eso a costo cero con modelos locales—.

Por eso el camino por defecto de esta guía es self-hosted Community a costo cero, y no es una concesión para quien no tiene presupuesto: es la decisión correcta para aprender. El camino manual te obliga a entender cada pieza —qué es un commit, qué es un entorno aislado, qué es una credencial por entorno— en vez de apretar un botón que lo esconde. Cuando termines, no solo vas a poder hacerlo gratis; vas a entender lo que la versión de pago automatiza, que es justo lo que te hace capaz de evaluarla.

Un escalón gratis que conviene subir: la Community registrada

Hay un matiz dentro de "gratis" que vale la pena conocer. n8n ofrece, sin costo, una edición Community registrada: sigues sin pagar, pero al registrar tu instancia con un correo desbloqueas algunas comodidades que la Community "a secas" no trae. Al momento de escribir esta guía, esas comodidades incluyen las carpetas (para organizar tus workflows), capacidades de depuración en el editor y el seguimiento de datos de ejecución personalizados —todas útiles, todas gratis—.

Es un escalón que conviene subir porque no cuesta nada y mejora la experiencia, sobre todo las carpetas cuando el número de workflows crece. Que quede claro para no generar confusión: la Community registrada sigue sin traer el source control integrado, los entornos nativos ni external secrets —esos siguen siendo de pago—. No cambia nada de lo que enseña esta guía; simplemente hace tu instancia gratuita un poco más cómoda. Verifica qué incluye la Community registrada en tu versión, porque, como todo lo demás, la lista evoluciona.

Dónde vive todo esto en la interfaz de n8n 2.0

Ubiquemos las piezas en la pantalla, para que sepas qué estás viendo. Con la advertencia habitual: la interfaz de n8n cambia entre versiones; verifica las ubicaciones y etiquetas exactas en tu propia instancia.

El export/import que ya conoces vive en el menú de tres puntos (⋯) del workflow abierto, arriba a la derecha: ahí están Download, Import from File e Import from URL (lección 3). Esta es la puerta gratuita por la que sacas el JSON, y es la que vas a usar en el proyecto de la lección 8. No depende del plan; está en Community.

La superficie de source control integrada aparece en la configuración de la instancia, no en el menú del workflow. En una instancia de pago con la feature activada, vas a ver una sección de Source Control donde conectas el repositorio Git y aparecen los botones de push y pull. En Community, esa sección o no aparece, o aparece como una feature bloqueada que te invita a mejorar de plan. Que la veas bloqueada no es un problema: significa que estás viendo el "automático" que no vas a usar, porque vas a hacer lo mismo con la CLI y Git.

Las variables y los entornos nativos, cuando existen (planes de pago), viven también en la configuración de la instancia y en la gestión de proyectos. En Community no los vas a encontrar ahí, y está bien: los tuyos van a vivir en tus archivos de Docker Compose y .env (Módulo 4), fuera de la interfaz de n8n, que es donde el modelo source/runtime dice que deben vivir de todos modos.

La conclusión de este recorrido: la única superficie de la interfaz que necesitas para esta guía es el menú de export/import, que es gratuito. Todo lo demás —commits, entornos, secretos— lo manejas fuera de n8n, con herramientas gratuitas (Git, Docker), que es precisamente lo que te da el control y la portabilidad que un botón integrado te quitaría.

Ejemplo trabajado: dos equipos, el mismo resultado

Comparemos dos equipos que logran exactamente lo mismo —order-triage versionado, con tres entornos y prueba en sandbox— por caminos distintos.

Equipo Automático (Business/Enterprise). Pagan una suscripción. Conectan su instancia a GitHub desde la sección de Source Control. Para versionar un cambio, aprietan "push" y n8n envía el workflow al repo. Para promover, cambian de entorno en la interfaz y n8n sincroniza desde la rama correspondiente. Los secretos los leen desde su Vault corporativo con external secrets. Qué obtienen: comodidad, menos pasos manuales, y features de organización grande (multiusuario, RBAC). Qué pagan: la suscripción mensual, que escala con el equipo.

Equipo Manual (Community). No pagan nada. Para versionar un cambio, exportan con la CLI de n8n y hacen git commit (Módulos 2 y 3). Para los entornos, tienen tres carpetas de Docker Compose —dev, staging, prod— cada una levantando su instancia aislada (Módulo 4). Los secretos viven en archivos .env por entorno. Coordinan compartiendo el repo cumbre-automations en GitHub. Qué obtienen: exactamente el mismo resultado —workflow versionado, entornos aislados, prueba en sandbox, rollback— más un entendimiento profundo de cada pieza. Qué pagan: cero, a cambio de operar la palanca a mano.

Qué esperar si comparas los dos repositorios de GitHub al final: son prácticamente indistinguibles. Los dos tienen el JSON versionado, la historia de commits, la estructura documentada. Un evaluador que abra cualquiera de los dos ve a un dueño del sistema. La diferencia no está en el artefacto; está en cuánta comodidad compraste para producirlo. Y para aprender —y para un portafolio— el camino manual no es inferior: es superior, porque demuestra que entiendes lo que el botón automatiza.

El criterio: cuándo vale la pena pagar

Terminemos con lo que de verdad necesitas para decidir. Pagar por la edición con source control integrado, entornos nativos y external secrets tiene sentido en situaciones concretas, y no en otras. Aquí está el criterio honesto.

Vale la pena pagar cuando:

• El equipo es grande y necesita compartir la misma instancia con varios usuarios, roles y permisos (RBAC). La coordinación por repo funciona, pero a cierta escala la gestión de accesos integrada ahorra fricción real.
• La organización ya tiene un gestor de secretos corporativo (Vault, AWS Secrets Manager) y una política que exige usarlo. Ahí external secrets no es comodidad, es cumplimiento.
• El costo del tiempo manual supera el costo de la suscripción. Si tu equipo hace decenas de promociones al día y cada paso manual cuesta minutos que se pagan caro, automatizar con la feature integrada puede salir más barato que hacerlo a mano.
• Necesitas soporte comercial y garantías que solo vienen con un contrato de pago.

No vale la pena pagar cuando:

• Estás aprendiendo. El camino manual enseña más y no cuesta nada.
• Trabajas solo o en un equipo chico que puede coordinar por un repo compartido.
• Tus secretos caben cómodamente en archivos .env por entorno, que es el caso de la enorme mayoría de los proyectos.
• Quieres un artefacto de portafolio. El repo hecho a mano demuestra más capacidad que el generado por botones.

La regla de fondo: paga por comodidad y por escala, no por capacidad. La capacidad —versionar, aislar, probar, promover— la tienes gratis. Si algún día pagas, que sea una decisión de "esto me ahorra tiempo o me lo exige mi organización", tomada con los ojos abiertos porque ya sabes hacer a mano lo que el botón hace. Nunca pagues por miedo a que "sin pagar no se puede", porque sí se puede, y esta guía te lo demuestra módulo por módulo.

Hay una ventaja del camino manual que rara vez se nombra y que conviene tener presente: portabilidad. Cuando versionas con Git y la CLI, tu repositorio y tu conocimiento no dependen de n8n. Git es el estándar de la industria y funciona con cualquier herramienta; Docker Compose levanta entornos para cualquier cosa, no solo para n8n. Si mañana tu proyecto migra a otra plataforma, o si trabajas en un equipo que usa varias, todo lo que aprendiste se transfiere. La feature integrada de pago, en cambio, 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 que pesar, y otra razón por la que, para aprender, el camino manual invierte mejor tu tiempo.

Errores comunes

Creer que "sin Enterprise no se puede versionar" y rendirse (conceptual). Qué pasa: alguien lee que el source control de n8n es de pago, concluye que versionar workflows requiere presupuesto que no tiene, y no versiona nada. Se queda del lado del constructor por una creencia falsa. Por qué pasa: la comunicación de n8n —razonablemente— destaca la feature integrada, y es fácil confundir "la feature integrada es de pago" con "la capacidad es de pago". Cómo detectarlo: si tu razón para no versionar es "no tengo Enterprise", tienes esta creencia. Cómo corregirlo: separa la feature de la capacidad. La capacidad de versionar es Git + tus workflows exportados, y las dos cosas son gratis. La feature de pago solo te ahorra apretar los botones a mano. Esta guía entera se hace en Community, gratis; el error es no haberlo sabido.

Pagar por Enterprise para tener versionado cuando no lo necesitas (práctico). Qué pasa: el error opuesto. Un equipo chico paga una suscripción cara "para poder versionar", cuando un repo de GitHub gratis y la CLI le daban lo mismo. Por qué pasa: es más fácil comprar comodidad que aprender el camino manual, y la suscripción se siente como "hacerlo bien". Cómo detectarlo: si estás por pagar por source control y tu equipo cabe en una sala chica, revisa si de verdad necesitas la comodidad o solo te falta aprender a hacerlo a mano. Cómo corregirlo: aprende el camino gratuito primero (esta guía). Si después de saber hacerlo a mano concluyes que la comodidad vale el precio para tu escala, entonces la decisión es informada. Pagar antes de saber es pagar por miedo.

Confundir "los secretos no viajan al repo" con "no tengo que preocuparme por los secretos" (conceptual y de seguridad). Qué pasa: alguien lee que el source control (integrado o manual) manda al repo solo stubs de credenciales, no los secretos, y concluye que el manejo de secretos está resuelto solo. Pero los secretos tienen que existir en cada entorno, y gestionarlos —crearlos, rotarlos, mantenerlos distintos entre dev y prod— es un trabajo real que el repo no hace por ti. Por qué pasa: "los secretos no están en el repo" suena a "los secretos están resueltos". Cómo detectarlo: si tu plan para los secretos es "el repo no los sube, así que ya está", te falta la otra mitad. Cómo corregirlo: entiende que separar los secretos del repo es solo el primer paso; el segundo es gestionarlos por entorno, que es el Módulo 4 completo, lo pagues o no.

Tomar los planes de esta lección como fijos (práctico). Qué pasa: alguien memoriza "source control es Business y Enterprise, external secrets es solo Enterprise" y lo repite como verdad permanente, cuando n8n reorganiza sus planes cada cierto tiempo. Por qué pasa: es natural tratar una tabla de precios como estable. Cómo detectarlo: si estás a punto de tomar una decisión de dinero basándote solo en lo que dice esta lección, detente. Cómo corregirlo: la página de precios de n8n es la fuente de verdad sobre qué feature está en qué plan, y cambia. Usa esta lección para entender la estructura —feature de pago contra capacidad gratuita, comodidad contra escala— que es estable, y verifica los detalles del plan en la fuente oficial antes de pagar.

Ejercicios

Ejercicio 1 — Separa feature de capacidad. Para cada afirmación, di si es verdadera o falsa y corrígela si hace falta: (a) "En n8n Community no se pueden versionar los workflows." (b) "El source control integrado de n8n envía tus secretos al repositorio." (c) "Para tener entornos dev/staging/prod hay que pagar Enterprise." (d) "External secrets es una comodidad para organizaciones con un gestor de secretos corporativo."

Ver solución

(a) Falsa. En Community no está la feature integrada de source control, pero la capacidad de versionar sí: se hace con la CLI de n8n y Git, gratis. Es el corazón de esta guía.

(b) Falsa. El source control (integrado o manual) envía al repo los workflows, las etiquetas y stubs vacíos de credenciales y variables —no los secretos reales—, que viajan solo referenciados, igual que en el export manual (lección 4).

(c) Falsa. Los entornos nativos gestionados por la herramienta son de pago, pero puedes tener entornos aislados de verdad, gratis, con un Docker Compose por entorno (Módulo 4). "Pagar" te da comodidad, no la capacidad.

(d) Verdadera. External secrets (Enterprise) sirve para leer secretos desde gestores como Vault o AWS Secrets Manager; es útil cuando la organización ya tiene esa infraestructura y una política que la exige. Para la mayoría, los archivos .env por entorno bastan.

Por qué funciona: las cuatro afirmaciones son las confusiones más comunes, y todas se disuelven con la misma distinción —feature de pago contra capacidad gratuita—. Si las corregiste bien, ya no vas a rendirte por creer que "no se puede sin pagar" ni pagar por miedo.

Ejercicio 2 — Decide por dos escenarios. Para cada equipo, decide si le recomendarías pagar por la edición con source control integrado o quedarse en Community, y justifica en dos o tres frases: (a) Una persona que automatiza para su propio negocio y quiere un portafolio. (b) Una empresa de 40 personas con un equipo de automatización de 8, que ya usa HashiCorp Vault para todos sus secretos corporativos y hace despliegues varias veces al día.

Ver solución

(a) Community. Trabaja solo, así que no necesita multiusuario ni compartir instancia; un repo de GitHub le da toda la colaboración y el historial. Quiere portafolio, y el repo hecho a mano demuestra más capacidad que uno generado por botones. Pagar no le agregaría nada que valga el costo. Recomendación clara: quédate gratis y aprende el camino manual.

(b) Pagar tiene sentido. Un equipo de 8 que despliega varias veces al día paga caro cada paso manual, así que la comodidad del source control integrado puede salir más barata que el tiempo. Ya tienen Vault, y una organización de ese tamaño suele tener políticas que exigen usar el gestor corporativo, así que external secrets deja de ser comodidad y pasa a ser cumplimiento. Y con 8 personas, el multiusuario y los roles (RBAC) ahorran fricción real. Aquí el criterio "escala y comodidad" se cumple en los tres frentes.

Por qué funciona: los dos escenarios están construidos para activar los dos lados del criterio. El (a) no cumple ninguna condición de "vale la pena pagar"; el (b) cumple tres. La decisión no es ideológica —"gratis siempre" o "pagar siempre es más profesional"—; es un cálculo de escala, cumplimiento y costo del tiempo. Aprender a hacer ese cálculo con los ojos abiertos es el punto de la lección.

Ejercicio 3 — Explícaselo a tu jefe. Tu jefe te dice: "necesitamos control de versiones para los workflows, cotiza cuánto cuesta el plan Enterprise de n8n". Escribe la respuesta que le darías en cuatro o cinco frases, honesta y sin vender humo, que le presente las dos opciones y una recomendación.

Ver solución

Una respuesta posible:

"Podemos versionar los workflows de dos formas. La cara: pagar el plan con source control integrado, que pone botones en n8n para sincronizar con Git y agrega entornos nativos y gestión de secretos corporativos; tiene sentido si crecemos, si necesitamos varios usuarios con roles, o si vamos a usar nuestro Vault. La gratis: usar Git y la CLI de n8n sobre un repositorio de GitHub, que nos da exactamente el mismo versionado —historial, revisión, rollback— con un poco más de trabajo manual y cero costo de licencia. Para nuestro tamaño actual, mi recomendación es empezar por la gratis: nos da la capacidad completa ya, nos hace entender el sistema, y si más adelante el trabajo manual empieza a costarnos tiempo, migramos a la de pago con conocimiento de causa. Empezar gratis no cierra la puerta a pagar después; empezar pagando sí nos cuesta desde el primer mes algo que quizás no necesitemos."

Por qué funciona: la respuesta no dice "gratis siempre" ni "hay que pagar"; presenta las dos opciones con su criterio y recomienda según el contexto, dejando la puerta abierta. Es la respuesta de alguien que entiende la diferencia entre feature y capacidad, y que le ahorra dinero a la empresa sin sacrificar la capacidad. Es, otra vez, una respuesta de dueño del sistema: piensa en el costo total, no solo en la comodidad.

Resumen y siguiente paso

En esta lección separaste, de una vez por todas, la feature de pago de la capacidad gratuita, con la imagen de la transmisión: el auto manual (Community) y el automático (Enterprise/Business) hacen los mismos cambios de velocidad; el automático solo hace por ti lo que en el manual haces a mano. Viste qué features viven detrás del muro de pago —source control integrado, entornos nativos, external secrets, variables, multiusuario y compartir— y qué usas en su lugar, gratis, en cada caso: la CLI de n8n y Git, un Docker Compose por entorno, archivos .env, y el repo compartido que resuelve la colaboración sin multiusuario. Confirmaste que todo lo que enseña esta guía se hace en Community a costo cero, y que ese camino por defecto no es una limitación sino la mejor forma de aprender, porque te hace entender lo que la versión de pago automatiza. Ubicaste en la interfaz de n8n 2.0 dónde vive el export/import gratuito y dónde aparece —bloqueada o no— la superficie de source control. Y saliste con un criterio claro: paga por comodidad y por escala, no por capacidad, y nunca por miedo a que "sin pagar no se puede".

Antes de avanzar deberías poder: explicar la diferencia entre la feature integrada de source control y la capacidad de versionar; nombrar tres cosas que Community no trae y su alternativa gratuita; y dar un criterio para decidir cuándo vale la pena pagar.

Con esto cierras la parte conceptual del módulo. Ya sabes qué es versionar (1), por qué el mercado lo pide (2), por qué el export/import no basta (3), qué hay en el JSON (4), qué se rompe al moverlo (5), el modelo que lo ordena todo (6) y qué cuesta cada pieza (7). Solo falta poner las manos: la lección 8 es el proyecto del módulo. Vas a tomar order-triage —o cualquier workflow tuyo—, exportarlo de verdad desde el editor, leer su JSON campo por campo con los ojos que te dio la lección 4, e identificar cada campo que se rompería al moverlo con la lista de la lección 5. El entregable —el JSON exportado más una nota de riesgos de portabilidad— es la primera piedra del artefacto de portafolio, y la base sobre la que se construyen los cinco módulos que siguen.

Recursos

• Compare editions / 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.
• Source control and environments — n8n Docs — la feature integrada de pago (Business y Enterprise); léela para saber exactamente qué automatiza el "camino automático".
• External secrets — n8n Docs — la feature de Enterprise para leer secretos desde gestores externos; el criterio de cuándo de verdad la necesitas está en esta lección.
• Choose how to use n8n — n8n Docs — la guía oficial para elegir entre Community self-hosted, Cloud y Enterprise; complementa el criterio de decisión de esta lección.
• n8n pricing — la página de precios, que es la fuente de verdad sobre qué feature está en qué plan; verifica aquí antes de cualquier decisión de dinero, porque los planes cambian.