feat(chart): add support for variables from existing secrets

[kamiKAC]

Pull Request

Description

Adds support for sourcing selected database and Redis connection values from existing Kubernetes Secrets.

This change avoids duplicate environment variable definitions in queue mode by rendering each DB and Redis env var from either a ConfigMap or a Secret, depending on the configured secret keys. It also updates chart validation so the required values can be provided either directly or through secret references.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Example/configuration update
• CI/CD improvements

Related Issues

Fixes # (issue)
Relates to # (issue)

Changes Made

• Added support for sourcing database.host, database.port, and database.database from database.existingSecret.
• Added support for sourcing database.user from database.userSecret.
• Added support for sourcing redis.host, redis.port, and redis.clusterNodes from redis.existingSecret.
• Added support for sourcing redis.username from redis.usernameSecret.
• Updated env rendering in _configmap-env.tpl and configmap.yaml so DB and Redis variables are defined only once, preventing duplicate env entries in the worker deployment.
• Updated _helpers.tpl validation to allow either direct values or secret-backed configuration for queue mode requirements.
• Extended values.schema.json with the new secret objects and direct-or-secret validation rules.
• Documented the new configuration options in values.yaml.

Testing Performed

Chart Validation

• helm lint charts/n8n passes
• ./scripts/validate-examples.sh passes
• Template rendering works with all examples

Deployment Testing (if applicable)

• Tested with minimal configuration
• Tested with production configuration
• Tested upgrade path from previous version
• All pods start successfully
• Application is accessible

Specific Testing for Changes

Describe any specific testing you performed for your changes:

• Ran helm lint charts/n8n successfully.
• Ran helm template against all example values files with a non-placeholder encryption key and verified they all render successfully:
  • keda-autoscaling.yaml
  • minimal-with-docker.yaml
  • minimal.yaml
  • multi-main-queue.yaml
  • production-s3.yaml
  • standalone.yaml
  • task-runners.yaml
• Confirmed the change addresses duplicate worker env definitions for DB_POSTGRESDB_USER, DB_POSTGRESDB_PORT, DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, QUEUE_BULL_REDIS_HOST, and QUEUE_BULL_REDIS_PORT.

Breaking Changes

If this includes breaking changes, describe what they are and provide migration instructions:

• None.

Documentation Updates

• Updated Chart.yaml version (if needed)
• Updated CHANGELOG.md
• Updated README.md (if needed)
• Updated examples (if needed)
• Updated CONTRIBUTING.md (if needed)

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have added examples that demonstrate the changes (if applicable)
• All new and existing tests pass

Screenshots (if applicable)

Add screenshots to help explain your changes.

Additional Notes

• This PR is focused on existing-secret support for DB and Redis connection values used by queue mode.

[cubic-dev-ai]

1 issue found across 6 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="charts/n8n/values.schema.json">

<violation number="1" location="charts/n8n/values.schema.json:525">
P1: Schema `anyOf` branches for database.existingSecret and database.userSecret lack `required`, causing them to pass vacuously when the property is absent. This allows invalid database configurations to incorrectly pass validation.</violation>
</file>

Architecture diagram

sequenceDiagram
    participant User as Helm User
    participant CLI as Helm CLI
    participant Chart as n8n Chart (values.yaml + helpers)
    participant Schema as values.schema.json
    participant ConfigMap as ConfigMap (configmap.yaml)
    participant Secret as Kubernetes Secret (existing)
    participant Pod as n8n Pod (worker/main)

    Note over User,Pod: Helm Chart Deployment Flow

    User->>CLI: helm install/upgrade with values
    CLI->>Chart: Load values.yaml + user overrides

    Note over Chart,Schema: Chart Validation Phase
    Chart->>Schema: Validate against schema.json
    Schema-->>Chart: Validation result

    alt queueMode.enabled = true
        Schema->>Chart: Check database requirements
        alt database.host/port/database provided
            Note over Chart,Schema: Direct values path (no change)
        else database.existingSecret.name is set
            Note over Chart,Schema: Secret-backed path (NEW)
        end
        
        alt database.user provided
            Note over Chart,Schema: Direct value path
        else database.userSecret.name is set
            Note over Chart,Schema: User from secret (NEW)
        end
        
        alt redis.host or redis.clusterNodes provided
            Note over Chart,Schema: Direct values path
        else redis.existingSecret name + hostKey/clusterNodesKey
            Note over Chart,Schema: Redis config from secret (NEW)
        end
        
        alt redis.username provided
            Note over Chart,Schema: Direct username
        else redis.usernameSecret.name is set
            Note over Chart,Schema: Username from secret (NEW)
        end
    end

    Chart->>ConfigMap: Generate configmap.yaml
    Note over ConfigMap: Conditionally omit keys<br/>when secret-backed

    alt database.existingSecret.name + databaseKey
        Note over ConfigMap: Skip DB_POSTGRESDB_DATABASE in ConfigMap
    else
        ConfigMap->>ConfigMap: Include DB_POSTGRESDB_DATABASE
    end

    alt database.existingSecret.name + hostKey
        Note over ConfigMap: Skip DB_POSTGRESDB_HOST in ConfigMap
    end

    alt database.existingSecret.name + portKey
        Note over ConfigMap: Skip DB_POSTGRESDB_PORT in ConfigMap
    end

    alt database.userSecret.name
        Note over ConfigMap: Skip DB_POSTGRESDB_USER in ConfigMap
    end

    alt redis.existingSecret.name + clusterNodesKey
        Note over ConfigMap: Skip REDIS_CLUSTER_NODES in ConfigMap
    else redis.existingSecret.name + hostKey
        Note over ConfigMap: Skip REDIS_HOST in ConfigMap
    end

    alt redis.existingSecret.name + portKey
        Note over ConfigMap: Skip REDIS_PORT in ConfigMap
    end

    alt redis.usernameSecret.name
        Note over ConfigMap: Skip REDIS_USERNAME in ConfigMap
    end

    ConfigMap-->>Pod: Mount as environment
    Note over Pod: Env vars from ConfigMap

    Pod->>Secret: Read secret-backed values (NEW)
    Note over Pod: DB/Redis connection values<br/>sourced from existing Secrets

    Pod->>Pod: n8n starts with resolved config
    Note over Pod: DB_POSTGRESDB_HOST/PORT/DATABASE/USER<br/>QUEUE_BULL_REDIS_HOST/PORT/CLUSTER_NODES/USERNAME

Loading

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[cubic-dev-ai]

P1: Schema anyOf branches for database.existingSecret and database.userSecret lack required, causing them to pass vacuously when the property is absent. This allows invalid database configurations to incorrectly pass validation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At charts/n8n/values.schema.json, line 525:

<comment>Schema `anyOf` branches for database.existingSecret and database.userSecret lack `required`, causing them to pass vacuously when the property is absent. This allows invalid database configurations to incorrectly pass validation.</comment>

<file context>
@@ -522,6 +522,24 @@
         "port": { "type": "integer" },
         "database": { "type": "string" },
         "user": { "type": "string" },
+        "existingSecret": {
+          "type": "object",
+          "properties": {
</file context>