Best way to automate credential syncing between self-hosted dev and prod n8n instances?

Hi everyone,

I’m running 2 self-hosted (EKS) n8n instances - dev and prod. Right now, whenever I update or add credentials in dev, I have to manually recreate/update them in prod as well, which is tedious and error-prone, especially as the number of workflows and credentials grows.

I’m stuck on how to avoid this manual syncing step. What are the best possible ways to automate syncing credentials between dev and prod self-hosted instances?

A few things I’d love input on:

  • Is there a supported way to export/import credentials via the CLI or API that could be scripted?
  • Has anyone set up a CI/CD pipeline (e.g., using source control + n8n CLI) to promote credentials/workflows from dev to prod?
  • Are environment variables or an external secrets manager (Vault, AWS Secrets Manager, etc.) a better long-term approach than storing credentials directly in each instance?
  • Any advice, workflows, or examples from people who solved this would be greatly appreciated. Thanks!

The n8n CLI is the primary way to script this. You can indeed export and import both workflows and credentials.

The Hurdle: The Encryption Key n8n encrypts all credentials in its database using the N8N_ENCRYPTION_KEY. If your Dev and Prod EKS instances have different keys (which they should for security), a direct export/import of encrypted files will fail in Prod because the Prod instance won’t be able to decrypt them.

The Solution: Decrypted Intermediate Files You can use the --decrypted flag to bypass this, but you must handle the resulting plain-text files with extreme care.

Proposed Workflow:

  1. Dev Side: Run a script in your Dev container: n8n export:credentials --all --decrypted --output=credentials_export/
  2. Secure Transport: Push these JSON files to a secure, ephemeral location (e.g., an encrypted AWS S3 bucket with a lifecycle policy to delete after 1 day, or an AWS Secrets Manager entry). Never commit these plain-text JSONs to your Git repository.
  3. Prod Side (CI/CD Pipeline):
    • Pull the decrypted JSONs from your secure storage.
    • Run the import command in your Prod container: n8n import:credentials --input=credentials_export/ --separate
    • Immediately wipe the local files after the import.

For a professional EKS setup, you should move away from treating n8n’s internal database as the “source of truth” for secrets. Instead, treat your credentials as part of your infrastructure.

The Strategy: External Secrets Manager + Environment Variables Instead of syncing the “Credential Entity” in n8n, you leverage n8n’s ability to use environment variables for many service configurations.

  • Architecture: Store your actual API keys/passwords in AWS Secrets Manager or HashiCorp Vault​.
  • Implementation:
    1. Use the External Secrets Operator (ESO) in your EKS cluster to sync AWS Secrets Manager values into Kubernetes Secrets.
    2. Inject these Kubernetes Secrets into your n8n Pods as environment variables.
    3. While n8n’s UI-created credentials are DB-based, you can use the n8n API within a CI/CD pipeline to “provision” credentials using those environment variables as the input values. This ensures that the definition of the credential lives in your code/vault, and only the value is injected at runtime.