How to Self-Host Flowise: 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 Flowise gets you the full Apache-2.0 open-source build, unlimited flows, chatflows, and team members, running on your own infrastructure in about ten minutes with Docker Compose. This guide covers the setup most tutorials rush past: generating a stable credential encryption key, choosing the right database for more than a solo test, and locking the instance down before you connect a real LLM API key to it.
What you need before you start
You need a server or VPS with Docker and Docker Compose v2 installed, plus openssl to generate a secret. Flowise itself is lightweight, since it doesn't run any model locally, it calls out to whichever LLM API your flows use, so 1-2 vCPU and 2GB of RAM is enough for a small team instance. The exception is if you plan to point Flowise at a self-hosted model server, like Ollama, running on the same box; that needs its own real compute budget and is worth sizing separately from Flowise itself.
Step 1: Clone the repo and set up the Docker directory
Flowise ships an official docker folder in its GitHub repository with a ready-to-edit Compose file:
git clone https://github.com/FlowiseAI/Flowise.git
cd Flowise/docker
cp .env.example .env
Everything you configure from here happens in that .env file, so keep it somewhere you'll back up alongside your database.
Step 2: Generate a stable encryption key
This is the step most self-hosting guides skip, and it's the one that causes real pain later. Every credential you connect to Flowise, an OpenAI key, a Pinecone or Qdrant connection string, any node's stored secret, gets encrypted at rest. If you never set FLOWISE_SECRETKEY_OVERWRITE, Flowise generates a random key on first launch and stores it on disk inside the container. That's fine until the container is recreated without the right volume mounted, at which point every stored credential becomes permanently undecryptable, even with a full database backup.
Generate a fixed value yourself and set it explicitly:
openssl rand -base64 32
Paste the result into FLOWISE_SECRETKEY_OVERWRITE in your .env file before the first docker compose up. Back this value up the same way you'd back up a password vault, separately from your database dumps, not alongside them.
Step 3: Decide on your database
Flowise defaults to SQLite, stored inside the container's data volume. That's genuinely fine for a solo developer testing flows locally, but it's the wrong call the moment more than one person is building against the same instance, or you care about surviving a server migration cleanly. For anything beyond a personal sandbox, set DATABASE_TYPE=postgres and fill in DATABASE_HOST, DATABASE_PORT, DATABASE_USER, DATABASE_PASSWORD, and DATABASE_NAME in your .env file, pointing at either a Postgres container you add to the Compose file or a managed database. The migration path from SQLite to Postgres after the fact means exporting and re-importing your flows by hand, so deciding this upfront saves a genuinely annoying afternoon.
| SQLite (default) | Postgres | |
|---|---|---|
| Setup effort | None, works out of the box | Add a database and set 5 env vars |
| Best fit | Solo developer, local testing | Any team instance |
| Concurrent writes | Handles this worst | Built for it |
| Migrating later | Manual export and re-import | Not needed, already there |
Step 4: Set basic auth and the port
Set FLOWISE_USERNAME and FLOWISE_PASSWORD in your .env file before exposing the instance to anything beyond localhost, this is the app-level login gate, and leaving it unset means anyone who reaches the URL has full access to every flow and credential. The default port is 3000; change PORT if that conflicts with something else already running on your server.
Step 5: Launch it
From the docker directory, start everything with:
docker compose up -d
Give it a minute to initialize, then visit http://localhost:3000, or your server's IP or domain on the same port. Log in with the FLOWISE_USERNAME and FLOWISE_PASSWORD you set, and you're in the canvas.
Step 6: Put TLS in front of it for real use
Don't expose Flowise's raw port directly to the internet for anything beyond local testing. Put Caddy or Nginx in front of it as a reverse proxy, terminating TLS there and forwarding to the Flowise container over your Docker network. Caddy is the lower-effort option if you want automatic Let's Encrypt renewal with a handful of config lines; a simple Caddyfile pointing your domain at the container's port is enough for most single-instance setups. Firewall the server so only 80 and 443 are reachable externally, never the app's raw port.
Step 7: Back up what actually matters
Your flows, chatflow configurations, and encrypted credentials live in the database, Postgres or SQLite, not scattered across the container's filesystem in a way that's easy to reconstruct. If you're on Postgres, a nightly pg_dump shipped off-server is the minimum viable backup. Back up your .env file, specifically the FLOWISE_SECRETKEY_OVERWRITE value, separately from that database dump; losing either one alone is recoverable, losing both together is not.
Common mistakes to avoid
Skipping the encryption key and letting Flowise generate one silently is the mistake we see most often; it works until the container's internal state is lost, and then every connected credential needs to be re-entered from scratch. Staying on SQLite past the point where more than one person is editing flows is the second, since concurrent writes to a SQLite file are exactly the scenario it handles worst. And exposing the raw port without a reverse proxy works right up until you're sending an LLM API key over an unencrypted connection to log in.
What's next
Once your instance is running, our Flowise vs n8n comparison covers where a purpose-built AI tool like Flowise earns its keep against a general automation platform, and where it doesn't. If you're deciding between Flowise and its closest visual-builder rival, Langflow vs Flowise breaks down the licensing, pricing, and hands-on build-time differences. And if you're weighing a visual canvas against writing directly against an agent framework, our roundup of open-source AI agent frameworks covers the code-first alternatives worth knowing about before you commit to a canvas tool.
Frequently asked questions
Is self-hosting Flowise actually free?
Yes. Flowise is open source under the Apache-2.0 license, and self-hosting it has no artificial limit on flows, chatflows, or team members. The paid Flowise Cloud tiers exist for teams that would rather not run their own server; none of their features are required to self-host the full product.
What happens if I lose my FLOWISE_SECRETKEY_OVERWRITE value?
Every credential you've stored in Flowise, OpenAI keys, Pinecone connections, any secret tied to a node, is encrypted with that key. Lose it without a backup, and those credentials can't be decrypted even from a full database restore; you'd have to re-enter every one. Treat the value with the same care as a password vault and back it up somewhere separate from your database dumps.
Do I need a GPU or a powerful server to self-host Flowise?
No, for the common case. Flowise itself doesn't run models locally; it orchestrates calls to whichever LLM provider you connect (OpenAI, Anthropic, a hosted endpoint). A 1-2 vCPU, 2GB RAM VPS runs the app comfortably. The exception is if you point Flowise at a self-hosted model server like Ollama on the same box, which needs real CPU or GPU headroom of its own.
Can I run Flowise without Docker?
Yes, via npm (npm install -g flowise, then npx flowise start), but you'll be managing Node versions and process supervision yourself. Docker Compose bundles the app, its database, and restart behavior into one file you can version and redeploy, which is why it's the path this guide covers.