n8n Security: Credentials, Webhook Auth & Self-Hosted Hardening

n8n protects automation data through AES‑256 credential encryption, multiple webhook authentication methods, and configurable self‑hosted hardening. All secrets can be externalized to vaults like HashiCorp Vault or AWS Secrets Manager. This guide details each security layer, from storing a single API key to production‑grade deployment.

How does n8n encrypt stored credentials?

n8n encrypts every credential you save using AES‑256 in CBC mode. A random initialization vector (IV) is generated per encryption operation, and the encryption key is stored in the n8n configuration. This ensures that even if the database is compromised, credential values remain unreadable without the key. [1]

For self‑hosted instances, you can rotate the encryption key by generating a new one and re‑encrypting existing credentials. Cloud users benefit from automatic key management without manual intervention.

What external secret storage integrations does n8n support?

n8n retrieves secrets from environment variables, HashiCorp Vault, and AWS Secrets Manager at runtime. This decouples sensitive values from workflow definitions and enables centralized secret rotation. You reference a secret in a credential field by using $env:SECRET_NAME or the vault‑specific syntax without hardcoding any tokens. [2]

Vault integration additionally supports dynamic secrets for databases, reducing the blast radius of credential leaks. See the node expressions guide for proper syntax usage.

How do you authenticate webhooks with HMAC, OAuth2, and Basic Auth?

n8n webhook nodes support three authentication methods: HMAC signature verification, OAuth2 token validation, and Basic/Header Auth. HMAC compares a computed signature of the request body against a header value using a shared secret. OAuth2 validates bearer tokens; Basic Auth checks a username and password pair sent in the header.

Choose HMAC for maximum integrity protection; it proves both sender identity and payload authenticity. Learn more in our types of workflows article.

How do environment variables protect sensitive data in n8n?

Environment variables inject secrets at the operating system level, keeping them out of workflow JSON exports and version control. n8n reads variables prefixed with N8N_ or custom names you define. You can then reference them in any credential field, avoiding plaintext secrets in the workflow canvas entirely. [3]

This method is the simplest to implement for Docker deployments: pass -e SECRET=value at container startup. Combined with a .env file and proper file permissions, it covers most small‑ to medium‑scale security needs.

What hardening steps should self-hosted n8n deployments follow?

Self‑hosted hardening requires terminating HTTPS at a reverse proxy like Nginx or Caddy, enabling queue mode with isolated workers, and setting restrictive firewall rules. You should also disable the public API if not needed and run n8n under a dedicated, non‑root user account for process isolation. [4]

For high‑availability setups, combine these measures with Redis‑backed queue mode, as detailed in n8n architecture and scaling.

How do vault integrations like HashiCorp Vault manage n8n credentials?

HashiCorp Vault provides dynamic, time‑limited credentials that n8n retrieves at workflow execution time. You configure a Vault connection in n8n’s settings, then reference secrets using a path like {{$vault.secret.path}}. This eliminates static credentials and enables automatic rotation every few hours. [5]

Vault integration is ideal for enterprise environments with strict compliance requirements. For simpler setups, AWS Secrets Manager offers a comparable managed service.