Cómo cifra n8n las credenciales, quién puede compartirlas en el equipo y cómo External Secrets gestiona los datos de acceso fuera de n8n.
Las credenciales son el verdadero corazón de toda automatización de n8n: sin una clave API, un token OAuth2 o una contraseña de base de datos, ningún trabajador digital puede comunicarse con sistemas externos. Por eso merece la pena analizar de cerca cómo protege n8n realmente estas credenciales, quién en el equipo puede utilizarlas sin verlas, y cómo mantener los valores sensibles completamente fuera de n8n haciendo que un almacén de secretos externo los gestione. Fecha: julio de 2026.
Este artículo distingue claramente tres niveles: el modelo de cifrado en segundo plano, los permisos de uso compartido para equipos y la integración de almacenes de secretos externos para configuraciones Enterprise. Al final, usted mantendrá el control sobre qué nivel es el adecuado para su configuración.
n8n almacena siempre todos los datos de acceso cifrados en la base de datos, nunca en texto plano. Según la guía de n8n sobre cómo definir su propia clave de cifrado, n8n genera automáticamente una clave aleatoria en el primer inicio y la guarda en la carpeta `~/.n8n`. n8n utiliza esta clave para cifrar cada credencial antes de escribirla en la base de datos. Si desea mantener usted mismo el control sobre esta clave, por ejemplo para gestionarla de forma centralizada o crear una copia de seguridad independiente del sistema de archivos, defina la siguiente variable de entorno antes de iniciar:
```
export N8N_ENCRYPTION_KEY=<una cadena larga y aleatoria>
```
Importante en el uso en equipo y en producción: si n8n se ejecuta en modo cola (queue) con varios workers, todas las instancias deben usar exactamente el mismo valor para `N8N_ENCRYPTION_KEY`. De lo contrario, los workers no pueden descifrar los datos de acceso cifrados por el proceso principal, y los workflows fallan justo en el punto donde se necesita una credencial.
Para las instancias autoalojadas, n8n ofrece además una rotación del cifrado. Según la documentación sobre la rotación de claves de cifrado, n8n trabaja aquí con dos niveles:
Los datos ya cifrados siguen siendo legibles después de una rotación; n8n los vuelve a cifrar automáticamente con la nueva Data Encryption Key en las próximas operaciones de escritura. La función se activa mediante la variable de entorno `N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true` en todas las instancias, tras lo cual la rotación se puede iniciar en Settings > Data Encryption Keys en la interfaz o mediante la API (`POST /encryption/keys`). Un punto que conviene tener muy claro de antemano: una vez que la función está activa y se han escrito nuevos datos en el nuevo formato, la rotación ya no se puede deshacer y no existe ninguna herramienta automatizada para reconvertir los datos. Por eso, una copia de seguridad completa de la base de datos antes de la activación no es opcional, sino obligatoria.
En cuanto varias personas trabajan en los mismos workflows, surge la pregunta de quién puede ver y utilizar qué datos de acceso. n8n distingue aquí deliberadamente entre el uso de una credencial y la visibilidad de sus valores. Según la documentación sobre cómo compartir workflows, la regla es la siguiente: quien comparte un workflow comparte automáticamente también el acceso a todas las credenciales utilizadas en él, incluso si estas no se compartieron explícitamente de forma individual. Esto garantiza que los workflows compartidos sigan siendo realmente ejecutables para todos los implicados.
En cuanto a los roles, n8n distingue entre dos niveles:
El principio del mínimo privilegio sigue aplicándose de forma coherente: si una credencial utilizada en el workflow no se ha compartido además de forma individual, un Editor puede ejecutar el workflow y editar otros nodos, pero no puede modificar precisamente el nodo con la credencial no compartida. Los valores de una credencial compartida, es decir, claves API o contraseñas, permanecen fundamentalmente invisibles para los Editors. Pueden utilizar la credencial, pero no leerla. Una nota práctica importante al margen: la propiedad de un workflow no se puede transferir simplemente, salvo en el marco de la eliminación de una cuenta de usuario. Por lo tanto, quien trabaje en equipo desde el principio debería crear los workflows preferiblemente directamente en un proyecto compartido en lugar de en el espacio de trabajo personal, ya que, según la documentación, añadir usuarios individuales mediante la función "Add users" solo funciona para workflows en el espacio personal. En los workflows dentro de un proyecto, la asignación de permisos se realiza en cambio a través de la propia pertenencia al proyecto.
Para las configuraciones Enterprise, n8n va un paso más allá y permite que los valores sensibles no se almacenen en absoluto en n8n, sino que permanezcan en un almacén de secretos externo. Según la documentación sobre almacenes de secretos externos, n8n admite seis proveedores para ello:
Esta función está reservada a los planes Enterprise Self-hosted y Enterprise Cloud. Se configura un vault en Settings > External Secrets mediante "Add secrets vault": allí asigna un nombre único al vault, selecciona el proveedor e introduce los datos de acceso necesarios. Dentro de una credencial, se accede después al valor externo mediante una expresión, por ejemplo:
```
{{ $secrets.<vault-name>.<secret-name> }}
```
Para 1Password existe una sintaxis ampliada con título del elemento y nombre del campo: `{{ $secrets.<vault-name>.<item-title>.<field-label> }}`. Conviene conocer una limitación técnica: n8n solo admite valores de texto simples para los secretos, no objetos JSON, y las expresiones solo funcionan dentro de los campos de credenciales, no en otros campos con soporte de expresiones. En cambio, la variable de entorno `N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL` permite definir con qué frecuencia n8n comprueba los cambios en el almacén externo, de forma predeterminada cada 300 segundos.
Para equipos pequeños, en la práctica a menudo ya basta con un `N8N_ENCRYPTION_KEY` bien configurado combinado con estructuras de proyecto y de uso compartido bien pensadas: quién puede ver qué workflow determina automáticamente también quién puede utilizar qué credencial. Pero en cuanto varios entornos, por ejemplo staging y producción, necesitan los mismos accesos API, o un requisito de cumplimiento exige que los secretos se mantengan de forma centralizada en un vault y también se roten allí de forma centralizada, External Secrets se convierte en un complemento razonable. Ambos niveles no se excluyen entre sí y se pueden combinar: el cifrado de la base de datos protege lo que n8n almacena por sí mismo, mientras que External Secrets reduce además lo que n8n tiene que almacenar de forma permanente.
Quien configure una instancia de n8n para un equipo y desee planificar correctamente desde el principio el cifrado, la asignación de permisos y, en su caso, los almacenes de secretos externos, encontrará apoyo en las automatizaciones de n8n de NordFlux, para que los datos de acceso sensibles estén desde el principio donde deben estar.
De forma predeterminada, n8n almacena la clave generada aleatoriamente en el primer inicio en la carpeta `~/.n8n` y la utiliza para cifrar las credenciales antes de guardarlas en la base de datos. Quien desee definir la clave por sí mismo debe establecer la variable de entorno `N8N_ENCRYPTION_KEY` antes del primer inicio.
Sí, ese es exactamente el caso estándar. Si una credencial se comparte con un usuario o a través de un proyecto, esa persona puede utilizar la credencial en sus propios workflows, pero los valores reales, como las claves API o las contraseñas, permanecen ocultos.
Si se comparte un workflow, la persona invitada puede ejecutarlo por completo de todos modos, ya que compartir un workflow incluye automáticamente el uso de todas las credenciales que contiene. Sin embargo, el nodo afectado solo se puede editar si la credencial también se ha compartido de forma individual; todos los demás nodos del workflow no se ven afectados.
No. Según la documentación, External Secrets solo está disponible en los planes Enterprise Self-hosted y Enterprise Cloud. Actualmente se admiten seis proveedores: 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault e Infisical.
No. Una vez activada la rotación de claves y que n8n ha escrito datos en el nuevo formato, la función ya no se puede desactivar y no existe ninguna herramienta automatizada para volver al formato anterior. Por ello, se recomienda encarecidamente realizar una copia de seguridad completa de la base de datos antes de la activación.
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
Cómo endurecer n8n: activar la 2FA, configurar la protección SSRF, bloquear nodes de riesgo con NODES_EXCLUDE y desactivar la Public API cuando no se utiliza.
Si pierde la clave de cifrado de n8n, todas las credenciales guardadas quedan inutilizables. Así se respaldan correctamente workflows, credenciales y claves.
Cómo configurar las credenciales de Anthropic y OpenAI en n8n, elegir el modelo adecuado para cada tarea y mantener bajo control los costes de tokens.
El cifrado por sí solo no protege mucho si los permisos compartidos en el equipo son demasiado amplios o falta External Secrets. NordFlux revisa el modelo de permisos de su instalación n8n e implanta una gestión de credentials acorde al tamaño de su equipo y a sus requisitos de cumplimiento. En una primera conversación repasamos juntos su configuración actual.
