Configure source control (Git) via environment variables, CLI, and API for IaC/GitOps deployments

The idea is:

Allow full Git source control configuration without the UI, through three complementary interfaces:

1. Environment Variables

New environment variables to pre-configure Git on startup:

Variable Type Description
N8N_SOURCECONTROL_REPO_URL String Git repository URL (SSH or HTTPS)
N8N_SOURCECONTROL_BRANCH String Branch to sync with
N8N_SOURCECONTROL_SSH_KEY String SSH private key content
N8N_SOURCECONTROL_SSH_KEY_FILE String Path to SSH private key file
N8N_SOURCECONTROL_HTTPS_USER String HTTPS username
N8N_SOURCECONTROL_HTTPS_TOKEN String HTTPS personal access token
N8N_SOURCECONTROL_CONNECTED Boolean Auto-connect to Git on startup
N8N_SOURCECONTROL_PULL_ON_STARTUP Boolean Auto-pull workflows when instance starts

Today only N8N_SOURCECONTROL_DEFAULT_SSH_KEY_TYPE exists (ed25519/rsa).

2. CLI Commands

Extend the n8n CLI with source control commands:

# Configure git repository
n8n sourcecontrol:configure [email protected]:org/repo.git --branch=main --sshKeyFile=/path/to/key

# Connect / disconnect
n8n sourcecontrol:connect
n8n sourcecontrol:disconnect

# Pull workflows from git
n8n sourcecontrol:pull

# Push workflows to git
n8n sourcecontrol:push

# Show current source control status
n8n sourcecontrol:status

Today the CLI supports export:workflow, import:workflow, export:credentials, etc. but has zero source control commands.

3. API Endpoints

Expose REST API endpoints for source control management:

PUT  /source-control/preferences  - Configure repo URL, branch, credentials
POST /source-control/connect      - Connect to configured repository
POST /source-control/disconnect   - Disconnect from repository
POST /source-control/pull         - Pull workflows from git
POST /source-control/push         - Push workflows to git
GET  /source-control/status       - Get current connection status and config

My use case:

We deploy n8n on Kubernetes with a fully declarative GitOps approach. All configuration is version-controlled: Helm values, environment variables, and secrets from Vault.

Git source control is the only configuration that requires manual UI interaction. Every time we deploy a new n8n instance (dev, preprod, prod), someone must:

  1. Open the browser
  2. Go to Settings > Environments
  3. Paste the repo URL
  4. Configure SSH or HTTPS credentials
  5. Select the branch
  6. Click Connect

This breaks the GitOps model and creates several problems:

  • New instances (scaling, disaster recovery, migration) require manual setup
  • CI/CD pipelines cannot fully automate n8n deployment
  • Configuration drift between environments when settings are applied by hand
  • No audit trail for source control configuration changes (unlike env vars in Git)

With environment variables, our Helm values would look like:

env:
  - name: N8N_SOURCECONTROL_REPO_URL
    value: "[email protected]:org/n8n-workflows.git"
  - name: N8N_SOURCECONTROL_BRANCH
    value: "main"
  - name: N8N_SOURCECONTROL_SSH_KEY
    value: "secret"
  - name: N8N_SOURCECONTROL_CONNECTED
    value: "true"
  - name: N8N_SOURCECONTROL_PULL_ON_STARTUP
    value: "true"

A fresh instance would boot up, connect to Git, and pull all workflows automatically. Zero manual steps.

I think it would be beneficial to add this because:

  1. GitOps/IaC compatibility - n8n is increasingly deployed on Kubernetes with tools like ArgoCD, FluxCD, and Terraform. Manual UI configuration is a blocker for fully automated deployments
  2. Reproducibility - if an instance is destroyed and recreated, Git should reconnect automatically without human intervention
  3. Multi-environment consistency - teams running dev/preprod/prod need each instance to point to the correct branch. This should be declarative, not manual
  4. CLI parity - the CLI already supports export:workflow, import:workflow, import:credentials but has no source control commands, which is an inconsistency
  5. The pattern already exists - N8N_SOURCECONTROL_DEFAULT_SSH_KEY_TYPE proves source control env vars are already supported, the coverage just needs to be extended
  6. Growing demand - multiple community threads show users struggling with this gap:

Any resources to support this?

Are you willing to work on this?

Yes, I’m willing to contribute code to implement this feature if it can speed up the implementation. Happy to submit a PR once the approach is validated by the maintainers.

Here is my implementation of the feature : feat(core): Add env var configuration, CLI commands, and public API for source control by RomainNeup · Pull Request #25538 · n8n-io/n8n · GitHub