Your servers, your region, your keys

Self-hosting

No licence key required

Bee Flow was built to be run by the people who use it. The images are public, the install is one command, and nothing calls home for permission to start.

Source on GitHub

The short version

One script, then a URL and a password

The script pulls the public images, generates secrets, waits for the health check and prints where to go. Optional services are opt-in profiles, so a small install stays small.

Pick your install

Six supported ways in

The one-line script

./selfhost.sh

Public images from the registry, no login. Best for a first evaluation and perfectly fine for a small team in production.

Docker Compose, your way

docker compose --profile core --profile guard up -d

Eight profiles — core, search, search-gpu, search-llm, guard, whisperx, pii and analytics. Run only the services you actually want, and keep the GPU ones off a CPU box.

Kubernetes

kubectl apply -k deploy/

Eleven manifests covering the namespace, config, secrets, both app services, storage, the guard, ingress, network policy and analytics. Manual manifests today — a Helm chart is not shipped yet.

Nextcloud App Store

Install Bee Flow as a Nextcloud ExApp and it inherits your existing users, groups and files. The connector is AGPL-3.0, as the App Store requires.

Portainer or the install wizard

A stack file for Portainer, and a browser-based wizard for teams that would rather answer questions than edit YAML.

No Docker at all

npm run dev:all

A local install script for Linux, macOS and Windows that runs the server and frontend directly against a local PostgreSQL. Handy for development and for auditing what the thing does.

What you are responsible for

The honest operations picture

Self-hosting is a real commitment. These are the parts that are yours.

TLS and the front door

Bee Flow expects a reverse proxy in front — Caddy, nginx, Traefik or Cloudflare. Certificates are your side of the line.

Backups

Your PostgreSQL and your object storage hold everything. A CMS site, knowledge base or automation also exports to a file on demand.

Sizing

The core stack is modest. Transcription wants a GPU; the search and rerank services are built to run on CPU-only machines if you prefer.

Deployment surface

Before you provision anything

What it needs to run

Real numbers from the deployment docs, not a shrug. The core stack is deliberately modest — the expensive parts are optional and off by default.

Minimum

2 CPU cores, 4 GB RAM, 10 GB disk, and 1 GB for PostgreSQL. That is a small VM, and it is enough for a team evaluating the platform properly rather than a toy.

Recommended

4 cores, 8 GB RAM, 50 GB disk, 2 GB for PostgreSQL. This is the shape most small and mid-sized organisations settle on for day-to-day production use.

Scaling out

The server is stateless once Redis is configured, so you scale it horizontally. PostgreSQL carries every durable thing — users, agents, conversations, knowledge chunks, automation runs, the audit log — which also makes it the only thing you must back up carefully.

What runs where

FAQ

What people ask before they commit a server

Does it phone home, and does it stop working if it cannot?

No, and no. The core workspace runs with no licence server reachable at all — that is why the badge at the top of this page says no licence key is required. Premium features check a signed licence when you have one, but the absence of a connection degrades those features rather than stopping the platform. An air-gapped install is a supported way to run this, not a workaround.

How do upgrades work?

Pull the new images and restart; database migrations run on server start. Pin a tag if you would rather decide when that happens — the published images are versioned, and nothing forces an upgrade on you on someone else's schedule. Read the release notes for the ones that change a default.

What do we actually have to operate?

TLS and the reverse proxy in front, backups of PostgreSQL and object storage, and enough disk for whatever knowledge base you build. Everything else is containers. The honest summary is that this is the same operational weight as running any other stateful web application — not less, and worth budgeting for.

Can we start hosted and move to our own servers later?

Yes, and it is a deliberate design goal rather than a favour. The hosted version runs the same images you would run. Sites, knowledge bases and automations export to files on demand, so the migration is an export and an import rather than a support ticket and a negotiation.

Which parts need a GPU?

Only transcription really wants one. Search, reranking and the PII detector are all built to run on CPU-only machines, and the compose profiles keep the GPU services off a box that does not have one. You can run the whole privacy layer without special hardware.

What do you give a security reviewer?

The source itself, a third-party licence inventory committed in the repository, and a CycloneDX SBOM generator you run against the tree yourself — we ship the script rather than a snapshot, because an SBOM checked in today describes yesterday's dependencies. Then a supply-chain story for extensions: marketplace modules are cryptographically signed packages whose signatures are verified before anything loads. Add the compliance checks running against the live install, and the review starts from evidence rather than from a questionnaire.

Read the code before you trust the claims

Source-available and auditable. The privacy behaviour described on this site is in the repository, not in a brochure — and running it yourself is the difference between a vendor promising sovereignty and you holding it.

Bee-Flow/Bee-Flow-AI