n8n Community RBAC: una checklist manual de control de acceso
Checklist para las lagunas de n8n community rbac: qué falta en Community y qué forzar a mano, sin roles de pago ni SSO en Community.
Comprobado con las fuentes citadas el .
Confirma qué incluye y qué excluye realmente la edición Community
Si estás buscando en Google n8n community rbac porque no estás seguro de qué protege realmente tu instancia de n8n gratuita y autoalojada, la respuesta breve es: poco más que el inicio de sesión. La propia documentación de n8n establece que, en la edición Community autoalojada, no se incluye el compartir workflows ni credenciales, de modo que solo el propietario de la instancia y quien haya creado un workflow o una credencial pueden abrirlo, según la documentación de n8n. Todos los demás que trabajen en esa instancia o bien comparten un inicio de sesión, o trabajan a ciegas respecto a lo que han construido sus compañeros.
Esa única frase no cuenta toda la historia que n8n cuenta de sí misma. Una página distinta de n8n sobre organizar el trabajo en proyectos establece que el RBAC mediante proyectos está disponible en la edición Community registrada autoalojada, así como en Business, Enterprise y todos los planes de n8n Cloud. Las dos páginas no coinciden, y ninguna fuente de n8n aquí resuelve la contradicción, así que trata ambas como documentación vigente y verifica en la página de precios de n8n antes de construir un plan basándote en una u otra lectura.
Lo que sí es constante en la documentación de n8n es que los roles personalizados, tanto a nivel de instancia como de proyecto, quedan detrás del plan Enterprise en n8n Cloud o autoalojado, y la comparativa de precios de n8n lista los roles de administrador como una incorporación del nivel Pro por encima de Starter. Si también te preguntas por el SSO de n8n en la edición Community, esa función queda fuera de lo que documentan aquí estas páginas de proyectos y RBAC, así que consulta directamente la página de precios actual de n8n en lugar de asumir una cosa u otra.
| Función | Community (autoalojada) | Business / Pro | Enterprise |
|---|---|---|---|
| Acceso a workflows y credenciales | Solo el propietario de la instancia y el creador, según la documentación de n8n | Compartir disponible | Compartir disponible |
| Proyectos / RBAC | La documentación de n8n no coincide: una página lo excluye, otra incluye Community registrada | Disponible | Disponible |
| Roles personalizados (instancia o proyecto) | No disponible | No disponible | Disponible |
| Roles de administrador | No listado para Community | Introducido en el nivel Pro | Disponible |
| Almacenes de secretos externos | No disponible | No disponible | Disponible |
Sources: Compare editions | Deploy | n8n Docs, Organize work in projects | Administer | n8n Docs, Set permissions and roles (RBAC) | Administer | n8n Docs, Share with others | Build | n8n Docs, Use external secret stores | Administer | n8n Docs, n8n Plans and Pricing - n8n.io
Compensa el modelo de un único propietario y un único administrador
Dado que la edición Community no tiene roles de RBAC más allá de su división básica entre propietario y miembro, la cuenta que inicia sesión como propietaria es, en la práctica, la única cuenta con alcance total. Las propias recomendaciones de buenas prácticas de n8n sugieren que el propietario de la instancia cree una cuenta aparte de nivel miembro para sí mismo, porque no hay forma de ver quién creó un workflow concreto si el propietario lo construye directamente, según la documentación de n8n.
Los informes de la comunidad respaldan esto desde fuera. En un hilo del foro comunitario de septiembre de 2025, un usuario autoalojado informa de que solo el único Owner puede realizar ciertas acciones de administrador en la edición Community, lo que empuja a algunos equipos a compartir el inicio de sesión del Owner o a levantar instancias adicionales como solución temporal. Un hilo de junio de 2026 de un usuario de una agencia describe la misma forma: sin RBAC ni proyectos compartidos, solo el administrador ve todos los workflows, mientras que el resto solo ve los suyos.
Nosotros trataríamos ese inicio de sesión de propietario como tratarías la contraseña root de un servidor, no como un marcador de equipo compartido: cuantas menos personas lo introduzcan, menos formas hay de que un único error alcance todas las credenciales de la instancia.
Este patrón no es exclusivo de los despliegues autoalojados. La propia entrada de blog de Linx Security, que describe una prueba en n8n Cloud, afirma que un administrador de instancia pudo ejecutar un workflow usando la credencial guardada de otro usuario sin la participación de ese usuario.
Sources: Follow best practices | Administer | n8n Docs, Allow multiple Admins on self-hosted (Community) - Feature Requests - n8n Community, Scaling n8n as an agency: collaboration & access-control options? - General - n8n Community, n8n Credential Sharing | Linx Security
Separa las credenciales sin reparto integrado ni bóveda de secretos
Las credenciales son donde el modelo de propietario único pasa de ser un riesgo abstracto a una incomodidad diaria. La documentación de n8n establece que compartir una credencial con otro usuario o proyecto está disponible en n8n Cloud y en Business y Enterprise autoalojados, lo que significa que la edición Community no tiene una forma integrada de que dos personas usen un mismo inicio de sesión para un CRM o una cuenta de correo compartidos. Esta es la mitad referida al reparto de credenciales de la misma laguna de n8n community rbac tratada arriba, y el reparto de workflows sigue el patrón idéntico.
La integración con almacenes de secretos externos, conectando n8n a herramientas como 1Password, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault o Infisical, también es una función exclusiva de Enterprise en n8n Cloud o autoalojado, según la documentación de n8n. Un mecanismo que la documentación de n8n enumera sin indicar una restricción de edición son las sobrescrituras de credenciales (credential overwrites), que fijan datos de credenciales de forma global en una instancia autoalojada; la documentación no confirma explícitamente que esto funcione en la edición Community no registrada, así que verifícalo en tu propia versión de instancia antes de depender de ello.
- Escribe una convención de nomenclatura de credenciales antes de que se incorpore un segundo creador, por ejemplo CLIENTE | SERVICIO | PROPÓSITO; se considera lista cuando cada credencial activa sigue ese patrón
- Da a cada credencial un propietario visible en ese nombre, ya que n8n no impondrá la propiedad por ti
- Mantén las credenciales personales y las de servicio compartido en patrones de nombre claramente distintos
- Vuelve a probar las sobrescrituras de credenciales en tu propia versión de instancia antes de confiar en ellas para algo global
Sources: Share credentials securely | Administer | n8n Docs, Share with others | Build | n8n Docs, Use external secret stores | Administer | n8n Docs, Manage credentials | Administer | n8n Docs
Impón a mano las convenciones de propiedad y traspaso de workflows
Cuando más de una persona construye en la misma instancia de edición Community, la propiedad se vuelve confusa rápidamente. El hábito de la cuenta de propietario separada descrito arriba es también la primera línea de defensa que recomienda la propia n8n aquí, así que trátalo como higiene de instancia y no como un paso de configuración puntual.
Una hoja de cálculo o un campo de ticket que registre quién es propietario de cada workflow suena casi demasiado simple, pero creemos que es la cantidad justa de proceso para un equipo pequeño: no cuesta nada empezarlo, y es más fácil mantenerlo honesto que una revisión formal que nadie tiene tiempo de ejecutar.
Un detalle relacionado merece conocerse aunque no sea en sí mismo una función de control de acceso: la documentación de n8n establece que las rutas de webhook deben ser únicas en toda una instancia, para todos los workflows y todos los usuarios, de modo que si los workflows de dos personas comparten una ruta, solo el primero que se ejecutó o se publicó sigue funcionando y el otro da error. En una instancia de edición Community compartida sin proyectos que separen las cosas, esa colisión es fácil de provocar por accidente.
Sources: Follow best practices | Administer | n8n Docs
Sustituye el control de versiones y el registro de auditoría ausentes
Las limitaciones de la edición Community no se detienen en quién puede abrir un workflow; también afectan a cómo podrías reconstruir qué cambió y cuándo, ya que las funciones ya tratadas aquí son las que normalmente llevarían esa información. Como consejo editorial y no como una función documentada de n8n, sugeriríamos exportar los workflows como JSON a un repositorio git privado con una cadencia regular, dando al equipo algo de historial de cambios aunque no haya control de versiones integrado.
Junto a eso, mantén un registro de despliegue ligero: una marca de tiempo, el nombre del workflow, quién lo aprobó y un hash de versión, para todo lo que se promueva de una instancia de construcción a una instancia de cliente o de producción. Considéralo completo cuando cada promoción a producción tenga una entrada correspondiente, no solo las que recuerdes anotar. No sustituirá a un registro de auditoría real, pero te da algo concreto a lo que apuntar cuando un workflow se comporta de forma distinta a como nadie recuerda haberlo configurado.
Sources: Compare editions | Deploy | n8n Docs, Follow best practices | Administer | n8n Docs
Usa la separación de instancias o entornos como límite de acceso
Si las convenciones por sí solas resultan demasiado frágiles en cuanto una tercera o cuarta persona empieza a construir, la solución más duradera en la edición Community es la separación por instancia en lugar de por rol. Un sandbox compartido para experimentar más instancias aisladas por cliente o por equipo da al equipo un límite real que no depende de que nadie recuerde una regla de nomenclatura, al coste de más infraestructura que mantener.
Creemos que merece la pena hacerlo antes de que parezca necesario: es mucho más fácil separar instancias antes de que un equipo haya superado un único inicio de sesión compartido que desenredar credenciales y workflows compartidos después del hecho.
Aquí es también donde reaparece la laguna anterior: la documentación de n8n describe que solo el propietario y el creador de la instancia tienen acceso en la edición Community, así que separar instancias no solo organiza el trabajo, sino que limita hasta dónde puede llegar un inicio de sesión comprometido o una acción descuidada de un administrador.
Sources: Compare editions | Deploy | n8n Docs
Cuándo las lagunas de n8n community rbac significan que deberías pagar por roles
Ninguna de estas soluciones temporales es una solución permanente, y la tabla anterior en esta checklist ya mapea dónde se cierran estas lagunas de n8n community rbac detrás de los niveles de pago, según la propia documentación de n8n.
En lugar de volver a enumerar qué nivel desbloquea qué rol, trata la checklist siguiente como el disparador práctico: cuando varias de estas señales se dan a la vez, es momento de actuar sin importar qué página de documentación estés leyendo.
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs, n8n Plans and Pricing - n8n.io
