Control de versiones en n8n: Git vs JSON exportado vs copias manuales
Control de versiones en n8n comparado: Git nativo, archivos JSON exportados y copias manuales, según historial, revisión, restauración y requisitos de edición.
Comprobado con las fuentes citadas el .
Tres enfoques para el control de versiones en n8n
Los equipos que necesitan control de versiones en n8n suelen elegir entre el control de código fuente nativo con Git, los archivos JSON exportados y las copias de seguridad manuales. Esta comparación juzga cada uno con cuatro criterios: historial, revisión, restauración y requisitos de edición.
La evidencia procede de la documentación y del blog de n8n, así que los flujos de control de versiones en n8n que aquí se describen reflejan lo que n8n documenta, y señalamos las lagunas por el camino.
Sources: Use source control and environments | Administer | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Git source control: el control de versiones nativo de n8n
Según la documentación de n8n, el control de código fuente nativo con Git solo está disponible en los planes Business y Enterprise. Los propietarios o administradores de la instancia lo habilitan y configuran, y los administradores de proyecto pueden hacer push pero no pull.
El historial se crea al hacer push, y en n8n el commit y el push se realizan juntos. La documentación también indica que la integración no es un control de versiones completo y no ofrece revisión al estilo de pull requests, por lo que la revisión se hace en tu proveedor de Git. Un push envía la versión guardada de un workflow, no la publicada, además de etiquetas y marcadores de credenciales con ID, nombre y tipo, de modo que los secretos no se suben al repositorio. Los datos de las filas de las data tables no se envían. El propio blog de n8n, que es una guía del proveedor, describe diffs que muestran nodos añadidos, modificados y eliminados antes de un push o un pull, y afirma que las instancias protegidas impiden las ediciones directas de recursos bajo control de código fuente.
Restaurar significa hacer pull de un estado anterior del repositorio, y un pull sobrescribe los cambios locales sin enviar. La documentación de n8n añade que no puede detectar conflictos entre workflows, que el repositorio es la fuente de verdad y que el push sobrescribe Git, por lo que se aconseja un flujo unidireccional. Un pull puede despublicar y volver a publicar brevemente un workflow publicado. Creemos que conviene adoptar el flujo unidireccional como regla estricta, porque la herramienta no te avisará cuando dos personas diverjan.
Sources: Use source control and environments | Administer | n8n Docs, Use Git in n8n | Administer | n8n Docs, Push and pull changes | Administer | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Control de versiones en n8n con JSON exportado y copias manuales
La documentación de n8n dice que el JSON de un workflow se puede exportar o importar mediante el menú del editor, copiar y pegar, la CLI o la API. La Server CLI de las instalaciones autoalojadas puede exportar un archivo por workflow, algo descrito como útil para el control de versiones, y puede exportar una versión histórica concreta. La documentación también recomienda la n8n CLI frente a la Server CLI para trabajos nuevos y prevé dejar obsoletas la exportación y la importación de la Server CLI, sin fecha fijada.
La documentación plantea varias precauciones al exportar y restaurar. La lista siguiente es nuestro resumen.
La API pública está disponible en Cloud Starter, Pro y Enterprise y en todas las ediciones autoalojadas, pero no en la prueba gratuita, de modo que la exportación de JSON por script mediante la API es posible sin un plan Business, aunque esa documentación no describe cómo diseñar un workflow de copia de seguridad. Para Community Edition, el propio blog del proveedor, en su entrada de agosto de 2026, sugiere un workflow programado que guarde el JSON modificado en un repositorio Git privado. Lo presenta como un proceso de copia de seguridad, no como sustituto de los entornos nativos, y recomienda probar las restauraciones. Creemos que es el término medio sensato para equipos con Community Edition, siempre que nadie lo confunda con entornos.
Las copias manuales consisten en descargar a mano un workflow como JSON desde el menú del editor y guardar el archivo donde tú elijas.
Sources: Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs, n8n API | Connect | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Historial de workflows integrado y versiones con nombre
El historial de workflows integrado guarda las versiones en la base de datos de la instancia de n8n, no en Git. La documentación describe el historial completo en Enterprise, en Cloud o autoalojado, mientras que todos los usuarios tienen las versiones de las últimas 24 horas y Cloud Pro, cinco días. Puedes restaurar una versión, clonarla en un workflow nuevo o descargarla como JSON.
Las versiones con nombre, que n8n nunca elimina automáticamente, están disponibles en Cloud Pro y Enterprise y en las ediciones autoalojadas Business y Enterprise.
Sources: View change history | Build | n8n Docs
Comparación de historial, revisión, restauración y edición
La tabla aplica los mismos cuatro criterios a los tres enfoques, dividiendo el JSON exportado en su forma programada hacia Git y en exportaciones manuales, y añadiendo el historial de workflows integrado para que esté completa. Úsala para elegir entre los flujos de control de versiones en n8n según tu edición.
| Enfoque | Historial | Revisión | Restauración | Edición |
|---|---|---|---|---|
| Control de código fuente nativo con Git | Se crea en cada push | En el proveedor de Git, no en n8n | Pull de un estado anterior del repositorio; sobrescribe los cambios sin enviar | Business, Enterprise |
| Exportación JSON programada a Git | Historial de Git de los archivos modificados, según la sugerencia del blog de n8n | Desconocido | Reimportar; los ID coincidentes pueden sobrescribirse al importar con la Server CLI | API pública en Cloud Starter, Pro, Enterprise y todas las autoalojadas; CLI más allá del autoalojamiento: desconocido |
| Exportaciones manuales | Solo lo que conservas y nombras tú mismo | Desconocido | Reimportar a mano; comportamiento de sobrescritura de la importación del editor: desconocido | Desconocido |
| Historial de workflows integrado | Versiones en la base de datos de la instancia | Desconocido | Restaurar, clonar o descargar como JSON | Completo en Enterprise; 24 horas para todos los usuarios; cinco días en Cloud Pro |
Las celdas marcadas como Desconocido son puntos que la documentación de n8n no indica, no una prueba de que la capacidad no exista.
Sources: Use source control and environments | Administer | n8n Docs, Use Git in n8n | Administer | n8n Docs, View change history | Build | n8n Docs, Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs, n8n API | Connect | n8n Docs, Workflow Versioning for Reliable Automation and Maintenance – n8n Blog
Lo que sigue sin saberse
Varios puntos siguen sin confirmarse en el material que revisamos. No está claro si Community Edition conserva el historial de workflows más de 24 horas, ni tampoco los pasos exactos para hacer pull de un commit de Git anterior concreto.
La fuente de la Server CLI de la que disponíamos estaba truncada, y la documentación de n8n etiqueta sus paquetes como Preview. Las copias manuales se basan en una inferencia a partir de la documentación de exportación. Por último, nada de esto procede de pruebas de primera mano.
Sources: Use Git in n8n | Administer | n8n Docs, View change history | Build | n8n Docs, Use the command line | Deploy | n8n Docs, Export and import | Build | n8n Docs
Recomendaciones editoriales
Son sugerencias nuestras, no resultados validados, y se derivan de la comparación anterior.
- En Business o Enterprise, usa Git nativo con un flujo unidireccional de desarrollo, staging y producción, y revisión en tu proveedor de Git.
- En Community Edition, programa exportaciones JSON de un archivo por workflow a un repositorio Git privado y trátalas como copia de seguridad con historial.
- Reserva las exportaciones manuales para instantáneas puntuales: ponles nombre, guárdalas en privado y no dependas de ellas como historial del equipo.
- Prueba una restauración en una instancia que no sea de producción y comprueba el comportamiento de sobrescritura de ID al importar.
Nuestra apuesta es que una prueba de restauración importa más que el enfoque que elijas, porque una copia de seguridad que nadie ha restaurado es solo una esperanza.
