Git providers
Flow deploys from a Git repo, and it supports four different ways of connecting to one, from a fully automated GitHub App down to a plain repository URL with nothing configured at all. All of this lives under /git in the dashboard, and only org admins and owners can connect or disconnect a provider, everyone else can still use whatever's already connected when creating a service.
GitHub
This is the smoothest option and the one worth using if your code is on GitHub. Click Connect and Flow walks you through GitHub's app manifest flow: you're sent to GitHub, you confirm the app (Flow registers it on your account for you, there's no client ID or secret to create yourself), and then you choose which repositories to install it on, the same picker GitHub shows for any app installation. That's the entire setup.
Because the app is registered specifically for your instance, the webhook Flow needs to hear about pushes is created automatically as part of that same flow. Nothing to paste into a GitHub settings page afterward.
One catch worth knowing: push-to-deploy relies on GitHub being able to reach your Flow instance to deliver that webhook. If your instance isn't reachable at a public URL, for instance if you're still running it behind http://server-ip:3000 without a domain in front, the dashboard will tell you as much, and pushes won't trigger a deploy on their own. Everything still works, you just use the Redeploy button on the service instead of relying on the webhook, see Deploying.
GitLab and Gitea
Both work the same way as each other. Instead of an app installation, you connect with a personal access token: on GitLab that's created under User Settings → Access Tokens with the api scope, on Gitea it's under Settings → Applications. You also give Flow the provider's base URL, which defaults to gitlab.com but can point at a self-hosted GitLab or Gitea instance just as easily.
The token is encrypted the same way your environment variables are. Unlike GitHub, the webhook here isn't created the moment you connect the provider, it's registered per repository, the first time you pick that repo while creating a service. From that point on, pushes to it behave the same as a GitHub-connected repo.
Generic Git
For anything else, or if you'd simply rather not connect an account at all, you can create a service with just a raw repository URL and, if it's private, an access token. There's nothing to set up at the org level for this option, you add it directly on the service when you create it.
The tradeoff is automation: a generic connection has no webhook, so pushing to the repo doesn't trigger a deploy by itself. You'll deploy it with the Redeploy or Rebuild button when you're ready, which is often exactly what you want for something you don't push to often.
Choosing per service, not per project
The Git provider is a choice you make on each individual service, not once for the whole project. It's entirely normal for a bot to deploy from a GitHub repo while its companion site in the same project deploys from a completely different provider, or from no provider at all if you attached it manually. Nothing about the project-level features, the shared network, the shared environment variables, cares which provider a given service's code comes from.
Fine-tuning what triggers a deploy
Once a service is connected to GitHub, GitLab, or Gitea, its General tab has a few more knobs worth knowing about:
- Autodeploy: whether a push actually triggers a new deployment at all. Turn it off if you'd rather review and deploy manually every time.
- Build path: a subdirectory to build from, for monorepos where the service you're deploying isn't at the repo root.
- Trigger type: deploy on every push to the branch, or only when a tag is pushed, useful if you cut releases instead of deploying every commit.
- Watch paths: one path prefix per line. If set, only a push that touches a matching file triggers a deploy, so changes to an unrelated part of a monorepo don't redeploy something they didn't affect. Leave it empty to watch the whole repo.