Skip to main content
Version: 1.13.x (Next)

API keys and authentication

This page documents Langflow's built-in authentication, including user accounts, Langflow API keys, and the environment variables that control access to your server. To connect Langflow to an external identity provider or SSO system, see SSO and external authentication.

warning

Never expose Langflow ports directly to the internet without proper security measures. Set LANGFLOW_AUTO_LOGIN=False, use a non-default LANGFLOW_SECRET_KEY, and deploy your Langflow server behind a reverse proxy with authentication enabled. For more information, see Start a Langflow server with authentication enabled.

Authentication credentials help prevent unauthorized access to your Langflow server, flows, and services connected through components.

There are three types of credentials that you use in Langflow:

  • Langflow API keys: For authentication with the Langflow API and authorizing server-side Langflow actions like running flows and uploading files.
  • Component API keys: For authentication between Langflow and a service connected through a component, such as a model provider or third-party API.
  • Authentication environment variables: These environment variables configure how Langflow handles user authentication and authorization.

Langflow API keys​

You can use Langflow API keys to interact with Langflow programmatically.

By default, most Langflow API endpoints, such as /v1/run/$FLOW_ID, require authentication with a Langflow API key.

Langflow validates API keys against keys stored in the database, but you can configure Langflow to validate API keys against an environment variable instead. For more information, see LANGFLOW_API_KEY_SOURCE.

Webhook endpoints require API key authentication by default. To disable authentication for webhook endpoints, use the LANGFLOW_WEBHOOK_AUTH_ENABLE environment variable. To configure authentication for Langflow MCP servers, see Use Langflow as an MCP server.

Langflow API key permissions​

A Langflow API key adopts the privileges of the user who created it. This means that API keys you create have the same permissions and access that you do, including access to your flows, components, and Langflow database. A Langflow API key cannot be used to access resources outside of your own Langflow server.

In single-user environments, you are always a superuser, and your Langflow API keys always have superuser privileges.

In multi-user environments, users who aren't superusers cannot use their API keys to access other users' resources. Superusers can only run their own flows, and cannot run flows owned by other users. You must start your Langflow server with authentication enabled to allow superusers to manage users and create non-superuser accounts.

Create a Langflow API key​

You can generate a Langflow API key in your Langflow Settings or with the Langflow CLI.

The CLI option is required if your Langflow server is running in --backend-only mode.

  1. In the Langflow header, click your profile icon, and then select Settings.
  2. Click Langflow API Keys, and then click Add New.
  3. Name your key, and then click Create API Key.
  4. Copy the API key and store it securely.

Use a Langflow API key​

To authenticate Langflow API requests, pass your Langflow API key an x-api-key header or query parameter.

curl -X POST \
  "http://$LANGFLOW_SERVER_ADDRESS/api/v1/run/$FLOW_ID?stream=false" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $LANGFLOW_API_KEY" \
  -d '{"inputs": {"text":""}, "tweaks": {}}'

For more information about forming Langflow API requests, see Get started with the Langflow API and Trigger flows with the Langflow API.

Track API key usage​

By default, Langflow tracks API key usage through total_uses and last_used_at records in your Langflow database.

To disable API key tracking, set LANGFLOW_DISABLE_TRACK_APIKEY_USAGE=True in your Langflow environment variables. This can help avoid database contention during periods of high concurrency.

Revoke an API key​

To revoke and delete an API key, do the following:

  1. In the Langflow header, click your profile icon, and then select Settings.
  2. Click Langflow API Keys.
  3. Select the keys you want to delete, and then click Delete.

This action immediately invalidates the key and prevents it from being used again.

Component API keys​

Component API keys authorize access to external services that are called by components in your flows, such as model providers, databases, or third-party APIs. These aren't Langflow API keys or general application credentials.

In Langflow, you can store component API keys in global variables in your Settings or import them from your runtime environment. For more information, see Global variables.

You create and manage component API keys within the service provider's platform. Langflow only stores the encrypted key value or a secure reference to a key stored elsewhere; it doesn't manage the actual credentials at the source. This means that deleting a global variable from Langflow doesn't delete or invalidate the actual API key in the service provider's system. You must delete or rotate component API keys directly using the service provider's interface or API.

For added security, you can set LANGFLOW_REMOVE_API_KEYS=True to omit API keys and tokens from flow data in your Langflow database. Additionally, when exporting flows, you can choose to omit API keys from the exported flow JSON.

Authentication environment variables​

This section describes the available authentication configuration variables.

You can use the .env.example file in the Langflow repository as a template for your own .env file.

For JWT token signing configuration, including algorithm selection and key management, see Configure JWT token signing.

LANGFLOW_AUTO_LOGIN​

This variable controls whether the visual editor uses automatic login or requires users to sign in.

  • If LANGFLOW_AUTO_LOGIN=False, automatic login is disabled. Users must sign in to the visual editor, authenticate as a superuser to run certain Langflow CLI commands, and use a Langflow API key for Langflow API requests. You must explicitly set LANGFLOW_SUPERUSER_PASSWORD before startup. Set LANGFLOW_SUPERUSER only if you want to override the default superuser username (langflow).

  • If LANGFLOW_AUTO_LOGIN=True, the visual editor automatically signs in all users as the configured superuser, and Langflow uses that username with a configured or generated bootstrap password. All users share the same visual editor environment without password protection, and they can run Langflow CLI commands as superusers. API requests still require a Langflow API key unless you also set LANGFLOW_SKIP_AUTH_AUTO_LOGIN to true.

The Langflow application default is True. Official Langflow Docker images set false. For more information, see Docker image defaults.

LANGFLOW_SKIP_AUTH_AUTO_LOGIN​

When LANGFLOW_AUTO_LOGIN=true, set LANGFLOW_SKIP_AUTH_AUTO_LOGIN=true to also skip API key authentication for API requests. The default is false, so API keys are still required even when auto-login is enabled. This variable will be removed in a future release.

LANGFLOW_ENABLE_SUPERUSER_CLI​

Controls the availability of the langflow superuser command in the Langflow CLI. The default is true, but false is recommended to prevent unrestricted superuser creation. For more information, see langflow superuser.

LANGFLOW_SUPERUSER and LANGFLOW_SUPERUSER_PASSWORD​

These variables specify the username and password for the Langflow server's superuser.

LANGFLOW_SUPERUSER=administrator
LANGFLOW_SUPERUSER_PASSWORD=securepassword

LANGFLOW_SUPERUSER_PASSWORD is required if LANGFLOW_AUTO_LOGIN=False. LANGFLOW_SUPERUSER is optional and defaults to langflow. LANGFLOW_SUPERUSER_PASSWORD can't use the legacy default value langflow; startup fails closed instead. When LANGFLOW_AUTO_LOGIN=True, LANGFLOW_SUPERUSER selects the auto-login account username and LANGFLOW_SUPERUSER_PASSWORD is optional. If the password isn't set, Langflow generates an unknown bootstrap password for the auto-login account.

When you start a Langflow server with authentication enabled, if the required password is not set, then startup fails instead of creating a default password. These defaults don't apply when using the Langflow CLI command langflow superuser.

LANGFLOW_SECRET_KEY​

This environment variable stores a secret key used for encrypting sensitive data like API keys and for JWT signing when using the HS256 algorithm. Langflow uses the Fernet library for secret key encryption. For JWT-specific configuration, see Configure JWT token signing.

If no secret key is provided, Langflow automatically generates one.

However, you should generate and explicitly set your own key in production environments. This is particularly important for multi-instance deployments like Kubernetes to ensure consistent encryption across instances.

To generate a secret encryption key for LANGFLOW_SECRET_KEY, do the following:

  1. Run the command to generate and copy a secret to the clipboard.

    • macOS: Generate a secret key and copy it to the clipboard:

      python3 -c "from secrets import token_urlsafe; print(f'LANGFLOW_SECRET_KEY={token_urlsafe(32)}')" | pbcopy

    • Linux: Generate a secret key and copy it to the clipboard:

      python3 -c "from secrets import token_urlsafe; print(f'LANGFLOW_SECRET_KEY={token_urlsafe(32)}')" | xclip -selection clipboard

    • Unix: Generate a secret key and print it to the terminal to manually copy it:

      python3 -c "from secrets import token_urlsafe; print(f'LANGFLOW_SECRET_KEY={token_urlsafe(32)}')"

  2. Paste the value into your .env file:

    LANGFLOW_SECRET_KEY=dBuu...2kM2_fb

    If you're running Langflow on Docker, reference the LANGFLOW_SECRET_KEY from your .env file in the docker-compose.yml file like this:

    environment:
      - LANGFLOW_SECRET_KEY=${LANGFLOW_SECRET_KEY}

Rotate the secret key​

Rotate LANGFLOW_SECRET_KEY if the key might have been compromised and as part of your routine credential management practices. Langflow provides a migration script that re-encrypts stored credentials and other sensitive data with a new key so you can rotate without losing access.

For more information, see Secret Key Rotation in the Langflow Security Policy.

LANGFLOW_NEW_USER_IS_ACTIVE​

When LANGFLOW_NEW_USER_IS_ACTIVE=False (default), new accounts are inactive until a superuser activates them with the Users API. Inactive users cannot sign in to the visual editor. The superuser can also deactivate an account with the same API.

When LANGFLOW_NEW_USER_IS_ACTIVE=True, new accounts are automatically activated.

LANGFLOW_NEW_USER_IS_ACTIVE=False

Only superusers can manage user accounts for a Langflow server through the Users API. For more information, see Start a Langflow server with authentication enabled.

LANGFLOW_ENABLE_SIGNUP​

This variable controls whether public self-registration is allowed at the POST /api/v1/users/ endpoint.

ValueDescription
True (default)Anyone can create a new Langflow account by calling the registration endpoint directly.
FalsePublic registration is disabled. Only superusers can create new accounts with the Users API.

Self-registration is always disabled when LANGFLOW_AUTO_LOGIN=True, because single-user mode has no multi-account concept. Superusers can create accounts regardless of this setting.

LANGFLOW_API_KEY_SOURCE​

This variable controls how Langflow validates API keys.

ValueDescription
db (default)Validates API keys against Langflow API keys stored in the database. This is the standard behavior where users create and manage API keys through the Langflow UI or CLI.
envValidates API keys against the LANGFLOW_​API_​KEY environment variable. Useful for Kubernetes deployments, CI/CD pipelines, or any environment where you want to inject a pre-defined API key without database configuration.

By default, Langflow validates the x-api-key header against the Langflow database with LANGFLOW_API_KEY_SOURCE=db. When using database-based validation, you can create multiple keys with per-user permissions, track usage, and manage keys through the Langflow UI or CLI.

When LANGFLOW_API_KEY_SOURCE=env, Langflow validates the x-api-key header against the value of the LANGFLOW_API_KEY environment variable. This means Langflow runs securely in stateless environments, such as with LFX or Kubernetes secrets.

When LANGFLOW_API_KEY_SOURCE=env, only a single API key can be used for the deployment. All authenticated requests use the same API key, and successful authentication grants superuser privileges. This mode is designed for single-tenant deployments or automated systems, not multi-user environments where different users need different access levels. To rotate your keys, update the environment variable and restart the Langflow server.

To enable environment-based API key validation:

  1. In the Langflow .env file, set the API key source to env:

    LANGFLOW_API_KEY_SOURCE=env

  2. In the Langflow .env file, set the API key value:

    LANGFLOW_API_KEY=your-secure-api-key

  3. Use the API key in your requests:

    curl -X POST \
      "http://LANGFLOW_SERVER_ADDRESS/api/v1/run/FLOW_ID?stream=false" \
      -H "Content-Type: application/json" \
      -H "x-api-key: LANGFLOW_API_KEY" \
      -d '{"inputs": {"text":""}, "tweaks": {}}'

    Replace LANGFLOW_SERVER_ADDRESS, FLOW_ID, and LANGFLOW_API_KEY with the values from your deployment.

Kubernetes deployment example

To configure an environment-based API key in a Kubernetes Secret, do the following:

  1. Create a Kubernetes Secret with your API key:

    apiVersion: v1
    kind: Secret
    metadata:
      name: langflow-api-key
    type: Opaque
    stringData:
      api-key: "YOUR_API_KEY"

    Replace YOUR_API_KEY with the LANGFLOW_API_KEY value from the Langflow .env file.

  2. Reference the langflow-api-key Secret in your Kubernetes deployment:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: langflow
    spec:
      template:
        spec:
          containers:
          - name: langflow
            image: langflowai/langflow:latest
            env:
            - name: LANGFLOW_API_KEY_SOURCE
              value: "env"
            - name: LANGFLOW_API_KEY
              valueFrom:
                secretKeyRef:
                  name: langflow-api-key
                  key: api-key
Docker Compose example

To configure an environment-based API key in Docker Compose, do the following:

  1. Set the API key in your Langflow .env file.

    LANGFLOW_API_KEY=your-secure-api-key

    Replace YOUR_API_KEY with your actual Langflow API key value.

  2. Create or update your docker-compose.yml file to set LANGFLOW_API_KEY_SOURCE=env and reference the LANGFLOW_API_KEY.

    services:
      langflow:
        image: langflowai/langflow:latest
        environment:
          - LANGFLOW_API_KEY_SOURCE=env
          - LANGFLOW_API_KEY=${LANGFLOW_API_KEY}
        ports:
          - "7860:7860"

LANGFLOW_CORS_*​

Cross-Origin Resource Sharing (CORS) configuration controls how authentication credentials are handled when your Langflow frontend and backend are served from different origins. The following LANGFLOW_CORS_* environment variables are available:

VariableFormatDefaultDescription
LANGFLOW_​CORS_​ALLOW_​CREDENTIALSBooleanTrueWhether to allow credentials, such as cookies and authorization headers, in CORS requests.
LANGFLOW_​CORS_​ALLOW_​HEADERSList[String] or String*The allowed headers for CORS requests. Provide a comma-separated list of headers or use * to allow all headers.
LANGFLOW_​CORS_​ALLOW_​METHODSList[String] or String*The allowed HTTP methods for CORS requests. Provide a comma-separated list of methods or use * to allow all methods.
LANGFLOW_​CORS_​ORIGINSString*The allowed CORS origins. Provide a comma-separated list of origins or use * for all origins.

The default configuration enables CORS credentials and uses wildcards (*) to allow all origins, headers, and methods:

LANGFLOW_CORS_ORIGINS=*
LANGFLOW_CORS_ALLOW_CREDENTIALS=True
LANGFLOW_CORS_ALLOW_HEADERS=*
LANGFLOW_CORS_ALLOW_METHODS=*
danger

Langflow's default CORS settings can be a security risk in production environments because any website can make requests to your Langflow API, and any website can include credentials in cross-origin requests, including authentication cookies and authorization headers.

In production deployments, specify exact origins in LANGFLOW_CORS_ORIGINS. You can also specify allowed headers and methods, if needed. For example:

LANGFLOW_CORS_ORIGINS=["https://yourdomain.com","https://app.yourdomain.com"]
LANGFLOW_CORS_ALLOW_CREDENTIALS=True
LANGFLOW_CORS_ALLOW_HEADERS=["Content-Type","Authorization"]
LANGFLOW_CORS_ALLOW_METHODS=["GET","POST","PUT"]

For a shared or public deployment served over HTTPS, harden the session cookies. Secure and SameSite default to values that support local HTTP development. Both the access and refresh cookies are HttpOnly by default; the browser sends them automatically with requests.

Set both LANGFLOW_ACCESS_SECURE and LANGFLOW_REFRESH_SECURE to True for HTTPS deployments. Cross-site HTTPS deployments must also set LANGFLOW_REFRESH_SAME_SITE=none.

VariableFormatDefaultDescription
LANGFLOW_​ACCESS_​SECUREBooleanFalseWhen true, the access_​token_​lf cookie is sent only over HTTPS. Recommended true for any HTTPS deployment.
LANGFLOW_​ACCESS_​HTTPONLYBooleanTrueWhen true, the access_​token_​lf cookie is not readable by JavaScript. Set to false only if a client must read this cookie in JavaScript.
LANGFLOW_​ACCESS_​SAME_​SITEStringlaxThe SameSite attribute of the access-token cookie (lax, strict, or none).
LANGFLOW_​REFRESH_​SECUREBooleanFalseWhen true, the refresh_​token_​lf cookie is sent only over HTTPS. Set this to true for any HTTPS deployment.
LANGFLOW_​REFRESH_​HTTPONLYBooleanTrueWhen true, the refresh_​token_​lf cookie is not readable by JavaScript.
LANGFLOW_​REFRESH_​SAME_​SITEStringlaxThe SameSite attribute of the refresh-token cookie (lax, strict, or none).
LANGFLOW_​COOKIE_​DOMAINStringNot setDomain attribute for the access and refresh cookies. Leave unset for host-only cookies. Set to a parent domain, such as .example.com, when the frontend and API are on different subdomains.

Anonymous public-flow authorization​

Anonymous public-flow links are direct-link capabilities, not discovery grants. Langflow accepts a canonical PUBLIC authorization share and preserves existing links derived from Flow.access_type=PUBLIC or an A2A folder with auth_type=none. Public shares never appear in general flow or shared-with-me listings.

A canonical PUBLIC share takes precedence over both compatibility grants. For flows, the shares API accepts only permission_level=execute at PUBLIC scope; execution includes the scrubbed direct-link read needed to load the playground. The API rejects read, write, and admin because there is no read-only, writable, or administrative anonymous flow surface. Deleting the share row removes the canonical grant and any still-set legacy setting becomes the effective grant again, so revoke access entirely by clearing the legacy setting as well.

An anonymous link grants only resource read and flow execution. It never grants create, write, delete, deploy, or administration actions, and callers cannot submit flow data or component tweaks. Public execution uses a stable non-user principal, so owner credentials, variables, files, and knowledge bases are unavailable unless a dependency has its own public authorization path. Errors are sanitized, and A2A HITL resumes recheck the current grant. Revocation blocks subsequent starts and resumes; it does not terminate work that is already running.

When LANGFLOW_AUTHZ_ENABLED=true, anonymous access also requires an authorization plugin that opts into public principals, maps request hosts through a deployment-owned allowlist, resolves a tenant from that mapping and server-derived domain context, and allows the action. The OSS public-principal plugin seam defaults to deny and never performs cross-tenant discovery. Plugins must not treat the raw Host header as a trusted tenant identity.

For A2A, auth_type=none applies this contract to both the direct agent card and execution routes. API-key and OAuth agent cards remain anonymously readable by direct link for A2A protocol discovery, but their JSON-RPC execution routes retain owner-key admission and owner execution.

LANGFLOW_RATE_LIMIT_*​

The following environment variables configure IP-based rate limiting to protect against brute-force attacks on the /login endpoint and abuse of public flow endpoints. When the limit is exceeded, Langflow returns HTTP 429 with a Retry-After: 60 header.

VariableFormatDefaultDescription
LANGFLOW_​RATE_​LIMIT_​ENABLEDBooleanTrueEnable rate limiting on the /login and /api/v2/workflows/public endpoints. Set to False to disable those limits (not recommended in production).
LANGFLOW_​RATE_​LIMIT_​PER_​MINUTEInteger5Maximum number of login attempts allowed per minute from a single IP address.
LANGFLOW_​RATE_​LIMIT_​STORAGE_​URIStringmemory://Storage backend for rate limit counters. Use memory:// for single-server deployments or redis://host:port for multi-server deployments where the limit should be shared across instances.
LANGFLOW_​RATE_​LIMIT_​TRUST_​PROXYBooleanFalseWhen true, Langflow reads the client IP from the rightmost X-Forwarded-For header entry instead of the direct connection IP. Enable only when Langflow is behind a trusted reverse proxy or load balancer. Do not enable if users can reach Langflow directly, as this allows header spoofing.
LANGFLOW_​PUBLIC_​FLOW_​RATE_​LIMIT_​PER_​MINUTEInteger20Maximum number of unauthenticated public-flow runs allowed per minute from a single IP address. Public flows consume resources under an isolated anonymous principal, so they are rate-limited separately from the /login endpoint.

LANGFLOW_SSRF_* and LANGFLOW_CONNECTOR_SSRF_*​

The following environment variables configure Server-Side Request Forgery (SSRF) protection for the API Request component and for connector components that take a tenant-controlled host or URL. SSRF protection prevents requests to internal or private network resources, such as private IP ranges, loopback addresses, and cloud metadata endpoints.

In a shared server where users you do not fully trust can build flows, set LANGFLOW_CONNECTOR_SSRF_VALIDATION_ENABLED=true, LANGFLOW_SSRF_PROTECTION_ENABLED=true, and LANGFLOW_CONNECTOR_SSRF_ALLOW_LOOPBACK=false, and then allowlist your own internal hosts with LANGFLOW_SSRF_ALLOWED_HOSTS.

VariableFormatDefaultDescription
LANGFLOW_​SSRF_​PROTECTION_​ENABLEDBooleanTrueEnable SSRF protection for the API Request component. When enabled, the component blocks requests to private IP addresses. When disabled, requests are not blocked.
LANGFLOW_​SSRF_​ALLOWED_​HOSTSList[String]Not setA comma-separated list of allowed hosts, IP addresses, or CIDR ranges that can bypass SSRF protection checks. For example: 192.168.1.0/24,10.0.0.5,*.internal.company.local.
LANGFLOW_​CONNECTOR_​SSRF_​VALIDATION_​ENABLEDBooleanTrueApply SSRF host validation to connector components that take a tenant-controlled host or URL. Uses LANGFLOW_​SSRF_​PROTECTION_​ENABLED and LANGFLOW_​SSRF_​ALLOWED_​HOSTS for the host policy. Set to false, or allowlist specific hosts, only when a trusted single-tenant deployment intentionally connects to private-network services.
LANGFLOW_​CONNECTOR_​SSRF_​ALLOW_​LOOPBACKBooleanTrueWhen connector SSRF validation is enabled, allow literal loopback hosts (localhost, 127.0.0.0/8, ::1) and local Redis/MongoDB Unix sockets. Multi-tenant deployments where a tenant must not reach the server's loopback should set this to false.
LANGFLOW_​KB_​ALLOWED_​HOSTSList[String]Not setAn exclusive allowlist of destination hosts for the network knowledge base backends (OpenSearch and Chroma Cloud). Accepts the same patterns as LANGFLOW_​SSRF_​ALLOWED_​HOSTS. Unlike that variable, which is an exception list that still admits any unlisted public host, this one denies by default: a destination a user supplies is refused unless its host is listed here. A destination Langflow reads from a server environment variable is already operator-controlled and does not need an entry, so setting OPENSEARCH_​URL on the server keeps working unchanged. Chroma Cloud's default host is also unaffected. See the note below.

Connector validation covers Cassandra, MongoDB, Redis vector store, PGVector, Couchbase, Valkey, Supabase, and the other vector stores and tools listed above. Private service names in container networks (for example, redis, mongo, or postgres resolving to 172.x addresses) require an entry in LANGFLOW_SSRF_ALLOWED_HOSTS. MongoDB and Couchbase SRV targets are checked by their own hostnames; allowlisting only the seed name does not cover those targets. For a single Couchbase DNS seed with an explicit port, validation checks both the seed and any SRV targets. Allowlist the target names with a wildcard such as *.cluster.internal, or their address range with a CIDR.

Use commas to separate Couchbase bootstrap hosts. With connector SSRF validation enabled, semicolons in the Couchbase connection-string authority are rejected because the SDK can interpret them as part of a DNS hostname.

In 1.12.4, PGVector connections to localhost or 127.0.0.1 are blocked by default, matching the SQL Database components. To keep a trusted local PGVector flow working, set LANGFLOW_SSRF_ALLOWED_HOSTS=localhost (and include 127.0.0.1 if used). Connector checks validate bootstrap addresses, but MongoDB, Redis Sentinel, Couchbase, and Valkey clients can discover additional peers after connecting or resolve a validated name again. Use network egress controls to prevent those clients from reaching internal services.

Model provider endpoints​

Custom model provider endpoints require HTTPS unless the operator explicitly permits HTTP through LANGFLOW_SSRF_ALLOWED_HOSTS. This allowlist accepts bare hostnames, IP addresses, *.domain wildcards, and CIDR ranges, without schemes or ports. For a URL containing an IP address, a covering CIDR grants the HTTP exception: for example, 172.16.0.0/12 permits http://172.17.0.3:8080/v1. For a DNS hostname, use its name or a wildcard; the HTTPS check does not resolve hostnames to match CIDRs.

An API key sourced from the server environment also requires the custom destination to be approved in LANGFLOW_PROVIDER_CREDENTIAL_ALLOWED_HOSTS. That separate allowlist accepts bare hosts, host:port, and *.domain wildcards, but not CIDRs. Prefix an entry with http:// to explicitly permit sending that credential over HTTP. For example, a trusted internal gateway at http://172.17.0.3:8080/v1 using a server-provisioned key needs both settings:

export LANGFLOW_SSRF_ALLOWED_HOSTS=172.16.0.0/12
export LANGFLOW_PROVIDER_CREDENTIAL_ALLOWED_HOSTS=http://172.17.0.3:8080

Knowledge base destinations​

The OpenSearch and Chroma Cloud knowledge base backends need a stricter rule than the other connectors.

The SSRF variables above validate a hostname and then hand the original URL to a vendor SDK, which resolves DNS again when it connects. For the API Request component Langflow closes that gap by pinning the validated IP address, but neither knowledge base SDK exposes a place to do that: chromadb builds its own HTTP client inside CloudClient and connects while the client is still being constructed, and OpenSearchVectorSearch passes one set of arguments to both its synchronous and asynchronous clients, so a single pinned transport cannot serve both. A hostname whose DNS answer changes between validation and connection can therefore still reach an internal address.

LANGFLOW_KB_ALLOWED_HOSTS closes that by requiring the destination to be one you chose:

export LANGFLOW_KB_ALLOWED_HOSTS=search.corp.example,*.opensearch.internal

A destination is permitted when either of the following is true:

  • Langflow read it from a server environment variable, such as OPENSEARCH_URL set on the server process. Only an operator can set one, so no allowlist entry is needed.
  • Its host appears in LANGFLOW_KB_ALLOWED_HOSTS.

Everything else is refused, including hosts that resolve to ordinary public addresses. A cluster URL a user saved as a Langflow variable in the UI, and a cloud_host sent in a request body, both need an entry. Chroma Cloud's fixed default host, api.trychroma.com, takes no user input and is always permitted.

This is a second check rather than a replacement: an approved host must still satisfy LANGFLOW_SSRF_PROTECTION_ENABLED and LANGFLOW_SSRF_ALLOWED_HOSTS, so an environment variable pointing at a cloud metadata address is still refused. Both checks share the LANGFLOW_CONNECTOR_SSRF_VALIDATION_ENABLED switch.

Component hardening for untrusted users​

Use these variables when users who can build or run flows on your server should not get host-level code execution, arbitrary file reads, or MCP mounts.

For more information, see Docker image defaults.

VariableFormatDefaultDescription
LANGFLOW_​BLOCK_​CODE_​INTERPRETER_​COMPONENTSBooleanFalseWhen true, blocks execution of any flow containing a built-in arbitrary-code-execution component, including the Python Interpreter, Python REPL/Code tools, Smart Transform, CSV Agent, and code-running agents such as CodeAct, CUGA, and OpenDsStar.
LANGFLOW_​RESTRICT_​LOCAL_​FILE_​ACCESSBooleanTrueBy default, built-in file-reading components, including the File, Directory, JSON/CSV-to-Data, and the CSV Agent, JSON Agent, and OpenAPI Agent can only read and write paths inside the LANGFLOW_​CONFIG_​DIR storage directory. This also blocks sqlite and duckdb dialects in the SQL Database components and local-filesystem Git clones. Security warning: setting this to false allows any user who can build flows to read arbitrary files on the server (including Langflow's own secret keys) through file components and sqlite:////path database URLs. Set it to false only in single-tenant deployments where reading local server files by absolute path is an intentional feature.
LANGFLOW_​DATABASE_​TLS_​FILES_​DIRAbsolute directory pathUnsetDirectory of administrator-provided TLS files that SQL database connector URLs may reference while local file access stays restricted. Only PostgreSQL sslrootcert, sslcert, and sslkey and MySQL/MariaDB ssl_​ca, ssl_​cert, and ssl_​key options are eligible. The referenced file must exist and resolve to a regular file inside this directory; traversal and symlink escapes are rejected. Keep this directory outside tenant-writable storage and mount it read-only.
LANGFLOW_​MCP_​SERVER_​DOCKER_​HARDENINGBooleanFalseWhen true, applies a strict Docker-argument policy to MCP stdio servers that use the docker transport. Rejects host filesystem or device mounts, host/another-container namespaces, non-default networks, privilege flags, and sandbox-disabling --security-opt values. Forms such as --network none / bridge and --security-opt no-new-privileges remain allowed.
LANGFLOW_​TWEAKS_​POLICYStringpermissiveWhich component fields a run request may set through tweaks. For more information, see Restrict API tweaks.

With the default LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS=true, SQL Database URLs using mysql+mysqlconnector:// must include allow_local_infile=false, and URLs using mariadb+mariadbconnector:// must include local_infile=false. Add the option with ? or append it with & if the URL already has a query string. On a trusted single-tenant server, setting LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS=false restores the prior URL behavior but also permits flows to access local server files.

For a database that requires a local CA certificate, stage the file in a directory managed by the server administrator and set LANGFLOW_DATABASE_TLS_FILES_DIR to that directory. For example, set LANGFLOW_DATABASE_TLS_FILES_DIR=/etc/langflow/db-tls and use postgresql://user:password@db.example.com/app?sslrootcert=/etc/langflow/db-tls/ca.pem. The setting grants all tenants who can supply a database URL access to the staged TLS files through the database driver, including client keys. Stage only files that every such tenant is authorized to use, and do not let tenants write to or replace files in this directory. Other local-file URL options remain blocked, and database host validation still applies when connector SSRF validation is enabled.

Enable these flags when untrusted users can build flows on this server.

The LANGFLOW_ALLOW_CUSTOM_COMPONENTS and LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS flags support two deployment modes. LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false blocks user-authored component code and registered built-in code-execution components at runtime. Set LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true independently when custom components should remain enabled but built-in code execution should be disabled.

To enable these flags, set the following:

  • LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false: blocks user-authored component code and registered built-in code-execution components. See Block custom components.
  • LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true: blocks built-in code-execution components.
  • LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS=true: confines built-in file access to the upload sandbox. This is the default; keep it enabled when untrusted users can build flows.
  • LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true: tightens Docker MCP server arguments.
  • LANGFLOW_TWEAKS_POLICY=declared or off: limits which component fields an API caller can override at run time. See Restrict API tweaks.

To block named built-in components, starter templates, model providers, or models across the install, use the catalog and model policy APIs.

Pair these settings with the SSRF settings to reduce common escape hatches.

These settings do not provide full user isolation. For more information, see Security.

The flags above decide whether code is allowed to run. They do not constrain what it does once it runs, so they are authorization controls rather than an isolation boundary.

To run permitted executions behind a kernel boundary instead of blocking them outright, set a sandbox backend. The built-in exec-sandbox backend runs code in a QEMU microVM on this host. Trusted third-party packages can register other backends.

A sandbox backend covers the Python Interpreter and the legacy Python REPL tool only — the other surfaces listed above still need the blocking flags.

tip

Do not enable a shared tracer when users are untrusted. Instead, use built-in local tracing. External tracing integrations such as Langfuse and Arize are process-wide, not per user, so on a shared server, every user's flow inputs and outputs will go to the same tracing project.

LANGFLOW_WEBHOOK_AUTH_ENABLE​

This variable controls whether API key authentication is required for webhook endpoints.

VariableFormatDefaultDescription
LANGFLOW_​WEBHOOK_​AUTH_​ENABLEBooleanTrueWhen True, webhook endpoints require API key authentication and validate that the authenticated user owns the flow being executed. When False, no Langflow API key is required and all requests to the webhook endpoint are treated as being sent by the flow owner.

By default, webhooks require API key authentication with LANGFLOW_WEBHOOK_AUTH_ENABLE=True.

To allow webhooks to run without authentication (not recommended; use only in trusted environments), in your Langflow .env file, set LANGFLOW_WEBHOOK_AUTH_ENABLE=False.

When webhook authentication is enabled, you must provide a Langflow API key with each webhook request as an HTTP header or query parameter. For more information, see Require authentication for webhooks.

Configure JWT token signing​

Langflow issues short-lived JSON Web Tokens (JWTs) when a user logs in. The default HS256 algorithm works for most deployments. Switch to RS256 or RS512 for production deployments that require asymmetric keys or need to share the public key with other services.

About the JWT structure and contents

When a user logs in at the /api/v1/login endpoint, Langflow validates the credentials and creates a JWT containing the user's identity and expiration time. This token is then used for subsequent API requests instead of sending credentials with each request.

A JWT consists of three parts separated by dots (.):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
  • The header contains the token type and signing algorithm.
  • The payload contains claims — token data for user information and expiration time.
  • The signature ensures the token hasn't been tampered with.

Each part of the JWT is Base64URL-encoded. You can paste this example JWT to decode the actual JSON data at jwt.io.

The following environment variables control JWT signing. LANGFLOW_SECRET_KEY is also used for data encryption and is documented separately in LANGFLOW_SECRET_KEY.

VariableDescriptionDefault
LANGFLOW_​ALGORITHMJWT signing algorithm: HS256, RS256, or RS512HS256
LANGFLOW_​PRIVATE_​KEYRSA private key for RS256/RS512 signingAuto-generated
LANGFLOW_​PUBLIC_​KEYRSA public key for RS256/RS512 verificationDerived from private key
LANGFLOW_​ACCESS_​TOKEN_​EXPIRE_​SECONDSAccess token expiration time3600 (1 hour)
LANGFLOW_​REFRESH_​TOKEN_​EXPIRE_​SECONDSRefresh token expiration time604800 (7 days)

HS256 (default)​

HS256 is the default JWT algorithm, suitable for single-server deployments. Langflow automatically generates and persists a secret key via LANGFLOW_SECRET_KEY. No configuration is necessary beyond what is already covered in the LANGFLOW_SECRET_KEY section above.

To explicitly set the algorithm in your .env:

LANGFLOW_ALGORITHM=HS256
LANGFLOW_SECRET_KEY="your-custom-secret-key"

RS256​

RS256 uses an RSA private/public key pair. The private key signs tokens; the public key verifies them. Use RS256 for production deployments or multi-instance setups where you want to share the public key with other services.

To automatically generate a key pair, set the algorithm and Langflow creates and persists the keys in LANGFLOW_CONFIG_DIR on startup:

LANGFLOW_ALGORITHM=RS256

To supply your own private key (public key is derived automatically):

LANGFLOW_ALGORITHM=RS256
LANGFLOW_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEF...
-----END PRIVATE KEY-----"

To supply a full key pair:

LANGFLOW_ALGORITHM=RS256
LANGFLOW_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEF...
-----END PRIVATE KEY-----"
LANGFLOW_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOC...
-----END PUBLIC KEY-----"

To generate an RSA key pair manually:

  1. Generate a 2048-bit private key:

    openssl genrsa -out private_key.pem 2048

  2. Extract the public key:

    openssl rsa -in private_key.pem -pubout -out public_key.pem

RS512​

RS512 uses the same RSA key format as RS256 but with SHA-512 hashing for greater cryptographic strength. Key generation and configuration follow the same pattern as RS256 — substitute RS512 for RS256 in all the examples above.

Configure Docker and Kubernetes deployments​

Docker with HS256 — for single-server or development deployments:

services:
  langflow:
    image: langflowai/langflow:latest
    environment:
      - LANGFLOW_ALGORITHM=HS256
      - LANGFLOW_SECRET_KEY=${LANGFLOW_SECRET_KEY}
    volumes:
      - langflow_data:/app/langflow
volumes:
  langflow_data:

Docker with RS256 — auto-generated keys (persisted in the volume):

services:
  langflow:
    image: langflowai/langflow:latest
    environment:
      - LANGFLOW_ALGORITHM=RS256
    volumes:
      - langflow_data:/app/langflow
volumes:
  langflow_data:

Docker with RS256 — mount an existing key pair:

services:
  langflow:
    image: langflowai/langflow:latest
    environment:
      - LANGFLOW_ALGORITHM=RS256
    volumes:
      - ./keys/private_key.pem:/app/langflow/private_key.pem:ro
      - ./keys/public_key.pem:/app/langflow/public_key.pem:ro
      - langflow_data:/app/langflow
volumes:
  langflow_data:

Kubernetes with RS256 — store keys as Secrets:

# jwt-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: langflow-jwt-keys
type: Opaque
stringData:
  algorithm: "RS256"
  private-key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvgIBADANBgkqhkiG9w0BAQEF...
    -----END PRIVATE KEY-----
  public-key: |
    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOC...
    -----END PUBLIC KEY-----
---
# langflow-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: langflow
spec:
  template:
    spec:
      containers:
        - name: langflow
          image: langflowai/langflow:latest
          env:
            - name: LANGFLOW_ALGORITHM
              valueFrom:
                secretKeyRef:
                  name: langflow-jwt-keys
                  key: algorithm
            - name: LANGFLOW_PRIVATE_KEY
              valueFrom:
                secretKeyRef:
                  name: langflow-jwt-keys
                  key: private-key
            - name: LANGFLOW_PUBLIC_KEY
              valueFrom:
                secretKeyRef:
                  name: langflow-jwt-keys
                  key: public-key

Configure token expiration​

Access tokens authenticate API requests and typically expire within 15 minutes to 1 hour. Refresh tokens obtain new access tokens without requiring the user to log in again and typically expire within 7 to 30 days. When an access token expires, the client can use the refresh token to get a new one from /api/v1/refresh.

LANGFLOW_ACCESS_TOKEN_EXPIRE_SECONDS=3600    # 1 hour
LANGFLOW_REFRESH_TOKEN_EXPIRE_SECONDS=604800 # 7 days

Start a Langflow server with authentication enabled​

This section shows you how to use the authentication environment variables to deploy a Langflow server with authentication enabled. This involves disabling automatic login, setting superuser credentials, and generating a secret encryption key.

This configuration is recommended for any deployment where Langflow is exposed to a shared or public network, or where multiple users access the same Langflow server.

Docker images

Official Langflow Docker images already set LANGFLOW_AUTO_LOGIN=false. You still must set LANGFLOW_SUPERUSER_PASSWORD (and optionally LANGFLOW_SUPERUSER) before the container can start. For more information, see Docker image defaults.

With authentication enabled, all users must sign in to the visual editor with valid credentials, and API requests require authentication with a Langflow API key. Sign in as a superuser to create a Langflow API key with superuser privileges. User management is through the Users API, not the visual editor.

Start the Langflow server​

  1. Create a .env file with the following variables:

    LANGFLOW_AUTO_LOGIN=False
    LANGFLOW_SUPERUSER=
    LANGFLOW_SUPERUSER_PASSWORD=
    LANGFLOW_SECRET_KEY=
    LANGFLOW_NEW_USER_IS_ACTIVE=False
    LANGFLOW_ENABLE_SIGNUP=False
    LANGFLOW_ENABLE_SUPERUSER_CLI=False

    Your .env file can have other environment variables. This example focuses on authentication variables.

    LANGFLOW_ENABLE_SIGNUP=False restricts account creation to superusers. LANGFLOW_NEW_USER_IS_ACTIVE=False keeps new accounts inactive until you activate them with the Users API.

  2. Set LANGFLOW_SUPERUSER_PASSWORD to your desired superuser password. Optionally set LANGFLOW_SUPERUSER to override the default langflow username.

    For a one-time test, you can use basic credentials like administrator and password. Strong, securely-stored credentials are recommended in genuine development and production environments.

  3. Recommended: Generate and set a LANGFLOW_SECRET_KEY for encrypting sensitive data.

    If you don't set a secret key, Langflow generates one automatically, but this isn't recommended for production environments.

    For instructions on generating and setting a secret key, see LANGFLOW_SECRET_KEY.

  4. Save your .env file with the populated variables. For example:

    LANGFLOW_AUTO_LOGIN=False
    LANGFLOW_SUPERUSER=administrator
    LANGFLOW_SUPERUSER_PASSWORD=securepassword
    LANGFLOW_SECRET_KEY=dBuu...2kM2_fb
    LANGFLOW_NEW_USER_IS_ACTIVE=False
    LANGFLOW_ENABLE_SIGNUP=False
    LANGFLOW_ENABLE_SUPERUSER_CLI=False

  5. Start Langflow with the configuration from your .env file:

    uv run langflow run --env-file .env

    Starting Langflow with this .env file creates or uses the configured superuser. If LANGFLOW_SUPERUSER_PASSWORD isn't set, startup fails instead of creating a default password.

  6. Verify the server is running. The default location is http://localhost:7860.

Next, add users with the Users API so they can collaborate on flows.

Manage users as an administrator​

As of Langflow 1.12, Langflow OSS has no Admin Page in the visual editor. Superusers add, activate, list, and delete users, set Superuser, and set other users' passwords with PATCH /api/v1/users/{id}. For more information, see Users endpoints.

  1. To complete your first-time login as a superuser, navigate to http://localhost:7860/login.

    If you aren't using the default location, replace localhost:7860 with your server's address.

  2. Log in with the password you set in LANGFLOW_SUPERUSER_PASSWORD and the username from LANGFLOW_SUPERUSER. If you did not set LANGFLOW_SUPERUSER, the username is langflow.

  3. Create a Langflow API key while signed in as the superuser. User-management requests require a Langflow API key in the x-api-key header.

  4. Create a user:

    import os

    import requests

    base = os.environ["LANGFLOW_URL"]
    headers = {
        "Content-Type": "application/json",
        "x-api-key": os.environ["LANGFLOW_API_KEY"],
    }
    payload = {
        "username": "newuser",
        "password": "securepassword123",
    }

    response = requests.post(f"{base}/api/v1/users/", headers=headers, json=payload, timeout=30)
    response.raise_for_status()
    print(response.json())

    The response includes the user's id. New accounts are inactive when LANGFLOW_NEW_USER_IS_ACTIVE=False (the default, and the value in the .env example above).

  5. Activate the account so the user can sign in. Replace USER_ID with the id from the create response:

    import os

    import requests

    base = os.environ["LANGFLOW_URL"]
    user_id = "USER_ID"
    headers = {
        "Content-Type": "application/json",
        "x-api-key": os.environ["LANGFLOW_API_KEY"],
    }
    payload = {"is_active": True}

    response = requests.patch(
        f"{base}/api/v1/users/{user_id}", headers=headers, json=payload, timeout=30
    )
    response.raise_for_status()
    print(response.json())

    To grant administrative privileges, include "is_superuser": true in the same request. To reset another user's password, PATCH /api/v1/users/{id} with "password": "<new password>". That path does not require the current password. PATCH /api/v1/users/{id}/reset-password is self-service: it must be called as that user and requires current_password. See Update user. To list, deactivate, or delete a user, see Users endpoints.

  6. Send the username and password to the user. The superuser sets the initial password when creating the account.

  7. To test the new user's access, sign out of Langflow, and then sign in at /login with the new user's credentials. A non-superuser can use the visual editor and cannot call the Users API to manage other accounts.

See also​

Was this page helpful?

Support
Search