7. Environments nativos (Enterprise): cuándo vale pagar

Descripción

Al terminar esta lección vas a poder describir qué ofrece la feature nativa de entornos y control de versiones de n8n —la que vive en los planes de pago—, contrastarla con honestidad frente al patrón self-hosted a costo cero que construiste en este módulo, y tomar una decisión informada con una matriz que pesa tamaño de equipo, presupuesto, cumplimiento y quién opera el sistema. Vas a saber, además, cómo sería la migración de self-hosted a Cloud si tu equipo crece, y por qué el trabajo que hiciste en este módulo hace esa migración fácil en vez de traumática.

Esto importa porque un dueño del sistema no solo sabe construir: sabe decidir, y decidir bien sobre dinero es parte del oficio. Es tan malo pagar por una feature que no necesitas —quemar presupuesto en comodidad para un equipo de una persona— como negarte a pagar cuando el cumplimiento de tu empresa lo exige y terminar con un montaje frágil y sin auditoría. Esta lección no te vende ni te disuade: te da el criterio para que la decisión sea tuya, con los ojos abiertos. Y es la última pieza de honestidad de planes del módulo: después de ver feature por feature qué es gratis y qué se paga, aquí miras el paquete completo.

Conexión con el módulo: las lecciones 2 a 6 construyeron el patrón self-hosted a costo cero —tres stacks aislados con Docker Compose, claves y credenciales por entorno, secretos en el .env—. Esta lección pone ese patrón entero en la balanza frente a la alternativa de pago, para que sepas exactamente qué estás eligiendo cuando eliges gratis, y cuándo convendría cambiar. La lección 8, el proyecto, te hace demostrar el patrón self-hosted funcionando; esta te da el marco para saber cuándo ese patrón es el correcto y cuándo no. En el Módulo 6, lección 6, vas a retomar esta misma decisión desde el ángulo del control de versiones (Git nativo vs. el flujo CLI); aquí la ves desde el ángulo de los entornos.

Comprar la casa amueblada o amueblarla tú

Antes de los detalles, la imagen que ordena la decisión.

Cuando alguien necesita un lugar donde vivir, tiene dos caminos honestos. Puede comprar una casa amueblada, con todo listo: entra, y ya están la cocina equipada, los muebles puestos, el servicio de mantenimiento contratado. Paga más, pero no tiene que montar nada ni saber de plomería. O puede comprar la casa vacía y amueblarla él: cuesta menos dinero, pero tiene que elegir cada mueble, armarlo, y arreglar él mismo la llave que gotea. El resultado —un lugar donde vivir— es el mismo; lo que cambia es cuánto pagas en dinero y cuánto pagas en trabajo y conocimiento.

Esa es exactamente la decisión entre la feature nativa de entornos (Enterprise) y el patrón self-hosted de esta guía. La feature nativa es la casa amueblada: entornos y control de versiones ya integrados en la interfaz, con botones, soporte y mantenimiento incluido. Pagas una suscripción, y a cambio no montas Docker Compose ni gestionas claves a mano. El patrón self-hosted es la casa que amueblas tú: el mismo resultado —entornos aislados, versionados, seguros— pero armado por ti con herramientas gratuitas, a cambio de tu trabajo y del conocimiento que ganaste en este módulo.

Ninguno de los dos es "el correcto" en abstracto. El correcto depende de cuánto vale tu tiempo, cuánto presupuesto tienes, qué exige tu empresa y quién va a operar el sistema. La decisión, como comprar casa, es personal y contextual. Lo que esta lección te da es cómo pensarla bien.

Qué ofrece la feature nativa, exactamente

Seamos precisos sobre qué compras, porque decidir sobre algo que no conoces es adivinar. La feature nativa de n8n —entornos y control de versiones (source control)— vive, según la documentación oficial, en los planes de pago; en el momento de escribir esta guía, en los planes Business y Enterprise (los nombres y el reparto exacto de features cambian con el tiempo, así que este dato conviene confirmarlo siempre en la página de precios de n8n cuando lo leas). Lo que ofrece:

Entornos conectados por Git, desde la interfaz. Enlazas cada instancia de n8n —development, staging, production— a una rama distinta de un repositorio de Git. El trabajo se mueve entre entornos con un patrón de push y pull desde la propia interfaz de n8n: construyes en development, haces push a su rama, y luego pull desde staging para llevar el cambio. No editas archivos JSON a mano ni corres comandos de la CLI: n8n lo hace por ti con botones.

Control de versiones integrado. El push guarda en Git una copia de tus workflows y tags, más los stubs (esqueletos, sin valores secretos) de credenciales y variables. El pull los trae de vuelta a la instancia. Es, en esencia, el flujo del Módulo 3 y 6 de esta guía —exportar, versionar, promover— pero automatizado dentro de n8n, sin que salgas a la terminal.

Control de acceso y roles. Solo los dueños o administradores de la instancia pueden habilitar y configurar el control de versiones y hacer push/pull. En equipos grandes, esa gobernanza de quién puede promover a producción importa.

En una frase: la feature nativa automatiza y le pone interfaz al mismo ciclo de vida que esta guía te enseña a hacer a mano. No hace nada conceptualmente distinto de lo que ya sabes; te lo hace más cómodo y gobernado. Ese es, exactamente, el valor que compras: comodidad, integración y soporte, no una capacidad que de otro modo sería imposible.

Lo que compras y lo que no

Vale la pena separar, sin marketing, qué te da de verdad la feature de pago sobre el patrón self-hosted, y qué no.

Lo que sí te da:

• Comodidad en la interfaz. Promover un workflow es un botón, no una secuencia de comandos. Para quien no vive en la terminal, es una diferencia grande.
• Menos trabajo de montaje y mantenimiento. No configuras Docker Compose, no gestionas claves de cifrado a mano, no escribes scripts de exportación. n8n se encarga.
• Soporte y garantías. Un plan de pago viene con soporte del proveedor y, según el nivel, acuerdos de servicio (SLA). Cuando algo se rompe a las tres de la mañana, hay a quién llamar.
• Features de empresa que suelen venir en el mismo paquete. SSO, control de acceso por roles (RBAC), registros de auditoría, secretos externos (los de la lección 6). Rara vez necesitas "solo entornos"; normalmente los entornos vienen en un plan que trae todo esto junto, y a veces el resto del paquete es lo que de verdad justifica el gasto.

Lo que no te da (porque ya lo tienes gratis):

• El aislamiento en sí. El aislamiento real entre entornos lo da la infraestructura —Docker Compose—, y eso es gratis. La feature de pago no aísla "mejor"; aísla más cómodo. Un cambio en tu dev self-hosted no toca tu prod self-hosted, igual que con la feature nativa.
• La capacidad de versionar. Versionar con Git es gratis; lo hiciste en los Módulos 2 y 3. La feature integrada te ahorra salir a la terminal, no te habilita algo que sin ella no podrías.

Es importante tener esto claro para no caer en el marketing ni en su opuesto. La feature de pago no es humo —resuelve problemas reales de comodidad, gobernanza y escala—, pero tampoco es magia: no te da entornos "de verdad" que lo gratis no te dé. Te da los mismos entornos con menos fricción y más servicios alrededor.

La matriz de decisión honesta

Con las dos opciones claras, veamos cómo elegir. La decisión gira sobre cuatro ejes; míralos uno por uno y luego júntalos.

Eje 1 — Tamaño del equipo. Una persona o dos que se coordinan hablando no necesitan la gobernanza de push/pull con roles: el patrón self-hosted les sobra. A partir de varias personas que tocan los mismos workflows, promueven a producción y necesitan reglas de quién puede qué, la interfaz gobernada empieza a pagar su precio. Cuanto más grande y menos coordinado el equipo, más vale la feature nativa.

Eje 2 — Presupuesto. El patrón self-hosted cuesta cero en licencias; cuesta tu tiempo. La feature nativa cuesta una suscripción; te ahorra tiempo. La pregunta honesta es: ¿cuánto vale tu tiempo comparado con el costo del plan? Para alguien que aprende, o un proyecto sin ingresos, el costo del plan es prohibitivo y el tiempo es lo que sobra: self-hosted. Para una empresa donde una hora de tu tiempo cuesta más que el plan mensual, pagar puede salir barato.

Eje 3 — Cumplimiento y auditoría. Este eje puede decidir solo. Si tu empresa opera bajo requisitos de cumplimiento —un sector regulado, un cliente que exige auditoría, una certificación de seguridad—, probablemente necesites registros de auditoría, SSO, RBAC y secretos externos con trazabilidad. Eso vive en los planes de pago, y aquí no es una comodidad: es un requisito. Negarte a pagar por principio, cuando el cumplimiento lo exige, es un error tan grande como pagar de más sin necesitarlo.

Eje 4 — Quién opera el sistema. ¿Quién va a promover workflows y gestionar entornos en el día a día? Si eres tú o alguien cómodo en la terminal, el flujo CLI+Git+Docker es natural y gratis. Si quien opera es una persona no técnica —un analista de negocio, un operador sin fondo de desarrollo—, un botón de push/pull en la interfaz puede ser la diferencia entre que use el sistema o que no lo toque por miedo. La feature nativa baja la barrera de operación.

Juntando los ejes, un resumen honesto:

Situación	Recomendación
Aprendes, o proyecto personal / sin ingresos	Self-hosted (esta guía). El costo del plan no se justifica.
Equipo chico (1–3), técnico, sin cumplimiento estricto	Self-hosted. El patrón te sobra y te ahorra el gasto.
Equipo que crece, varios promueven a prod, coordinación difícil	Evalúa pagar. La gobernanza de la interfaz empieza a pagar.
Operadores no técnicos en el día a día	Evalúa pagar. El botón baja la barrera.
Sector regulado / cumplimiento / auditoría exigida	Paga. No es comodidad, es requisito.
Necesitas SSO, RBAC, secretos externos con auditoría	Paga. Vienen en el paquete de pago.

La regla que resume la matriz: paga cuando el costo del plan es menor que el costo (en tiempo, riesgo o incumplimiento) de no pagarlo. Para muchos que empiezan, ese punto está lejos, y self-hosted es la respuesta correcta durante mucho tiempo. Para una empresa que escala, ese punto llega, y reconocerlo a tiempo también es ser buen dueño del sistema.

El costo escondido del "gratis": el tiempo y el bus factor

La matriz pesa el presupuesto, pero conviene ser honesto sobre un costo del patrón self-hosted que no aparece en ninguna factura: el tuyo. "Costo cero" se refiere a las licencias, no al esfuerzo. Montar y mantener tres entornos con Docker Compose, gestionar las claves, escribir los scripts de promoción, y arreglar tú mismo cuando algo se rompe, es trabajo real y recurrente. Para quien aprende, ese trabajo es el objetivo —aprendes haciéndolo—. Para una empresa, ese trabajo tiene un costo de oportunidad: son horas que esa persona no dedica a otra cosa.

Hay además un riesgo que los equipos chicos subestiman, y que tiene nombre: el bus factor —cuántas personas tendrían que "ser atropelladas por un autobús" para que el sistema quede sin quien lo entienda—. Si eres la única persona que sabe cómo están montados los entornos, dónde viven las claves y cómo se promueve un cambio, el bus factor de tu empresa es uno. El día que te vayas de vacaciones —o de la empresa— y algo se rompa, nadie sabe repararlo. La feature de pago, con su interfaz y su soporte, sube ese número: el conocimiento no vive solo en tu cabeza, sino en una herramienta documentada con alguien a quien llamar.

Esto no invierte la decisión —para un equipo chico y técnico, self-hosted sigue siendo correcto—, pero la matiza. Si eliges self-hosted en una empresa, la contrapartida es documentar bien (los Módulos 3 y 6 de esta guía son justo eso) para que el bus factor no sea uno. El patrón gratuito es correcto siempre que la disciplina de documentación lo acompañe; sin ella, el ahorro en licencias se paga en fragilidad. La feature de pago, en parte, es una forma de comprar esa documentación y ese respaldo ya hechos.

Ejemplo trabajado: tres escenarios, tres decisiones

Apliquemos la matriz a tres situaciones concretas, para ver cómo se razona.

Escenario A — Tú, aprendiendo y armando tu portafolio. Una persona, cero presupuesto para licencias, sin requisitos de cumplimiento, cómoda (o volviéndose cómoda) en la terminal. Decisión: self-hosted, sin dudar. No solo por el costo: montar los entornos tú mismo es precisamente lo que demuestra en una entrevista que entiendes el sistema por dentro. Pagar aquí sería gastar dinero para esconder justo lo que quieres mostrar. La matriz da self-hosted en los cuatro ejes.

Escenario B — Una agencia de tres personas con cinco clientes. Tres personas técnicas que se coordinan bien, sin cumplimiento regulado, presupuesto ajustado pero existente. Promueven workflows con cierta frecuencia. Decisión: self-hosted todavía, con un ojo en el futuro. El equipo es chico y técnico, así que el flujo CLI+Git+Docker les funciona. El punto de inflexión sería si crecen a diez personas o si un cliente empieza a exigir auditoría; ahí revalúan. Por ahora, el patrón de esta guía les da todo lo que necesitan sin gastar.

Escenario C — Una empresa de salud con quince personas en el equipo de datos. Sector regulado, requisitos de auditoría, gente no técnica que también opera workflows, presupuesto disponible. Decisión: paga. Aquí no es comodidad: el cumplimiento exige registros de auditoría y control de acceso que los planes de pago traen, la escala del equipo justifica la gobernanza de la interfaz, y los operadores no técnicos necesitan los botones. Insistir en self-hosted por ahorrar sería poner en riesgo el cumplimiento para ahorrar lo que, a esa escala, es poco dinero. La matriz da "paga" en tres de los cuatro ejes, y el de cumplimiento pesa doble.

Qué esperar de este razonamiento: fíjate que en los tres casos la decisión no salió de un gusto ni de una ideología ("lo gratis siempre es mejor" / "lo de pago siempre es mejor"), sino de pesar los cuatro ejes contra la situación real. Ese es el método. La respuesta cambia con el contexto, y saber por qué cambia es lo que te hace capaz de defenderla ante un jefe o un cliente.

Las señales concretas de que llegó el momento de pagar

La matriz te da los ejes, pero en la práctica la decisión no llega como "hoy analizo los cuatro ejes". Llega como una señal: un síntoma cotidiano que te dice que el patrón self-hosted empezó a costarte más de lo que te ahorra. Vale la pena tener esas señales nombradas, para reconocerlas cuando aparezcan en vez de aguantarlas por inercia.

Estas son las más claras:

• Alguien promovió a producción algo que no debía, y no hubo forma de saber quién ni cuándo. Cuando el equipo crece, la promoción manual sin registro se vuelve un riesgo. Si te encontraste preguntando "¿quién subió esto a prod?" sin poder responder, la auditoría de la feature de pago dejó de ser un lujo.

• Una persona no técnica del equipo necesita promover, y el flujo de terminal la bloquea. Si tu operador de negocio no toca los workflows porque "eso de la terminal me da miedo", el sistema no se está usando a su potencial. El botón de push/pull podría desbloquear a esa persona.

• Un cliente o auditor te pidió por escrito registros de acceso, control de roles o SSO. Esto no se negocia con criterio técnico: es un requisito externo. Cuando aparece, el paquete de pago que lo trae deja de ser opcional.

• Pasas más tiempo manteniendo la infraestructura de entornos que construyendo automatizaciones. Si el andamiaje —Docker, claves, scripts— se comió el tiempo que deberías dedicar al trabajo que genera valor, estás pagando en horas lo que podrías pagar en licencia.

• El bus factor es uno y el equipo lo notó. Cuando alguien dice "solo Fulano sabe cómo levantar prod", ya tienes un riesgo operativo reconocido. La herramienta documentada con soporte lo mitiga.

Ninguna de estas señales, sola, obliga a pagar. Pero cuando empiezas a ver dos o tres a la vez, la balanza se inclinó, y seguir en self-hosted "por principio" pasó de ser prudencia a ser terquedad. La marca de un buen dueño del sistema no es elegir gratis para siempre ni pagar por reflejo; es reconocer el momento en que la decisión correcta cambió y actuar en consecuencia, con argumentos, no con orgullo. Guarda estas señales: son tu alarma, y hasta que suenen, el patrón de esta guía es tu respuesta.

Cómo sería la migración self-hosted → Cloud

Una pregunta natural: "si empiezo self-hosted y algún día mi equipo crece, ¿tiro todo y empiezo de nuevo?". La respuesta tranquilizadora es no, y la razón es todo el trabajo que hiciste en esta guía.

Porque ya versionas tus workflows con Git (Módulos 2 y 3), la migración a la feature nativa —que también se apoya en Git— es en gran parte llevar lo que ya tienes a donde n8n lo espera. Tus workflows ya están exportados, normalizados y en un repositorio; la feature nativa lee de un repositorio. Tu disciplina de credenciales fuera del repo, .env por entorno y nombres consistentes se traslada casi tal cual. Lo que cambia es dónde vive el botón de promover: de tu terminal, a la interfaz de n8n.

En grandes trazos, una migración se vería así (los detalles dependen de la versión y conviene seguir la guía oficial del momento):

1. Contratas el plan que incluye entornos y source control, y creas las instancias de Cloud (o conectas las self-hosted a la feature).
2. Conectas cada instancia a su rama del repositorio que ya tienes. Tu cumbre-automations —o su equivalente— pasa a ser el repositorio que la feature nativa usa.
3. Importas tus workflows y recreas las credenciales en cada instancia, con la misma disciplina de nombres y valores por entorno que aprendiste en la lección 5. Esto no cambia: las credenciales se siguen recreando por entorno.
4. Cambias tu flujo de promoción del push manual con Git y la CLI, al push/pull desde la interfaz.

También existe un punto intermedio que muchos equipos adoptan y conviene conocer: el enfoque híbrido. No tienes que elegir "todo self-hosted" o "todo de pago" de golpe. Un equipo puede mantener dev y staging self-hosted a costo cero —donde experimenta, donde no hay datos reales, donde el ahorro es puro beneficio— y pagar solo por el entorno o las features que de verdad lo justifican en prod —donde vive lo real, donde el cumplimiento y el soporte importan—. La decisión de plan no es una sola para todo el sistema; puedes aplicarla entorno por entorno. Esto suaviza mucho la transición: creces pagando por lo que empieza a dolerte, no por todo a la vez. Y como la disciplina que aprendiste es la misma en los dos lados, mezclarlos no crea fricción conceptual, solo dos formas de operar el mismo patrón.

Lo importante: la disciplina no se tira, se traslada. Todo lo que este módulo te enseñó —entornos aislados, una clave por entorno, credenciales de prueba vs. reales, secretos fuera del workflow— sigue siendo verdad en Cloud; la feature de pago solo cambia la ergonomía de operarlo. Quien aprendió a hacerlo a mano entiende qué hace la feature cuando aprieta el botón, y por eso migra con confianza en vez de con fe ciega. Empezar self-hosted no es un callejón sin salida: es la mejor preparación posible para, si llega el día, usar bien la versión de pago.

Errores comunes

Pagar demasiado pronto, por comodidad que no necesitas (de criterio). Qué pasa: alguien que aprende, o un equipo de una persona, contrata un plan de pago "para hacerlo bien", y gasta presupuesto en gobernanza y soporte que a esa escala no aportan. Por qué pasa: se confunde "de pago" con "profesional", como si lo gratis fuera de aficionado. Cómo detectarlo: si pagas por push/pull con roles pero eres la única persona que toca el sistema, pagas por gobernar a un equipo de uno. Cómo corregirlo: usa la matriz. Para un equipo chico y técnico sin cumplimiento, self-hosted no es la opción "barata", es la opción correcta: te da lo mismo y te obliga a entender el sistema.

Negarte a pagar cuando el cumplimiento lo exige (de criterio, y arriesgado). Qué pasa: alguien lleva la bandera del "todo gratis" hasta una empresa regulada, y arma un montaje self-hosted sin auditoría ni control de acceso donde el sector exige ambos. El día de una revisión, no hay registros que mostrar. Por qué pasa: el orgullo de hacerlo gratis nubla el requisito real. Cómo detectarlo: si tu empresa tiene requisitos de cumplimiento y tu sistema no tiene auditoría ni RBAC, el ahorro es una deuda que va a vencer. Cómo corregirlo: cuando el cumplimiento entra en juego, pagar por las features que lo satisfacen no es un lujo, es parte del trabajo. Reconocerlo a tiempo es tan de dueño del sistema como saber montar Docker Compose.

Creer que la feature de pago aísla "de verdad" y la gratuita no (conceptual). Qué pasa: alguien supone que sin pagar sus entornos no están "realmente" separados, y desconfía de su propio montaje self-hosted. Por qué pasa: es fácil asumir que lo que cuesta dinero es más sólido. Cómo detectarlo: si crees que tu dev self-hosted podría "contaminar" tu prod self-hosted pese a tener volúmenes, claves y puertos separados, tienes esta duda infundada. Cómo corregirlo: el aislamiento lo da la infraestructura, no el plan. Tu patrón self-hosted aísla igual de real que la feature nativa; lo que la feature agrega es comodidad y servicios, no aislamiento superior. Confía en lo que construiste y verificaste.

Temer que empezar gratis te encierre (de criterio). Qué pasa: alguien no monta el patrón self-hosted por miedo a "tener que rehacer todo" si algún día paga. Por parálisis, se queda con una sola instancia y sin entornos. Por qué pasa: se sobreestima el costo de migrar. Cómo detectarlo: si pospones montar entornos "hasta decidir si vale la pena pagar", el miedo a migrar te está costando el aislamiento hoy. Cómo corregirlo: empezar self-hosted no encierra; prepara. Como ya versionas con Git, la migración a la feature nativa es trasladar, no rehacer. Monta el patrón gratis ahora; si algún día pagas, lo que aprendiste te hace usar la versión de pago con criterio.

Ejercicios

Ejercicio 1 — Aplica la matriz. Para cada situación, di si recomendarías self-hosted o evaluar/pagar, nombrando el eje o los ejes que más pesan: (a) un freelancer que automatiza para tres clientes chicos, cómodo en la terminal; (b) un banco con un equipo de veinte personas y auditorías trimestrales; (c) una startup de cinco personas técnicas, sin cumplimiento, con inversión pero cuidando el gasto; (d) una ONG donde quien opera los workflows es una coordinadora sin fondo técnico.

Ver solución

(a) Self-hosted. Ejes de tamaño (equipo de uno), presupuesto (freelance) y operador (técnico) apuntan todos a self-hosted. Sin cumplimiento en juego, no hay razón para pagar.

(b) Paga. El eje de cumplimiento (auditorías trimestrales, sector regulado) decide casi solo, y el tamaño del equipo (veinte) refuerza la necesidad de gobernanza. Aquí pagar es requisito, no lujo.

(c) Self-hosted todavía, revaluando al crecer. Equipo chico y técnico, sin cumplimiento: el patrón les funciona y cuidar el gasto es sensato. El punto de inflexión sería crecer mucho o que aparezca un requisito de auditoría.

(d) Evalúa pagar, por el eje del operador: una persona no técnica opera el día a día, y el botón de push/pull baja la barrera frente al flujo CLI+Git+Docker. Aunque el equipo sea chico, quién opera pesa aquí.

Por qué funciona: si nombraste el eje dominante en cada caso, dominas el método —la decisión no es "gratis vs. pago" en abstracto, es qué eje pesa más en esta situación—. Fíjate que (a) y (b) son claros, y (c) y (d) muestran que el mismo tamaño de equipo puede dar respuestas distintas según el operador o el cumplimiento.

Ejercicio 2 — Qué compras y qué ya tienes. De esta lista, separa lo que la feature de pago te da de nuevo de lo que ya tienes gratis con el patrón self-hosted: (a) el aislamiento entre dev y prod; (b) promover un workflow con un botón en vez de comandos; (c) versionar los workflows con Git; (d) registros de auditoría de quién promovió qué; (e) que un cambio en dev no toque prod; (f) SSO y control de acceso por roles.

Ver solución

Ya lo tienes gratis: (a) el aislamiento entre entornos —lo da Docker Compose—; (c) versionar con Git —lo hiciste en los Módulos 2 y 3—; (e) que un cambio en dev no toque prod —es la consecuencia del aislamiento, ya la tienes—.

Te da de nuevo la feature de pago: (b) el botón de promover en la interfaz —comodidad sobre el flujo CLI—; (d) los registros de auditoría —trazabilidad que el patrón self-hosted no trae de fábrica—; (f) SSO y RBAC —features de empresa del paquete de pago—.

Por qué funciona: la separación deja claro que lo esencial (aislamiento, versionado) es gratis, y lo que se paga es comodidad (b) y servicios de empresa (d, f). Saber qué de lo que "vende" un plan ya lo tienes te protege de pagar por lo que ya posees, y de despreciar lo que de verdad agrega valor a escala.

Ejercicio 3 — El argumento ante tu jefe. Tu jefe, en una empresa chica y técnica sin requisitos de cumplimiento, leyó que n8n tiene "environments" de pago y quiere contratarlo "para ser profesionales". Escribe en cuatro o cinco frases cómo le explicarías, sin sonar a que solo quieres ahorrar, por qué el patrón self-hosted es la opción correcta ahora y en qué condición concreta recomendarías reconsiderar.

Ver solución

No hay una única respuesta; un buen argumento diría algo como: "Los entornos separados que buscamos —dev, staging y prod aislados, versionados y seguros— ya los tenemos montados con Docker Compose y Git, a costo cero, y funcionan de verdad: un cambio en dev no toca prod, cada entorno tiene su propia clave y sus credenciales. La feature de pago no nos daría más aislamiento; nos daría comodidad en la interfaz y servicios de empresa —auditoría, SSO— que a nuestro tamaño y sin requisitos de cumplimiento todavía no necesitamos. Mientras seamos un equipo chico y técnico, pagar sería gastar en comodidad que no nos falta. Yo reconsideraría en el momento en que crezcamos a un equipo grande donde varias personas promuevan a producción y necesitemos gobernar quién puede qué, o si un cliente nos empieza a exigir auditoría; ahí la feature empieza a pagar su precio."

Por qué funciona: el argumento no dice "ahorremos"; dice "ya tenemos lo esencial, y esto es lo que la feature agrega, y esta es la condición concreta para reconsiderar". Esa forma —reconocer el valor real de la opción de pago y nombrar el disparador de la decisión— es la que convence a un jefe, porque demuestra criterio, no tacañería. Es, otra vez, hablar como dueño del sistema.

Resumen y siguiente paso

En esta lección tomaste la decisión de plan con criterio. Con la imagen de comprar la casa amueblada o amueblarla tú entendiste que la feature nativa de entornos (de pago) y el patrón self-hosted de esta guía llegan al mismo resultado —entornos aislados, versionados, seguros— y que lo que cambia es cuánto pagas en dinero y cuánto en trabajo. Viste qué ofrece la feature nativa exactamente: entornos conectados por ramas de Git con push/pull desde la interfaz, control de versiones integrado y gobernanza de roles, disponible en los planes de pago (Business/Enterprise, verifícalo en precios). Distinguiste lo que compras —comodidad, menos montaje, soporte, features de empresa— de lo que ya tienes gratis —el aislamiento y la capacidad de versionar—. Aplicaste la matriz de decisión sobre cuatro ejes (tamaño de equipo, presupuesto, cumplimiento, quién opera) a tres escenarios, y viste que empezar self-hosted no te encierra: como ya versionas con Git, la migración a Cloud es trasladar la disciplina, no rehacerla.

Antes de avanzar deberías poder: describir qué ofrece la feature nativa de entornos; nombrar los cuatro ejes de la matriz de decisión; explicar qué te da la opción de pago y qué ya tienes gratis; y decir por qué empezar self-hosted facilita una migración futura en vez de complicarla.

La lección 8 cierra el módulo con las manos en la masa: el proyecto. Vas a levantar los tres entornos —dev, staging y prod— corriendo a la vez en tu máquina, cada uno con su clave de cifrado, sus credenciales de prueba o reales y su webhook propio, y vas a demostrar el aislamiento: que un cambio en dev no toca prod, y que los secretos de un entorno no se descifran en otro. El entregable —los compose files, el .env.example y una prueba de aislamiento documentada— es la evidencia de que sabes construir el patrón que esta lección te enseñó a decidir cuándo usar.

Recursos

• Source control and environments — n8n Docs — la descripción oficial de la feature nativa: entornos por ramas de Git y push/pull desde la interfaz.
• Environments in n8n — n8n Docs — cómo n8n modela development/staging/production conectados por Git.
• Compare editions / pricing — n8n Docs — qué features viven en qué plan; confírmalo aquí y en la página de precios, porque los planes cambian.
• Tutorial: Create environments with source control — n8n Docs — cómo se ve, paso a paso, montar entornos con la feature nativa; útil para dimensionar qué automatiza frente al patrón self-hosted.