Introduction

If you have ever run a Discord bot alongside a small dashboard or marketing site for it, you already know the annoying part isn't writing the bot. It's everything around it: finding somewhere to run it, wiring it up to a database, making sure the site can talk to the bot without hardcoding IPs, remembering which environment variable lives where, and doing all of that again for every client if you run more than one of these. Flow exists to take that annoying part off your plate.

Flow is a self-hosted control panel you install on your own server. You connect a Git repo, tell it which server to run on, and Flow builds and deploys it for you. Push a commit and it redeploys on its own. And because it treats a bot and its companion site as one connected thing rather than two unrelated apps, they can already see each other, share secrets, and share a database the moment you create them, without you writing a single line of networking glue.

It occupies the same space as Dokploy or Coolify, if you've used either of those. The difference is that scope: Flow is opinionated about the bot-plus-site shape specifically, so that relationship is built in from day one instead of something you configure by hand every time.

The mental model

Everything in Flow nests inside a handful of ideas. Once these click, the rest of the dashboard makes a lot more sense, so it's worth reading slowly even if you're itching to skip ahead to the install command.

• Org: the account-level container everyone and everything belongs to. Most instances only ever have one, and you're its owner the moment you sign up.
• Project: the thing you actually create day to day. A Project is a folder for one client or one product: it holds the services that make it up, and anything you mark as shared (secrets, a database connection string) is automatically available to every service inside it.
• Service: a single deployable thing living inside a Project. Usually that's a bot and a site, but a Service can also be an addon like a shared Postgres or Redis instance that the others connect to. Each Service has its own repo, its own build settings, and its own deploy history, even though it shares a Project with its siblings.
• Node: a server Flow deploys onto. The server Flow itself runs on already counts as one, nothing to set up. Add more by pointing Flow at a VPS you already have; it connects over SSH and installs a small agent there itself. Services get scheduled onto whichever node you choose when you create them.
• Deployment: one build-and-release of a Service. Every push (or manual redeploy) creates a new one, and you can look back through the history or roll back to an older one later.

So a typical setup looks like: one Project called Acme Support Bot, containing three Services inside it, a Discord bot, its admin dashboard site, and a shared Postgres addon, all deployed onto one Node, all able to reach each other without any of them knowing the others' public URLs.

What this section covers

This isn't a quick-start with three steps and a "good luck from here." It walks through the whole dashboard: installing the control plane itself, how projects and services fit together, environment variables and secrets, connecting Git providers, how deploys and rollbacks actually work, the built-in logs and terminal, adding nodes, monitoring, cron-style schedules, team roles and invites, and the audit log. Read it end to end if you're setting Flow up for the first time, or jump straight to whichever page matches what you're stuck on.

Start with Installation to get the control plane running, or read Architecture first if you'd rather understand how the pieces fit together before you touch a terminal.