Environment Variables Not Injected into Runner Pods in Self-Hosted Kubernetes Deployment (v4.0.4)

Description

Environment variables configured in the Trigger.dev portal are not being injected into runner pods during task execution in a self-hosted Kubernetes deployment. Tasks fail immediately with missing environment variable errors, despite variables being correctly configured in the portal.

Environment

• Deployment Type: Self-hosted Kubernetes (AWS EKS)
• Helm Chart Version: 4.0.5
• App Version: v4.0.4
• Database: External RDS PostgreSQL 15.10
• Container Runtime: containerd
• Kubernetes Version: 1.31

Expected Behavior

Based on theTrigger.dev documentation:

Environment variables are fetched and injected before a run begins.

When environment variables are configured in the Trigger.dev portal for a project/environment, they should be:

1. Fetched from the database by the webapp
2. Decrypted using theENCRYPTION_KEY
3. Included in the dequeue response
4. Injected into runner pods by the supervisor

Actual Behavior

Environment variables configured in the portal are NOT injected into runner pods. Runner pods start without the configured environment variables, causing tasks to fail immediately.

Reproduction Steps

1. Deploy Trigger.dev v4.0.4 to Kubernetes using Helm chart 4.0.5
2. Configure environment variables in the portal (e.g., Project Settings → Environment Variables)
3. Add variables for production environment (e.g.,SUPABASE_URL,SUPABASE_SERVICE_ROLE_KEY)
4. Create a task that uses these environment variables:

   exportconstmyTask=task({id:"test-task",run:async()=>{if(!process.env.SUPABASE_URL||!process.env.SUPABASE_SERVICE_ROLE_KEY){thrownewError("Missing required environment variables");}// Task logic here}});

5. Trigger the task from the portal
6. Task fails with "Missing required environment variables"

Investigation Evidence

1. Environment Variables ARE Configured Correctly in Database

-- Query to verify environment variables existSELECTev.key, evv."environmentId",sr.idas"secretRefId"FROM"EnvironmentVariable" evJOIN"EnvironmentVariableValue" evvONev.id= evv."variableId"JOIN"SecretReference" srON evv."valueReferenceId"=sr.idWHERE evv."environmentId"='<environment-id>'ANDev.keyIN ('SUPABASE_URL','SUPABASE_SERVICE_ROLE_KEY');

Result: ✅ Both variables exist in database with encrypted values inSecretReference table

2. Webapp HAS Required Configuration

Verified viakubectl exec:

• ✅ENCRYPTION_KEY: Present (32 hex characters)
• ✅DATABASE_URL: Connected to PostgreSQL
• ✅DIRECT_URL: Connected to PostgreSQL

3. Dequeue Response Does NOT Include Environment Variables

From supervisor logs during task execution:

{"message":"[KubernetesWorkloadManager] Creating container","opts": {"envId":"cmj8vz5v200060826t5qq2ro1","envType":"PRODUCTION","projectId":"cmj8vz5uj00050826v0tlsx79","runId":"cmj9l0x2q000m2531jrl18ha4","image":"docker.io/maceinnovations/proj_...","machine": {"name":"small-1x","cpu":0.5,"memory":0.5}// NOTE: No "env" or "variables" field present!  }}

Expected: Theopts object should include anenv orvariables field with the decrypted environment variables.

4. Runner Pods Have NO Environment Variables

Verified by inspecting a running runner pod:

kubectlexec -n trigger<runner-pod> -- env| grep SUPABASE# Result: No output - variables not present

5. Task Fails Immediately

Runner pod status:

Status: FailedRestarts: 5+Exit Code: 1

Task error logs confirm missing environment variables cause immediate failure.

Root Cause Analysis

The/engine/v1/worker-actions/dequeue endpoint in the webapp appears to NOT include environment variables in its response to the supervisor. The response includes:

• ✅ Environment ID (envId)
• ✅ Environment type (envType)
• ✅ Project ID
• ✅ Run metadata
• ❌ Environment variables (env orvariables field)

Since the supervisor receives no environment variables from the dequeue endpoint, it cannot inject them into runner pods.

Webapp Configuration Verified

All required webapp environment variables are properly configured:

webapp:env:    -ENCRYPTION_KEY:<32-hex-chars># For decrypting secrets    -DATABASE_URL:postgresql://...# For database access    -DIRECT_URL:postgresql://...# For migrations    -SESSION_SECRET:<generated>    -MAGIC_LINK_SECRET:<generated>

Supervisor Configuration

Supervisor does NOT have direct database access (by design):

• NoDATABASE_URL environment variable
• NoENCRYPTION_KEY environment variable
• Relies on webapp's dequeue endpoint to provide environment variables

This is the expected architecture - the supervisor should receive environment variables from the webapp via the dequeue endpoint.

Comparison with Cloud Version

In Trigger.dev Cloud, environment variables configured in the portal work correctly. This suggests the issue is specific to the self-hosted v4.0.4 implementation.

Checked for Existing Issues

Searched GitHub issues and found no existing reports of this problem:

• No issues mentioning "environment variables not injected"
• No issues about dequeue endpoint and environment variables
• No issues about self-hosted v4 environment variable problems

Potential Causes

1. Bug in v4.0.4 dequeue endpoint: The endpoint may not be fetching environment variables from the database
2. Missing feature in self-hosted version: Environment variable injection may not be implemented in self-hosted v4.0.4
3. Missing configuration: There may be an undocumented configuration flag required to enable this feature

Attempted Workarounds (Not Acceptable)

These workarounds would bypass the portal configuration system and prevent per-project, per-environment variable management:

• ❌ Adding env vars to Helmworker.extraEnvVars
• ❌ Usingkubectl patch to inject env vars
• ❌ Creating manual Kubernetes secrets

Questions

1. Is environment variable injection from the portal supported in self-hosted v4.0.4?
2. If yes, is there a configuration option we're missing?
3. Should the dequeue endpoint include environment variables in its response?
4. Has this been fixed in a newer version?

Helm Chart Verification

Checked for newer versions:

helm show chart oci://ghcr.io/triggerdotdev/charts/trigger --version"~4.0.0"# Result: version 4.0.5 (appVersion v4.0.4) is the latest

No newer chart versions available as of December 17, 2025.

Request

Please confirm whether this is:

1. A bug that needs to be fixed
2. A missing feature in self-hosted deployments
3. A configuration issue with documentation needed

If this is a bug, we're happy to test a fix or newer version. We have a full reproduction environment available.

Additional Context

• Tasks run successfully when using environment variables from the local.env file in dev mode
• The issue only occurs with portal-configured environment variables in deployed tasks
• All other Trigger.dev functionality works correctly (deployments, dashboard, runs tracking)
• Network connectivity, database connections, and Runs Replication Service all verified working

Related Documentation:

• Environment Variables
• Self-hosting Kubernetes
• Webapp Environment Variables
• Supervisor Environment Variables