How to Self-Host Langflow: Step-by-Step Guide
This page may contain affiliate links. If you buy through them we may earn a commission at no extra cost to you.
Self-hosting Langflow gets you the full MIT-licensed build, unlimited flows and components, running on your own infrastructure in a few minutes with Docker Compose. This matters more than it used to: DataStax's managed Langflow hosting on Astra was discontinued in April 2026, so self-hosting is now the primary way most teams run it, not one option among several. This guide covers the setup from a clean server to an instance you'd trust with real work, including the two things that trip people up most: the database choice and locking down the superuser account.
What you need before you start
You need a server or VPS with Docker and Docker Compose v2 installed. Langflow itself is light on compute, since model inference happens through whichever LLM API your flows call rather than on the Langflow server, so 1-2 vCPU and 2GB of RAM is enough for a small team instance. If you're also running a self-hosted model server like Ollama on the same box, size that separately and generously; it's a genuinely different resource profile than Langflow's own footprint.
Step 1: Pull the official image and write your Compose file
The fastest path is Langflow's official Docker image rather than building from source:
mkdir -p /opt/langflow && cd /opt/langflow
Write a docker-compose.yml with a langflow service using the langflowai/langflow:latest image (pin a specific version tag once you've confirmed the instance is stable, rather than tracking latest indefinitely), exposing port 7860. For anything beyond a quick local test, add a Postgres service too; the next step covers wiring it in.
Step 2: Point it at Postgres instead of the default SQLite
Langflow's container defaults to a local SQLite file, which works for a single developer poking at flows but isn't built for concurrent writes from more than one person. Set the LANGFLOW_DATABASE_URL environment variable to a standard Postgres connection string (postgresql://user:password@host:5432/langflow) pointing at either a Postgres container you've added to the Compose file or a managed database. Making this call before you've built anything real saves you from a manual export-and-reimport migration later, since Langflow doesn't automate that move for you.
Step 3: Set the superuser account explicitly
Langflow creates a superuser account on first launch, and leaving this to defaults is the most common security gap we see in self-hosted instances reachable from outside a local network. Set LANGFLOW_SUPERUSER and LANGFLOW_SUPERUSER_PASSWORD explicitly in your environment before the first docker compose up, using a real password manager to generate the password. This account has access to every stored credential and flow in the instance, so treat it accordingly.
Step 4: Launch and log in
Start everything with:
docker compose up -d
Give Postgres a moment to initialize if you're using it, then visit http://localhost:7860, or your server's address on the same port. Log in with the superuser credentials you set in Step 3.
Step 5: Put TLS in front of it for anything public
Don't expose port 7860 directly to the internet. Run Caddy or Nginx in front of the container as a reverse proxy, terminating TLS there. Caddy is the simpler choice for automatic Let's Encrypt certificate management with minimal configuration; a short Caddyfile pointing your domain at the Langflow container covers most single-instance setups. Firewall the server so only 80 and 443 are reachable externally.
Step 6: Back up your database, not just the container
Your flows, components, and any stored credentials live in Postgres (or the SQLite file, if you stayed there), not in a way that's trivial to reconstruct from the running container alone. A nightly pg_dump shipped off-server is the minimum viable backup if you're on Postgres. Test a restore on a throwaway server once before you trust the process, the same rule that applies to any self-hosted tool holding data you can't afford to lose.
Step 7: Set the auto-login and API key variables deliberately
Two more environment variables are worth setting explicitly rather than leaving on defaults. LANGFLOW_AUTO_LOGIN defaults to enabling passwordless access on some deployments, which is convenient for a local sandbox and a real liability the moment the instance is reachable from outside your network; set it to false once you've moved past local testing, so every session actually requires the superuser credentials from Step 3. Separately, if you're calling Langflow's API from external scripts or another service rather than only using the browser UI, generate a dedicated API key from the settings panel rather than reusing your superuser password anywhere in code or CI configuration.
Here's a quick reference for the environment variables this guide has you set:
| Variable | What it does |
|---|---|
LANGFLOW_DATABASE_URL |
Points the instance at Postgres instead of local SQLite |
LANGFLOW_SUPERUSER |
The admin account's username |
LANGFLOW_SUPERUSER_PASSWORD |
The admin account's password |
LANGFLOW_AUTO_LOGIN |
Set to false once past local testing to require a login |
Common mistakes to avoid
Leaving the superuser account on defaults is the mistake most likely to bite you, especially now that self-hosting is Langflow's primary path rather than a fallback option, meaning more instances are reachable from the open internet than before. Staying on SQLite past the point where more than one teammate is building flows is the second; it runs fine until a concurrent write corrupts something mid-session. Leaving LANGFLOW_AUTO_LOGIN on its default past the local-testing phase is a close third, since it quietly removes the login wall you thought Step 3 had already put in place. And pulling the latest image tag on every restart means an upstream update can change your running instance without warning, pin a version once you're stable.
What's next
Once your instance is running, our Langflow vs Flowise comparison covers how the two visual LangChain builders actually differ in licensing, RAG tooling, and build speed, useful context now that Langflow's own hosted option is gone and the self-hosting decision carries more weight. If you're considering a Node.js-first alternative instead, our guide to self-hosting Flowise walks through the equivalent setup for that tool. And if a code-first framework fits your team better than any visual canvas, our best LangChain alternatives for building AI agents roundup covers where Langflow sits against writing directly against LangChain or a competing framework.
Read the source docs directly before you commit: Langflow publishes its current self-hosting guide, which is worth checking against this one since deployment details shift as the IBM-stewarded project continues to evolve post-DataStax.
Frequently asked questions
Is Langflow still maintained and safe to self-host after DataStax's shutdown?
Yes. DataStax discontinued its managed Langflow hosting on Astra in April 2026, but the open-source project kept going and is now stewarded under IBM. Self-hosting via Docker is the primary, actively maintained way to run Langflow today; there's no official managed alternative replacing what DataStax offered.
What are the minimum server requirements for self-hosting Langflow?
A 1-2 vCPU, 2GB RAM VPS runs Langflow comfortably for a small team, since the model inference itself happens on whichever LLM API you connect, not on the Langflow server. Budget more only if you're also running a self-hosted model server like Ollama on the same box.
Do I need Postgres, or is SQLite enough?
SQLite, the default, is fine for a single developer testing flows locally. For a team instance, or anything you'd be upset to lose, switch to Postgres by setting LANGFLOW_DATABASE_URL in your environment. Concurrent writes from multiple users are exactly the case SQLite handles worst, and the migration after the fact means exporting and re-importing flows by hand.
Is there a free hosted version of Langflow now that DataStax's is gone?
Not an official one as of this writing. Self-hosting is the primary path, whether on your own VPS or a third-party host running the open-source image on your behalf. If that changes, it would come from the IBM-stewarded project itself rather than a return of the old DataStax Astra integration.