Taking a flow to production with tracing

I'd treat the flow JSON as code: commit it to git, with every credential referenced as a global variable. CI builds a Docker image from a pinned Langflow version and adds custom components. At runtime the container gets environment variables from a secrets manager: auto-login off, superuser credentials, a stable secret key, a Postgres database URL, model keys and tracing keys. It sits behind a reverse proxy for TLS and rate limiting. Callers use POST /api/v1/run with an x-api-key from a service user, only from our backend, and I restrict which tweaks they can pass. Finally, tracing to LangSmith or Langfuse plus latency and error alerts give us visibility, and we promote the same image from staging to production.

With auto-login on, Langflow treats every visitor as an already-logged-in superuser. That is convenient on a laptop but dangerous on a network. Anyone who reaches the UI or API could edit flows, read global variables and run anything. Setting LANGFLOW_AUTO_LOGIN=False turns authentication on. You then supply superuser credentials through environment variables, people must log in to the editor, and API calls must carry a valid key. It is the single setting that turns a local toy into a service you can put behind a proxy. I also check it in CI or at startup, so a misconfigured image fails fast instead of quietly going live with an open run endpoint.

A key pasted into a component field becomes part of the flow's saved state. When you export the flow as JSON and commit it, that key ends up in git history, code review, backups and anyone's clone. Global variables keep the secret outside the flow: the component stores only a reference to a variable name. In production, that variable gets its value from an environment variable that the secrets manager injects. The same flow file then works in dev, staging and prod with different keys, and rotating a key never touches the flow. I also add a CI check that scans exported JSON for key-like strings, so a mistake is caught before merge.

Keys should never be part of component inputs in the first place:<br><ul><li>Models read credentials from global variables backed by environment variables, so the key is configuration, not data flowing through the graph.</li><li>I review custom components so they never echo headers, environment values or credentials into outputs.</li><li>I forbid tweaks that could inject a key or override an endpoint.</li><li>Tracing keys sit only in the container environment.</li></ul>For user data, I classify what the flow handles and decide whether full prompts may be traced at all. Options include redacting or masking fields before the model step, restricting trace project access, and setting retention. Finally, I test this: run a flow and search the trace and logs for known secret patterns.

First I check the metrics to scope it: is it one flow or all, did it start with a deploy, and are errors rising too? If it lines up with a release, I compare traces before and after on the same image version history. Then I open slow traces in LangSmith or Langfuse and look at per-component timings. Usually the culprit is the model call, a slow vector store query, a tool or agent loop making extra calls, or a long message history inflating prompts. Token counts in the trace show prompt growth. Depending on the cause I'd trim history, cap agent iterations, add timeouts, switch to a faster model or scale replicas, and roll back the image if needed.

There are two kinds. Inbound keys are Langflow API keys that callers send in the x-api-key header; I create them for a dedicated service user, keep them only in backend services, and rotate or revoke them per consumer. Outbound secrets are model provider, vector store and tracing keys; I store them in a secrets manager and inject them as environment variables, loading them into Langflow global variables so flow JSON never contains them. LANGFLOW_SECRET_KEY must be stable and backed up, because it encrypts stored credentials. I also make sure traces and logs don't capture keys or sensitive user data, and keep the UI off the public internet.

Langflow uses the secret key for cryptographic work such as encrypting stored credentials, including global variable values, and signing auth tokens. Every replica that shares the same PostgreSQL database must use the same key. If one replica has a different key, it cannot decrypt secrets the others wrote, and tokens issued by one replica fail on another. Users see random authentication or decryption errors depending on which pod served them. If the key is lost, the encrypted values in the database become unreadable and must be re-entered. So the key lives in the secrets manager, is injected identically into all replicas, and is rotated only through a planned migration.

I start FROM the official Langflow image at a pinned version tag, never latest, so builds are reproducible and upgrades happen on purpose. Next I install extra Python dependencies from a lock file, copy reviewed custom component code into the components path, and optionally copy the exported flow JSON so it loads at startup. The image contains no secrets; everything sensitive arrives at runtime as environment variables. CI then runs a smoke test. It starts the container with test config, waits for /health, and calls the run endpoint with a test key and a known input. Finally it scans the image for vulnerabilities and tags it immutably, for example with the git commit SHA, so a rollback just means redeploying an earlier tag.

The proxy handles these jobs:<br>1. It terminates TLS, so clients only ever talk HTTPS.<br>2. It enforces request body size limits, so huge payloads never reach the Python process.<br>3. It applies rate limits per caller, ideally keyed on the API key or client identity.<br>4. It writes structured access logs with status, latency and a request ID.<br>5. It can hide paths that should not be public, such as the editor UI, or allow only the run and health endpoints.<br>Langflow is an application server, not an edge gateway. Pushing these concerns to the edge rejects abuse cheaply, before it uses worker capacity. It also keeps the policy in one place across replicas and gives you consistent latency data. I make sure the proxy redacts the x-api-key header from its logs.

I create a dedicated service user rather than using the superuser, then generate keys under that user, ideally one key per calling application. Each key goes into the caller's own secrets store. Per-caller keys give you per-caller rate limits, attribution in logs, and the ability to revoke one client without breaking the others. Rotation is overlap-based:<br>1. Create a new key.<br>2. Deploy it to the caller.<br>3. Confirm traffic shows the new key in use.<br>4. Revoke the old one.<br>On suspected compromise, I revoke immediately and accept a short outage for that one caller. Revoked or missing keys are rejected before any component runs, so a leaked key stops costing model tokens the moment it is revoked.

Both integrate with Langflow through environment variables and record per-run traces with component inputs, outputs, timing and token usage. So the choice is mostly organisational:<br><ul><li>Langfuse is open source and can be self-hosted. That matters when data residency or privacy rules say prompts and outputs must stay in your own infrastructure.</li><li>LangSmith is a managed service closely tied to the LangChain ecosystem. It suits teams already using it for evaluation and datasets.</li></ul>I would weigh where trace data may legally live, retention controls, access control for who can read traces, existing team tooling, and operational effort. Whichever you pick, treat trace storage as sensitive data, because traces contain user prompts and model outputs.

Message history is stored in Langflow's database, keyed by session ID. If all replicas share one PostgreSQL database, any replica can serve any turn of a conversation. Replica one writes the history, replica two reads it on the next request, and you do not need sticky sessions. With local SQLite per container, history would split across replicas and the bot would seem to forget context. The caller must send a stable, unguessable session ID per conversation. Session IDs should be scoped per user, so one caller cannot read another's history by guessing IDs. You also need a retention policy, because history tables grow with every message and may contain personal data.

I use Little's law: concurrent in-flight requests equal arrival rate times average duration. Most of a run's time is spent waiting on the model provider and vector store. So I measure real p50 and p95 run duration from traces, take peak requests per second from the access logs, and multiply to get the concurrency to hold. Then I load-test one container to find how many concurrent runs it serves before latency degrades or memory climbs. Dividing gives a replica count, and I add headroom for failover and spikes. I also check the external limits: provider rate and token quotas, vector store throughput and database connections. These often cap throughput before Langflow CPU does.

First, make failures visible: traces show which model component failed and how long it waited, and 5xx and timeout metrics alert on it. For transient errors such as rate limits, retry with backoff and a cap so retries do not amplify the overload. For sustained outages, options include a fallback model path in the flow, or failing fast with a clear error the client can handle. Hanging is the worst outcome. Capacity-wise, I keep per-caller rate limits at the proxy below the provider quota, so one noisy client cannot exhaust it for everyone. I alert on provider error rate specifically, because restarting Langflow containers will not fix an upstream problem.

Every image is tagged immutably, by commit SHA, and contains the flow JSON, custom components and pinned dependencies. Rolling back means redeploying the previous known-good tag, which restores the exact flow, code and Langflow version together. I deploy gradually, using canary or rolling updates, and watch p95 latency, 5xx rate and timeouts against the old version before shifting all traffic. The tricky part is the database. If a Langflow version upgrade ran schema migrations, an older image may not work against the new schema. So I treat version upgrades separately from flow changes, back up PostgreSQL before upgrading, and test the upgrade in staging first.

Playground testing is manual, so CI needs automated checks:<br>1. Validate that the exported JSON loads and contains no hard-coded secrets.<br>2. Unit test custom components as ordinary Python classes with their inputs and outputs.<br>3. Build the image, start it with test configuration, and call POST /api/v1/run/<flow-id> with a set of known inputs.<br>4. Assert on response shape and key behaviours.<br>Because model output is non-deterministic, I assert on structure, required fields or keywords. Alternatively I run a small evaluation set and compare scores rather than expecting exact strings. I also test negative paths: no API key, a revoked key and a disallowed tweak should all be rejected.

I treat the tracing backend as a store of personal data:<br><ul><li>Decide whether data may leave your infrastructure. If not, self-host Langfuse or use a deployment in the right region.</li><li>Restrict access to trace projects to the people who need it.</li><li>Set retention so traces expire.</li><li>Be able to delete data on request, which is easier if traces link to a pseudonymous session or user ID rather than names or emails.</li><li>For highly sensitive inputs, mask fields before they reach traced components, or trace only a sample.</li></ul>Message history in PostgreSQL needs the same retention and deletion thinking. The privacy policy must cover both.

The flow JSON in git is the artifact. It contains only references to global variables, never values. Each environment has its own secrets manager entries feeding the same variable names:<br><ul><li>its own provider keys;</li><li>its own database URL;</li><li>its own vector store;</li><li>its own tracing project.</li></ul>Promotion means deploying the same image tag to the next environment, never re-exporting from a UI. Separate tracing projects keep prod traces clean and let you compare staging runs. I keep flow IDs stable across environments where possible, or map them in client configuration, so callers change only the base URL and key.

You need a shared identifier. The proxy generates or forwards a request ID and logs it with the API key's identity, status and latency. Requests also carry flow ID and session ID, which Langflow passes into traces, so traces can be filtered by flow and session. From a latency spike on the dashboard, you find the slow requests in the access logs, take their timestamp, flow and session, and open the matching trace. Adding a request ID to trace metadata where possible makes this a direct lookup rather than a time-window search. Clocks across proxy, containers and the tracing backend should be synchronised so the timelines line up.

The main threats and their mitigations:<br>1. Unauthenticated access: auto-login off, API keys required, editor not public.<br>2. Leaked keys: secrets only in env vars and global variables, redacted logs, revocable per-caller keys.<br>3. Tweak abuse: an allowlist.<br>4. Prompt injection: user input or retrieved documents tell the Agent to misuse its tools. I limit the tools to what is needed, prefer read-only ones, and require confirmation outside the flow for destructive actions.<br>5. Data exposure through traces or message history: access control and retention.<br>6. Resource exhaustion: size limits, rate limits and timeouts.<br>I would test the injection risk directly, with adversarial inputs in the CI evaluation set.

Loading at startup from files baked into the image makes the deployment declarative. The image built from a git commit fully defines what runs, every replica gets the same flow, and rollback restores the exact old flow. The cost is that every flow change needs a rebuild and redeploy. Importing through the UI is faster for iteration, but it creates drift: production now holds a flow that may not match git, and nobody can easily tell which version is live. For production I prefer loading from files, with flow IDs kept stable so client URLs do not break. UI editing stays in dev or staging, and changes are exported back to git before promotion.

Timeouts exist at several layers:<br>1. The client's HTTP timeout.<br>2. The reverse proxy's upstream timeout.<br>3. Any timeout on the model and vector store calls inside components.<br>The rule is that inner timeouts should be shorter than outer ones. A slow provider call should fail inside Langflow with a clear error, and the error should come back to the client, rather than the proxy cutting the connection first and returning a generic gateway timeout. If the proxy times out first, the run may keep executing and spending tokens after the client has gone. I track timeouts as their own metric, separate from 5xx, because they usually point to an upstream provider or a slow retrieval step.

The /health endpoint tells the orchestrator whether the Langflow process is up and responsive. The orchestrator uses it to restart containers that hang or crash and to keep traffic away from containers still starting. I separate the ideas of liveness and readiness where the platform supports it. A container that is still loading flows should not get traffic, but it should not be killed either. I keep the probe cheap. It should not call the model provider, because a provider outage would then make the orchestrator restart every healthy container in a loop. Restarts should be monitored too. A rising restart count is itself an alert, often pointing to memory leaks or bad config.

I would not expose the editor publicly. Production should run flows, not be edited live. Edits made directly in prod bypass git review and cause drift from what CI tested. Common approaches:<br><ul><li>Run a separate build environment where people edit and test.</li><li>Export flows to git and deploy them to a production instance that serves only API traffic.</li><li>At the proxy, allow only the run, webhook and health paths publicly.</li><li>Keep the UI reachable only over a private network or VPN, for emergency inspection by a few authenticated admins.</li></ul>Superuser credentials are strong, stored in the secrets manager, and not shared.

Webhooks are usually called by third-party systems. You often cannot control their headers as easily, and the payload shape is defined by the sender. I still require authentication and never leave a webhook open. I also restrict which sources can reach the path at the proxy, apply size and rate limits, and treat the payload as untrusted input that may contain prompt injection. Webhooks are often fire-and-forget, so the caller does not see failures. Monitoring and traces become the only way to notice problems, which makes alerting on webhook-triggered run errors and checking idempotency for retried deliveries important.

Exposing flows as MCP tools means AI clients can call them directly, possibly in loops chosen by an agent rather than a human. The same rules apply as for the run endpoint:<br><ul><li>Require authentication.</li><li>Expose only flows meant to be tools.</li><li>Give each tool a clear name and description so clients use it correctly.</li></ul>I would think about blast radius. If a flow can write data or call external systems, an agent misled by prompt injection could misuse it. Rate limits and cost controls matter more, because agent clients can generate many calls quickly. I trace MCP-triggered runs the same way, so you can attribute load and errors to the calling client.

Custom components are Python classes, so they are code that runs with access to the container's environment, including every secret. They go through normal code review, live in git, and have unit tests. Their dependencies are pinned and installed at image build time, never at runtime. I scan the image for known vulnerabilities and watch for dependency conflicts with Langflow's own packages, which is a common upgrade pain. Components should read credentials only through declared inputs or global variables, never log them, and handle external call errors explicitly. That way a failure shows up clearly in the trace instead of as a vague exception.

I treat it as its own change, separate from flow edits:<br>1. Read the release notes for breaking changes to components, the API or configuration.<br>2. Bump the pinned base image tag in a branch.<br>3. Run CI smoke and evaluation tests.<br>4. Deploy to staging against a copy of the production database, because upgrades can run schema migrations.<br>5. Re-check that flows still load, custom components still import, and traces still arrive.<br>6. Back up PostgreSQL, then roll out gradually while comparing latency and error rates.<br>Because migrations may not be reversible, rollback may mean restoring the database backup along with the old image, so I plan that path beforehand.

For a server-to-server API, keying by API key is usually better:<br><ul><li>Many callers may sit behind one NAT or cloud egress IP, so IP limits punish innocent clients together.</li><li>One client may call from many IPs, so IP limits under-count it.</li><li>A per-key limit matches the identity you issue, revoke and bill against, and lets you give different clients different quotas.</li></ul>I still keep a coarser IP-based limit to absorb floods of unauthenticated requests, which carry no key. Limits should stay within what the model provider quota can sustain, so one caller cannot starve others.

The cleanest option is that external callers never talk to Langflow's run endpoint directly. A thin gateway or backend service sits in between. It validates the request against a schema per flow, allows only specific tweak fields such as a temperature within a range, drops everything else, and then calls Langflow with its own key. Many products go further, accept only the user input and session ID, and build any tweaks server-side. A proxy rule that inspects JSON bodies can work, but it is harder to maintain. Either way, allowlist rather than blocklist, and log rejected tweaks, because they are a sign of probing.

I would base SLOs on what users feel:<br><ul><li>availability, as the fraction of non-5xx responses for authenticated requests;</li><li>p95 latency for each flow, since flows differ a lot.</li></ul>Alerts fire on burn rate against those targets rather than single spikes. Supporting alerts cover:<br><ul><li>timeout rate;</li><li>a sudden rise in 401s, which suggests a broken client key rotation or an attack;</li><li>429s from our own rate limiter;</li><li>container restarts and failing /health probes;</li><li>provider error rate seen in traces.</li></ul>Each alert links to a runbook and a dashboard filtered by flow, so on-call can jump to traces quickly. Targets come from measured baselines, not guesses.

Traces record token usage per component per run. That lets you see which flows, components and callers consume the most tokens. Common findings:<br><ul><li>an agent looping through many tool calls;</li><li>a retrieval step stuffing too many documents into the prompt;</li><li>message history growing unbounded and resent on every turn.</li></ul>Fixes include capping agent iterations, limiting retrieved chunks, trimming history, or using a cheaper model for simple steps. Per-key rate limits at the proxy also act as a spend control. I would aggregate token usage by flow and caller into a dashboard and alert on unusual jumps, which can also reveal a leaked API key.

Streaming changes how the connection behaves. The proxy must not buffer the whole response, or the client gets nothing until generation finishes and the benefit disappears. Idle and read timeouts must allow long-lived connections that send data gradually. In monitoring, total request duration becomes less meaningful, because a streamed response is long by design. Time to first token is the better user-facing latency signal. Rate limiting may also need to consider concurrent open streams, not just request count. I would verify all of this with an end-to-end test through the real proxy, not just against the container directly.

1. ALANGFLOW_SUPERUSER
2. BLANGFLOW_AUTO_LOGINCorrect answer
3. CLANGFLOW_DATABASE_URL
4. DLANGFLOW_SECRET_KEY

Why: Auto-login treats every visitor as logged in. Setting LANGFLOW_AUTO_LOGIN=False turns on real authentication.

1. APOST /api/v1/run/<flow-id>Correct answer
2. BPOST /api/v1/execute
3. CPUT /api/v1/run/<flow-id>
4. DGET /api/v1/flows/<flow-id>

Why: Flows are run with POST /api/v1/run/<flow-id>, optionally with tweaks and a session_id.

1. ABase64-encoded in the component field
2. BAs a reference to a global variable whose value comes from the environmentCorrect answer
3. CIn a comment at the top of the JSON file
4. DPasted into the model component's API key field

Why: Referencing a global variable keeps the secret out of the flow file. The value is injected at runtime from the secrets manager.

1. AOnly the first component runs
2. BThe flow runs with the superuser's permissions
3. CThe flow runs but tracing is disabled
4. DIt is rejected before any component runsCorrect answer

Why: Missing or revoked keys are rejected up front, so no model or vector store calls are made.

1. Ax-langflow-token
2. BCookie: session
3. CAuthorization: Basic
4. Dx-api-keyCorrect answer

Why: Langflow API keys are passed in the x-api-key header (or as a query parameter) when calling endpoints such as POST /api/v1/run/<flow-id>.

1. APostgreSQL makes LLM calls faster
2. BReplicas need a shared, durable store for flows, users, keys and message historyCorrect answer
3. CTracing to Langfuse requires PostgreSQL
4. DSQLite cannot store flow JSON

Why: Each container would otherwise have its own local SQLite file, so sessions and keys would be inconsistent and lost on restart; LANGFLOW_DATABASE_URL points all replicas to one database.

1. AAt the PostgreSQL database
2. BAt the reverse proxy in front of LangflowCorrect answer
3. CInside each Langflow component
4. DAt the model provider

Why: The reverse proxy terminates HTTPS and also applies size limits, rate limits and access logging.

1. AWhich message history the conversation usesCorrect answer
2. BWhich API key is billed
3. CWhich Docker replica handles the request
4. DWhich tracing backend receives the trace

Why: Message history gives chat memory per session ID, so the same session_id continues the same conversation.

1. ADocker build arguments
2. BDatabase migrations applied on startup
3. CPer-request overrides of component settingsCorrect answer
4. DProxy rate limit rules

Why: Tweaks override component settings for a single run. That is why external callers should be limited to an allowlist.

1. AOnly the proxy access logs
2. BThe Playground chat window
3. CPostgreSQL message history
4. DLangSmith or LangfuseCorrect answer

Why: Langflow's tracing integrations include LangSmith and Langfuse, and both are enabled through environment variables.

1. ABuilds become reproducible and upgrades happen deliberatelyCorrect answer
2. BPinned tags disable authentication
3. CLatest images cannot load flows
4. DPinned tags remove the need for PostgreSQL

Why: A pinned tag makes every build use the same Langflow version, so upgrades are tested changes, not surprises.

1. ATyped into the UI after each deploy
2. BFrom a secrets manager as environment variablesCorrect answer
3. CStored in the flow JSON in git
4. DBaked into the Docker image layers

Why: Injecting secrets at runtime keeps them out of images, git and flow files.

1. ASo replicas use different model providers
2. BSo the proxy can terminate TLS
3. CSo traces are deduplicated
4. DSo each replica can decrypt stored secrets and validate tokens written by the othersCorrect answer

Why: The secret key is used for encryption and signing. Mismatched keys break decryption and authentication across replicas.

1. Ap95 latencyCorrect answer
2. BAverage request size
3. Cp50 latency
4. DTotal request count

Why: p95 captures tail latency, which the median hides.

1. AEach component's inputs, outputs, timing and token usageCorrect answer
2. BThe container's CPU temperature
3. CThe proxy's TLS certificate
4. DOnly the final HTTP status code

Why: Traces break a run down by component, which is how on-call finds the component at fault.

1. ARedeploy the previous immutable image tagCorrect answer
2. BTurn auto-login back on
3. CEdit the flow live in the production editor
4. DDelete the PostgreSQL database

Why: Immutable tags bundle the flow, components and Langflow version, so redeploying the old tag restores known-good behaviour.

1. AStoring history in the flow JSON
2. BPutting history in the tracing backend
3. CSticky sessions on the proxy only
4. DA shared PostgreSQL database via LANGFLOW_DATABASE_URLCorrect answer

Why: Message history is stored in the database, so a shared database lets any replica read it.

1. ADisabling the /health probe
2. BRedacting the x-api-key header at the proxyCorrect answer
3. CRaising the rate limit
4. DUsing a larger Docker image

Why: If the proxy logs headers unfiltered, keys end up in log storage, so the header must be redacted.

1. AWait for the next scheduled rotation
2. BChange LANGFLOW_DATABASE_URL
3. CRevoke the leaked key and issue a new one to the clientCorrect answer
4. DRebuild the Docker image

Why: Revocation immediately stops the leaked key from running flows, and the client gets a replacement.

1. ATweaks disable tracing for that run
2. BTweaks clear message history for all sessions
3. CTweaks force the flow to run in the Playground
4. DThey can override component settings such as model, prompt or credentials at request timeCorrect answer

Why: Tweaks override component settings per request, so unrestricted tweaks let a caller change behaviour or cost; the backend should whitelist or strip them.

1. ARestarts containers that are unhealthyCorrect answer
2. BSends traces to Langfuse
3. CRuns every flow once a minute
4. DRotates API keys

Why: The health probe detects unresponsive containers so they can be restarted automatically.

1. AA component has a Python bug
2. BThe model provider is down
3. CA client is sending a missing or revoked API keyCorrect answer
4. DPostgreSQL ran out of disk

Why: 401s are authentication failures, often a broken key rotation or an unauthorised caller, not a server fault.

1. AOnly proxy endpoints
2. BOnly built-in HTTP calls
3. COnly other agents
4. DComponents in tool mode, other flows, and MCP toolsCorrect answer

Why: The Agent takes tools from components switched to tool mode, from other flows and from MCP tools.

1. AA JavaScript plugin for the canvas
2. BA Python class with defined inputs and outputsCorrect answer
3. CA YAML file read by the proxy
4. DA Docker sidecar container

Why: Custom components are Python classes with inputs and outputs, added to the image at build time.

1. AThe model name
2. BThe caller's API key or identityCorrect answer
3. CThe flow ID
4. DThe session_id only

Why: Keying limits on the API key matches the identity you issue and revoke. It also avoids the shared-IP problems of IP-based limits.

1. AThe superuser used for administration
2. BAn anonymous auto-login user
3. CEach end user's personal browser session
4. DA dedicated service userCorrect answer

Why: A service user limits blast radius and keeps admin credentials out of client applications.

1. Aabout 23
2. Babout 600
3. Cabout 60Correct answer
4. Dabout 7

Why: By Little's law, concurrency is arrival rate times duration, so 20 × 3 = 60 in-flight runs.

1. AIt sends traces to LangSmith
2. BIt hosts the PostgreSQL database
3. CIt replaces the reverse proxy
4. DIt exposes flows as tools that MCP clients can callCorrect answer

Why: As an MCP server, Langflow exposes flows as tools to MCP clients, and those tools still need authentication.

1. ATo reject oversized payloads before they consume worker capacityCorrect answer
2. BTo reduce token usage inside traces
3. CTo speed up PostgreSQL queries
4. DTo shorten session IDs

Why: Size limits block abusive or accidental huge bodies at the edge, cheaply.

1. AIt would disable tracing
2. BHealth checks cannot make HTTP calls
3. CA provider outage would make every healthy container get restartedCorrect answer
4. DThe provider requires a different header

Why: Probes should reflect the container's own health. Otherwise an external outage causes restart loops.

1. AFlows loaded from files in the image
2. BPublic editor with auto-login enabledCorrect answer
3. CEditor reachable only on a private network
4. DOnly run and health paths exposed publicly

Why: An open editor with auto-login exposes unauthenticated control of flows and secrets.

1. AIt makes Langflow run faster
2. BFlow changes become versioned, reviewable and reproducible in CI buildsCorrect answer
3. CIt encrypts provider keys automatically
4. DIt replaces the need for tracing

Why: Git gives history, review and a single source the image is built from, which also enables clean rollback.

1. AThe TLS certificate
2. BThe vector store query and the number of chunks retrievedCorrect answer
3. CThe /health probe interval
4. DThe superuser password

Why: The trace attributes the latency to the vector store component, so fix retrieval, or roll back if a change caused it.