Configura la gestión de usuarios en n8n antes de que tu equipo supere los inicios de sesión compartidos
Guía práctica de gestión de usuarios en n8n: invitar usuarios, elegir roles y organizar proyectos y credenciales para un equipo en crecimiento.
Comprobado con las fuentes citadas el .
Por qué los inicios de sesión compartidos se convierten en un riesgo a medida que crece el equipo
La mayoría de los equipos pequeños empiezan a usar n8n de la misma manera: una persona crea la cuenta y todos los que necesitan crear o editar un workflow usan ese mismo inicio de sesión. Funciona hasta que deja de funcionar. En cuanto una segunda o tercera persona necesita tocar workflows y credenciales, un único inicio de sesión compartido se convierte en un riesgo. Configurar la gestión de usuarios de n8n con antelación —antes de que el tamaño del equipo obligue a hacerlo— le da a cada persona su propia cuenta, sus propios permisos y un registro de lo que cambió, en lugar de una identidad anónima que todos comparten.
El costo práctico de omitir esto aparece de forma silenciosa. La documentación de n8n señala que no se registra la autoría de los workflows, por lo que no hay forma de saber quién creó un workflow en particular (F8), una carencia que se agrava cuando varias personas comparten un único inicio de sesión, porque incluso el nombre de la cuenta registrada deja de significar algo concreto. Consideramos que esto es más que una cuestión de buenas prácticas: cuando desaparece la atribución, también desaparece la responsabilidad sobre lo que realmente hace un workflow y sobre quién debe corregirlo.
Nada de esto requiere un plan más avanzado ni una migración: cualquier cuenta puede tener el rol de instancia básico de Owner o Member sin importar la edición, y solo ciertas capacidades específicas —el rol de instancia Admin, o los roles a nivel de proyecto— están limitadas según el plan (F1, F9).
Sources: Manage users and access | Administer | n8n Docs, Understand instance roles | Administer | n8n Docs, Set permissions and roles (RBAC) | Administer | n8n Docs
Qué incluye la función de gestión de usuarios de n8n
La gestión de usuarios de n8n incluye todo lo necesario para pasar de un inicio de sesión compartido a un equipo gestionado: invitar a las personas como usuarios con nombre, asignar un rol a cada una y mantener una vista única de quién tiene acceso. Los roles de instancia integrados son Owner, Admin y Member, y Admin solo está disponible en n8n Cloud Pro, Enterprise y Enterprise autoalojado (F1). La página Settings > Users muestra todas las cuentas de la instancia, incluidas las personas que han sido invitadas pero aún no han aceptado (F2), de modo que un admin puede ver exactamente quién todavía necesita configurar su inicio de sesión.
La gestión de usuarios también cubre qué sucede cuando alguien se va. Eliminar a un usuario activo no es un solo clic: el admin tiene que decidir si copia los workflows y credenciales de esa persona a un usuario sustituto o los elimina de forma definitiva (F3). Esa decisión importa más de lo que parece, porque es el momento en que el trabajo sin vincular ni atribuir se rescata o desaparece para siempre.
La diferencia entre planes importa al presupuestar el crecimiento del equipo. Un equipo puede invitar a Members con nombre en cualquier plan, pero solo las cuentas de n8n Cloud Pro, Enterprise o Enterprise autoalojado desbloquean el rol Admin, que puede ver y compartir todos los workflows en toda la instancia (F1). Saber esto antes de implementar evita descubrir a mitad de proyecto que el plan actual no admite la supervisión que el equipo creía tener.
Sources: Manage users and access | Administer | n8n Docs, Add and remove users | Administer | n8n Docs
Cómo configurar la gestión de usuarios de n8n e invitar a tus primeros usuarios
Activar la gestión de usuarios de n8n es una configuración breve, no un proyecto. El owner de la instancia configura el SMTP, invita a cada compañero por correo electrónico desde la página Users y permite que cada persona elija su propia contraseña en lugar de compartir la del owner. Los nuevos usuarios se pueden invitar directamente desde la página Users de la cuenta owner introduciendo su dirección de correo y haciendo clic en Invite (F6).
La ruta exacta de clics es sencilla una vez configurado el SMTP. Desde la cuenta owner, se abre el menú de tres puntos junto al icono de usuario, se selecciona Settings, luego Users, y se hace clic en Invite para introducir la dirección de correo de un nuevo compañero (F6). Al enviar la invitación se envía un correo con un enlace que la nueva persona usa para establecer su propia contraseña, de modo que la contraseña del owner nunca tiene que compartirse con nadie (F6).
Ninguno de estos pasos requiere que el nuevo compañero contacte directamente con el owner. Una vez configurado el SMTP, el correo de invitación contiene todo lo necesario para establecer una contraseña y empezar por su cuenta (F6, F4). Es una decisión de diseño deliberada: invitar a las personas como usuarios con nombre, en lugar de incorporarlas a una contraseña compartida, es precisamente el sentido de configurar la gestión de usuarios.
Sources: User management | Deploy | n8n Docs
Configurar el SMTP para invitaciones y restablecimiento de contraseñas
La configuración del SMTP solía ser obligatoria en toda instancia autoalojada; se volvió opcional a partir de la versión 0.210.1 de n8n (F4). Esa flexibilidad ayuda para una prueba rápida, pero tiene un costo real en cualquier cosa pensada para durar: si un equipo omite el SMTP, los usuarios invitados no pueden usar el flujo de restablecimiento de contraseña (F5), por lo que cada contraseña olvidada se convierte en una tarea manual para quien tenga la cuenta owner.
En la práctica, configuraríamos el SMTP desde la primera configuración, incluso en una instancia autoalojada pequeña, porque ahora toma solo unos minutos y elimina una carga de soporte recurrente más adelante, en cuanto más de dos o tres personas dependan de restablecer sus propias contraseñas.
Habilitar el SMTP en una instancia autoalojada implica establecer los datos del servidor de correo mediante variables de entorno en lugar de una pantalla de configuración dentro de la app, ya que esa configuración se aplica a través de variables de entorno (F4). Es un paso único para quien gestiona el despliegue, no algo que cada usuario invitado tenga que pensar.
Sources: User management | Deploy | n8n Docs
Crear la cuenta owner e invitar a los compañeros
Con el SMTP configurado, cada compañero recibe su propia invitación en lugar de la contraseña del owner, siguiendo el mismo flujo de la página Users descrito anteriormente (F6).
La propia documentación de n8n recomienda que el owner de la instancia cree una segunda cuenta con el rol Member para el trabajo diario, en lugar de construir workflows mientras está conectado como Owner (F7). Esto se desprende directamente de la carencia de atribución descrita antes: un owner que sigue editando directamente puede terminar sobrescribiendo en silencio el trabajo de un compañero sin que nadie se dé cuenta (F8).
Sources: User management | Deploy | n8n Docs, Understand instance roles | Administer | n8n Docs
Elegir los roles adecuados según tu plan
Una vez que cada persona tiene su propio inicio de sesión, la siguiente decisión es qué puede hacer realmente cada una. El sistema de roles de n8n funciona en dos niveles: los roles de instancia, que se aplican a toda la cuenta, y los roles de proyecto, que se aplican dentro de un proyecto concreto. Ambos están limitados según el plan, y los roles de proyecto están disponibles de forma más amplia que los roles personalizados, que se detallan en las secciones siguientes (F9, F10).
Una estructura inicial habitual da a todos el rol Member a nivel de instancia, crea un proyecto por equipo o cliente, y asigna Project Admin a quien tome las decisiones diarias de ese proyecto. Las cuentas Admin a nivel de Owner, o los roles de proyecto Editor y Viewer, pueden añadirse después, en cuanto surja una necesidad específica de supervisión a nivel de instancia o de acceso de solo lectura (F9, F10).
Los equipos autoalojados se enfrentan a una complicación adicional: los roles de proyecto requieren al menos una edición Registered Community en lugar de la versión de código abierto totalmente sin registrar, y los roles personalizados de instancia o de proyecto requieren específicamente el nivel Enterprise autoalojado (F9, F10). Comprobar el plan real del equipo frente a estos requisitos antes de prometerle a un colega un rol concreto evita una retractación incómoda más adelante. Es un pequeño trabajo previo que vale la pena la primera vez que alguien pide un rol que el plan actual no incluye.
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs
Roles de instancia: Owner, Admin y Member
Owner, Admin y Member forman los tres roles de instancia de n8n; los requisitos de plan de Admin se explicaron antes (F1). Los Owners y Admins pueden ver y compartir todos los workflows de la instancia, no solo los propios (F18); los Members se limitan a lo que se les haya compartido explícitamente. Esa asimetría es precisamente el sentido de la división de roles: Owner y Admin existen para las personas que realmente necesitan supervisión a nivel de toda la instancia, no para todo el que construya workflows.
Dado que tanto Owner como Admin pueden ver y compartir todos los workflows de toda la instancia, conviene mantener ambos roles reservados en lugar de otorgarlos por defecto. Un número reducido de cuentas Owner o Admin, con el resto de personas en Member o en un rol de proyecto, mantiene el grupo de quienes pueden tocar cualquier workflow de la instancia lo bastante pequeño como para poder revisarlo de verdad (F18).
| Rol | Alcance típico | Requisito de plan |
|---|---|---|
| Owner | Control total de la instancia, se crea durante la configuración inicial | Todos los planes de n8n Cloud y autoalojados |
| Admin | Visibilidad de toda la instancia, gestión de usuarios y compartición de todos los workflows | n8n Cloud Pro, Enterprise y Enterprise autoalojado |
| Member | Acceso limitado a los workflows y credenciales que se le hayan compartido explícitamente | Todos los planes de n8n Cloud y autoalojados |
Sources: Manage users and access | Administer | n8n Docs, Share with others | Build | n8n Docs
Roles de proyecto (RBAC): Admin, Editor y Viewer
Dentro de un proyecto, tres roles permiten un control más detallado: Project Admin, Project Editor y Project Viewer. Project Editor está limitado a n8n Cloud Pro y Enterprise autoalojado (F11), y Project Viewer otorga acceso de solo lectura a los workflows, credenciales y ejecuciones de un proyecto sin permitir que esa persona ejecute nada (F12). En conjunto, los roles de proyecto están disponibles en todos los planes de n8n Cloud y en las versiones autoalojadas Registered Community, Business y Enterprise (F9).
Elegir entre Editor y Viewer dentro de un proyecto depende sobre todo de quién necesita modificar cosas frente a quién solo necesita visibilidad. Un revisor o una parte interesada que deba ver los workflows y ejecuciones de un proyecto pero nunca editarlos ni ejecutarlos se ajusta al rol Viewer; cualquiera que esté construyendo o manteniendo workflows activamente necesita Editor, donde el plan lo permita, o Project Admin si además necesita gestionar la membresía del proyecto (F11, F12, F9). Combinar ambos dentro de un mismo proyecto —algunas personas como Editor, otras como Viewer— es normal y a menudo la forma más simple de abrir la visibilidad sin abrir la edición.
| Rol | Qué puede hacer | Requisito de plan |
|---|---|---|
| Project Admin | Gestionar la membresía del proyecto y compartir sus credenciales | n8n Cloud (todos los planes) y autoalojado Registered Community, Business y Enterprise |
| Project Editor | Crear y editar workflows dentro del proyecto | n8n Cloud Pro y Enterprise autoalojado |
| Project Viewer | Vista de solo lectura de los workflows, credenciales y ejecuciones del proyecto | n8n Cloud Enterprise y Enterprise autoalojado |
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs, See available roles | Administer | n8n Docs
Estructurar el acceso por proyecto y por credencial
Los roles responden a quién puede hacer qué dentro de un proyecto; los proyectos responden a dónde vive ese trabajo. Un proyecto agrupa un conjunto de workflows, credenciales y usuarios, y solo los owners y los admins de instancia pueden crear un nuevo proyecto (F15).
Decidir los límites de los proyectos antes de poblar una instancia importa más de lo que parece, porque n8n vincula la compartición al proyecto en el que vive un workflow o una credencial, y moverlo más adelante elimina su compartición existente (F15, F16). Agrupar por equipo, por cliente o por entorno son puntos de partida razonables; lo importante es elegir uno antes de que los workflows y las credenciales se acumulen fuera de cualquier proyecto.
Sources: Organize work in projects | Administer | n8n Docs
Organizar workflows y credenciales en proyectos
Dentro de un proyecto, la membresía del día a día se gestiona localmente: añadir o eliminar a un miembro de un proyecto específico lo gestionan los Project Admins de ese proyecto (F17). Eso mantiene los cambios de membresía cerca de las personas que realmente usan el proyecto, en lugar de canalizar cada pequeño cambio a través de un único admin de toda la instancia.
Mover un workflow o una credencial a un proyecto distinto, o a un usuario propietario distinto, elimina toda su compartición existente (F16). Hay que tratarlo como una puerta de un solo sentido: decidir la estructura de proyectos antes de poblarla con trabajo compartido, ya que reorganizarla después implica volver a compartir todo desde cero.
Por ejemplo, un equipo que más adelante divide un proyecto de operaciones en dos más pequeños tendría que volver a compartir cada workflow y credencial con las personas adecuadas dentro de los nuevos proyectos, ya que ninguna de las comparticiones originales se traslada (F16). Tratar los límites de los proyectos como algo semipermanente evita ese trabajo repetido.
Sources: Organize work in projects | Administer | n8n Docs
Compartir workflows y credenciales sin excederse
Solo los owners de instancia y los usuarios con el rol de instancia Admin pueden ver y compartir todos los workflows de toda la instancia (F18); el resto solo ve lo que se les ha compartido explícitamente. Compartir un workflow no comparte automáticamente aquello de lo que depende: si se comparte un workflow sin sus credenciales subyacentes, el destinatario no puede editar los nodos que usan esas credenciales (F19).
Las credenciales creadas dentro de un proyecto solo pueden ser compartidas por los Project Admins de ese proyecto (F20), y una vez que se comparte una credencial, el destinatario conecta su propia cuenta subyacente en lugar de reutilizar la conexión del propietario original (F21). Creemos que exigir a cada persona conectar su propia cuenta, en lugar de reutilizar la de otra, es uno de los mejores comportamientos predeterminados de n8n, porque mantiene pequeño el alcance del daño si una credencial se filtra o se revoca.
- Compartir un workflow junto con las credenciales de las que dependen sus nodos, o los destinatarios no podrán editar esos nodos
- Dejar que los project admins, no todos los miembros, decidan quién recibe una credencial compartida
- Esperar que cada destinatario conecte su propia cuenta subyacente en lugar de reutilizar la tuya
Sources: Share with others | Build | n8n Docs, Share credentials securely | Administer | n8n Docs
Mirando hacia adelante: roles personalizados, SSO y gobernanza a gran escala
Todo lo anterior funciona dentro de los roles integrados de n8n. Los equipos que necesitan un control más fino —por ejemplo, un rol que pueda editar workflows pero nunca tocar credenciales— se topan con un muro: los roles personalizados de instancia y de proyecto más allá del conjunto integrado están restringidos a n8n Cloud Enterprise y Enterprise autoalojado (F14). La propia documentación de n8n sobre roles personalizados presenta esto como algo deliberado: los roles personalizados existen para que un admin pueda otorgar solo las capacidades concretas que necesita una persona, en lugar de repartir acceso Admin completo como solución alternativa (F13).
El blog de n8n, publicado en enero de 2026, describe los Custom Project Roles como una forma de que los admins modelen roles operativos —constructores, revisores, operadores— con permisos granulares a nivel de proyecto (F22), y describe el aprovisionamiento de usuarios basado en SSO como la sincronización automática de los permisos de una persona desde un proveedor de identidad hacia n8n a medida que cambia su rol allí (F23). Ambas son capacidades de nivel Enterprise, descritas en el propio anuncio de n8n y no verificadas de forma independiente en otro lugar.
Los roles personalizados exclusivos de Enterprise y el aprovisionamiento por SSO suelen volverse relevantes cuando el tamaño del equipo o las necesidades de cumplimiento superan los roles integrados, en lugar de ser necesarios desde el primer día. Los roles de instancia y de proyecto integrados, combinados con una estructura de proyectos deliberada y una compartición cuidadosa de credenciales, cubren la mayor parte de lo que necesita un equipo en crecimiento hasta que aparecen esos requisitos (F13, F14, F22, F23).
Sources: Custom roles | Administer | n8n Docs, Introducing Custom Project Roles and User Provisioning via SSO, built for Enterprise governance – n8n Blog
