LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT are not initialized until Superuser login (Blocking Backend-only deployments)

[Hyedryn]

Bug Description

Description

When running Langflow (v1.7.1) in a Kubernetes environment using langflow-runtime k8s helm charts, Global Variables defined via the LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT environment variable are not accessible via the API after container startup.

Requests made using a valid LANGFLOW_API_KEY fail because the variables are not found in the database. The variables only become available/active after a Superuser explicitly logs in via Swagger docs (or the UI if enabled). Once this login event occurs, subsequent API Key requests work correctly.

This behavior blocks "headless" or backend-only deployments where no human interaction with the UI is expected.

System Information

• Langflow Version: 1.7.1
• Deployment Method: Helm Chart (langflow-runtime) on Kubernetes
• Python Version: 3.12
• Database: SQLite (Ephemeral/emptyDir - database is fresh on every pod start)

Environment Configuration

The pod is configured with the following environment variables:

LANGFLOW_AUTO_LOGIN="false"
LANGFLOW_API_KEY="sk-..." # Valid API Key
LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT="AZURE_API_KEY"
AZURE_API_KEY="<actual_value>"

Workaround

I am currently forcing a "wake up" of the variables by adding a postStart hook or a sidecar script that waits for the service to be ready and then performs a curl POST /api/v1/login request. This is not ideal for production.

Reproduction

Steps to Reproduce

1. Deploy Langflow with an ephemeral SQLite database (fresh state).
2. Configure LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT to sync a variable (e.g., AZURE_API_KEY).
3. Wait for the pod to reach Running state.
4. Attempt 1 (Fail): Immediately try to list variables using the API Key:

   curl -X GET "http://<host>:7860/api/v1/variables" \
        -H "x-api-key: <your-api-key>"

   Result: Returns [] (Empty list). Flows using these variables fail.
5. Intervention: Perform a login request via Swagger or curl using Superuser credentials:

   curl -X POST "http://<host>:7860/api/v1/login" \
        -d "username=<user>&password=<pass>" ...

6. Attempt 2 (Success): Retry the API Key request from Step 4.
   Result: Returns [{"name": "AZURE_API_KEY", ...}]. Flows now work.

Expected behavior

Expected Behavior

Variables defined in LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT should be synchronized from the OS environment to the database during the application startup process, ensuring they are available for API-based execution immediately, without requiring a User Session or Login event.

Actual Behavior

The variables are not synchronized on startup. It appears the synchronization logic is triggered only upon the first successful user authentication/login event. Since the database is fresh (ephemeral), the variables table is empty until this event triggers.

Who can help?

@italojohnny

Operating System

Docker image langflow/langflow:1.7.1 running inside a k8s cluster (deployed using https://github.com/langflow-ai/langflow-helm-charts)

Langflow Version

1.7.1

Python Version

3.12

Screenshot

No response

Flow File

No response

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• Global variables not updating after environment variables change #8580

👤 Suggested Assignees

• smn-snkl

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[AntonioABLima]

Hi @Hyedryn ,

Thank you for bringing this up and for the detailed observation.

You are absolutely correct. The behavior you described, where variables are initialized from environment variables into the Secret storage (like Kubernetes) — is indeed how the current VariableService was implemented. This isn't exclusive to Kubernetes; it's a structural design choice in how Langflow handles the synchronization between the host environment and the user-specific storage.

I have just created an internal feature request ticket (LFOSS-3176) to review and improve this mechanism.