Projects and services

This is where you'll spend most of your time in Flow. Projects and services are the actual things you create, deploy, and come back to check on, everything else in the dashboard exists to support these.

Creating a project

A Project is just a name, that's the entire form. Think of it as a folder for one client or one product: everything you build for "Acme Studios" goes in one Project, everything for the next client goes in another. The name has to be unique inside your org, and Flow generates a slug for it automatically. You're added as a member of any Project you create, and org owners and admins can always see every Project regardless.

Adding a service

Once you're inside a Project, adding a Service is where the actual choices are. You'll pick:

A name, whatever helps you tell it apart from its siblings.
A type: Bot, Site, or Addon. Bot and Site are treated identically under the hood, the label is just for your own clarity, addon is different and covered on its own below.
A node, which server this actually runs on. The server Flow itself is installed on already shows up here with nothing extra to do, so you can pick that and move on, or choose another node you've added for more capacity.

For a Bot or Site, you then choose how it runs, see the three runtime modes in Architecture, and connect a repository, or skip that step entirely and attach one later. That last option is genuinely useful if you want to get the Service and its environment variables set up before the code is ready.

Addons: shared Postgres and Redis

An Addon isn't something you deploy code to, it's infrastructure the rest of your Project's services share. Creating one asks for two things: which kind, Postgres or Redis, and what environment variable name the connection string should be exposed as, it defaults to sensible values (DATABASE_URL, REDIS_URL) but you can rename it if something in your codebase expects different.

Behind the scenes, creating the addon generates a random password, provisions the database itself, and writes the connection string as a shared environment variable on the Project, meaning every other Service in it, your bot and your site, both, picks it up automatically with no copy-pasting between them. This happens through a real deployment too, you'll see it show up as a "Provision addon" entry the first time.

One thing worth knowing: you can only have one shared variable with a given name per Project, so if you already have something using the key you picked, creating the addon will fail until you rename one or the other.

The service page

A Service's own page is organized into tabs, and it's worth knowing what lives where before you go looking for something:

General: the deploy buttons (Deploy, Reload, Rebuild, Stop), the autodeploy and build cache toggles, and which Git provider and branch this Service builds from. Covered in depth in Deploying.
Environment: variables specific to this Service, on top of whatever the Project shares with everything in it. See Environment variables.
Domains: not shown for addons. Attach a domain and the container port it should route to, and Flow's reverse proxy on that node handles routing and TLS from there. The domain needs to already resolve to that node's IP in DNS before a certificate can be issued.
Deployments and Logs: your deploy history and the raw output for each one, including rollbacks. See Deploying and Logs and the terminal.
Schedules: cron-style one-off commands that run inside the container. See Schedules.
Monitoring: a quick pointer to this Service's container state, for actual resource graphs across everything, see Monitoring and Docker.
Advanced: build command, start command, and output directory overrides, plus a Danger Zone to delete the Service entirely, permanently, deploy history included.
Discord: Bot services only. Add the application's Discord application ID here, and if a DISCORD_TOKEN variable is set (shared or Service-specific), Flow validates it against Discord's API and shows you the bot's username, avatar, and its currently registered slash commands, plus a small tool to generate an invite link for a given set of permissions.

A few tabs, Preview Deployments, Volume Backups, and Patches, exist as placeholders for features that aren't built yet. They're visible so you know they're planned, not because there's anything functional behind them today.

Stopping and starting

Every Service has a Stop and Start control independent of deploying. Stopping doesn't delete anything, your deploy history, its environment variables, its domain, all of it is untouched, it just takes the running container or process down. This is the right tool for "I don't need this running right now" without going anywhere near the Delete Service button on the Advanced tab.