Qué significa RBAC en n8n: cuándo lo necesita un equipo pequeño

Por Roman Rodomansky·Publicado el 24 sept 2026

Una explicación clara del significado de RBAC en n8n: roles de instancia y proyecto, requisitos de plan y cuándo un equipo pequeño lo necesita.

• Guía
• n8n
• Control de acceso
• Preparación para producción

Comprobado con las fuentes citadas el 24 sept 2026.

Qué es el control de acceso RBAC, en términos generales

Si estás tratando de precisar el significado de RBAC antes de implementarlo en un equipo, el concepto no nace con n8n. El control de acceso basado en roles asigna a cada usuario uno o más roles, y cada rol conlleva un conjunto definido de privilegios, según el Computer Security Resource Center del NIST. En lugar de conceder acceso persona por persona, se asignan roles, y son los roles los que llevan los permisos.

El objetivo del RBAC, en general, es gestionar la seguridad a un nivel que refleje cómo está estructurada realmente la organización, en lugar de mantener una lista de acceso independiente para cada persona y recurso. Esta descripción procede de una página general del NIST, no específica de n8n, que la propia fuente señala como archivada y ya no actualizada, pero la lógica subyacente es exactamente la que sigue el propio sistema de permisos de n8n.

Sources: Role Based Access Control | CSRC

Cómo implementa n8n el RBAC: roles de instancia frente a roles de proyecto

n8n aplica el RBAC en dos niveles distintos. Los roles de instancia determinan lo que un usuario puede hacer en toda la instancia de n8n, cosas como invitar personas o gestionar la configuración global. Los roles de proyecto determinan lo que esa misma persona puede hacer dentro de un proyecto concreto, que es donde realmente ocurre la construcción diaria de flujos de trabajo.

De forma predeterminada, los roles de instancia de n8n son Owner (propietario), Admin y Member. Los roles de instancia y de proyecto totalmente personalizados, en los que se definen permisos más allá de esos valores predeterminados, son una función exclusiva de Enterprise tanto en n8n Cloud como en n8n autoalojado; los roles integrados son con los que trabaja el resto.

Sources: Set permissions and roles (RBAC) | Administer | n8n Docs

Roles de proyecto en la práctica: Admin, Editor y Viewer

Dentro de un proyecto, n8n ofrece tres roles: Admin, Editor y Viewer. Estos determinan quién puede editar, ejecutar o simplemente ver los flujos de trabajo de ese proyecto.

El rol Viewer es más estricto de lo que podría parecer: quienes lo tienen pueden abrir y leer los flujos de trabajo de un proyecto, pero no pueden ejecutar manualmente ni siquiera aquellos que tienen permiso para ver.

Sources: See available roles | Administer | n8n Docs

Qué plan o edición requiere cada nivel de rol

Nada de esto está disponible en todas partes de forma predeterminada. La edición Community autoalojada y gratuita no tiene ningún sistema de proyectos ni de compartición: solo el propietario de la instancia y quien haya creado un flujo de trabajo o credencial concretos puede acceder a ellos, por lo que ni siquiera existe un rol que asignar.

Los proyectos y la compartición —el mecanismo del que depende el RBAC— se desbloquean en los planes autoalojados Business y Enterprise, y en n8n Cloud, según su propia tabla de funciones. La página de precios de n8n presenta esto como un control de acceso basado en roles que garantiza «el nivel adecuado de permisos» para cada miembro del equipo. Incluso el plan de nivel inicial Cloud Starter incluye un proyecto compartido, y Cloud Pro añade un tercer proyecto compartido junto con una función denominada roles de Admin.

El rol Editor en concreto —que permite a alguien editar y ejecutar flujos de trabajo sin gestionar el proyecto— solo está disponible en n8n Cloud Pro o en la edición Enterprise autoalojada. Ten en cuenta que la página de precios de n8n no lleva ninguna fecha de publicación explícita en lo documentado aquí, así que considera los nombres de los planes y sus inclusiones como exactos solo a fecha de esta consulta, y confírmalos en la página de precios en vivo antes de comprometer presupuesto.

Sources: See available roles | Administer | n8n Docs, Compare editions | Deploy | n8n Docs, n8n Plans and Pricing - n8n.io

Qué no cubre el RBAC en n8n

Los roles no llegan a todos los rincones de una instancia de n8n. Las variables y las etiquetas no están delimitadas por el RBAC en absoluto: permanecen globales y visibles en toda la instancia sin importar qué roles de proyecto hayas asignado. Mantén convenciones de nomenclatura y disciplina de revisión para ellas por separado, en lugar de suponer que los roles también las restringen.

Sources: See available roles | Administer | n8n Docs

Escenario: un flujo de trabajo compartido, distintos derechos según el rol

Imagina un flujo de trabajo de producción que tres personas tocan de forma distinta: se trata de un escenario propuesto para razonar sobre el tema, no de un caso documentado de n8n. Un responsable de ingeniería necesita ver que se mantuvo en verde durante la noche, un desarrollador necesita arreglar un nodo roto, y una parte interesada solo quiere confirmar que se ejecutó.

Un flujo de trabajo compartido, tres conjuntos de derechos

1. Admin: Gestiona quién tiene acceso al proyecto y puede editar o ejecutar el flujo de trabajo a voluntad.
2. Editor: Abre el flujo de trabajo, arregla el nodo roto y lo vuelve a ejecutar, sin tocar la membresía del proyecto.
3. Viewer: Comprueba el historial de ejecuciones para confirmar que la ejecución fue correcta, pero no puede activarla manualmente.

Sources: See available roles | Administer | n8n Docs

Cuándo un equipo pequeño realmente necesita RBAC

Entonces, ¿cuándo se traduce realmente el significado de RBAC en una decisión de compra? Ninguna fuente oficial de n8n indica un umbral específico de tamaño de equipo: lo que sigue es un juicio editorial basado en la disponibilidad documentada de funciones, no una recomendación del proveedor.

• Si tu equipo tiene aproximadamente entre 1 y 3 personas que comparten el inicio de sesión del propietario de la instancia, o si cada persona solo toca siempre sus propios flujos de trabajo, el acceso predeterminado de la edición Community (propietario más creador) puede ser ya suficiente.
• Si más de una persona necesita derechos distintos sobre el mismo flujo de trabajo compartido —una edita y despliega, otra solo activa ejecuciones, una tercera solo necesita visibilidad—, esa es la señal práctica para pasar a los roles de proyecto.
• Haz coincidir cada rol con el trabajo real: Viewer para quienes solo necesitan el estado, Editor para quienes construyen y mantienen flujos de trabajo, y Admin con moderación para quien tenga la decisión sobre el acceso y la estructura.
• Recuerda que el rol Editor ya requiere n8n Cloud Pro o Enterprise autoalojado, así que presupuesta el plan junto con la decisión sobre el número de personas.

Sources: See available roles | Administer | n8n Docs, Compare editions | Deploy | n8n Docs

Próximos pasos prácticos para estandarizar los permisos en un equipo en crecimiento

Antes de implementar roles en un equipo en crecimiento, plasma en papel el mapa de quién necesita qué. Eso es lo que convierte el significado de RBAC comentado anteriormente en una configuración real en lugar de una conjetura.

• Enumera todos los flujos de trabajo de producción compartidos y quién los toca actualmente.
• Marca a cada persona según si necesita editar, solo ejecutar o solo ver ese flujo de trabajo.
• Comprueba cuáles de los planes o ediciones de tu equipo ya admiten proyectos y compartición.
• Confirma si el acceso de nivel Editor requiere una actualización antes de prometérselo a nadie.
• Revisa por separado quién puede ver las variables y etiquetas compartidas, ya que los roles no las restringen.

Sources: See available roles | Administer | n8n Docs