Skip to main content
Manage GitHub integration for auto-deploy on push. These are subcommands of floo apps github.

connect

Connect a GitHub repo for auto-deploy. The command creates the named app if it does not exist and triggers an initial deploy unless you pass --no-deploy. A human must install the floo GitHub App on the repo’s owning account and authorize floo in a browser. When the App is missing, connect opens a setup link and waits for the human to finish; that link connects the installation to your floo org. Run floo init and floo preflight, then commit and push the generated configuration before connecting. The initial deploy reads the already-pushed branch, so connecting first can deploy incomplete source or configuration.

Flags

Agent / CI usage

Run connect with --no-browser (implied by --json) and relay the printed setup link to a human. Two browser-only actions are required: authorize floo with GitHub through that link, and install the App on the account that owns the repo. Each account needs its own installation; an organization installation does not cover a personal-account repo, or vice versa. If the App was installed outside a setup link, run floo apps github setup --no-browser and relay its link. Re-run connect after the human finishes.

Examples

JSON output

The deploy object contains the deployment record returned by the API. With --no-deploy, deployed is false and deployment fields are omitted; the first deploy runs on your next push to the connected branch.

disconnect

Disconnect a GitHub repo from an app.

Flags

JSON output


status

Show GitHub connection status (repo, branch, connected date).

Flags

JSON output


setup

Mint a fresh setup link to link or re-link the floo GitHub App installation to your floo org. Run it when the App was installed outside a setup link and connect fails with GITHUB_INSTALLATION_NOT_AUTHORIZED. A human opens the link and authorizes floo with GitHub; floo links an installation that login can access, or shows a picker if several are available. If none is installed, the page asks the human to install the App on the repo’s owning account; floo links it automatically when GitHub reports the installation.

Flags

JSON output

Open setup_url once in a browser, then run connect. Without --no-browser, the CLI opens the link, waits for the binding, and reports {"linked": true, "next": "..."}.

Granting the floo GitHub App access to a repository

Connecting a repo takes two operations. They are separate, both are required, and neither substitutes for the other. The setup link can be opened before installation; both actions require a human in a browser.

1. Grant access on GitHub

Open:
  • Choose the account that owns the repository. GitHub scopes an installation to one account. Installing on an organization grants nothing for a repo owned by a personal account, and the reverse is equally true. For acme/storefront, the installation must be on acme; for you/side-project, it must be on your personal account.
  • Select the repository under “Repository access”. With “Only select repositories”, the repo must appear in that list. An installation saved with the repo unselected reports success on GitHub and still fails connect.

2. Bind the installation to your floo org

Open the setup link from connect, or mint a fresh one for an App installed outside that flow:
Open the printed link and authorize floo with GitHub to link the installation to your floo org, then re-run connect. Installing directly from github.com without opening a setup link leaves connect failing with GITHUB_INSTALLATION_NOT_AUTHORIZED.

Which failure am I looking at?

floo apps github status --app my-app reports the connection for an app that is already connected. It does not report install state for an app that has not connected yet, so use the error code from connect to tell these three apart.

For agents

You cannot grant GitHub access. It is a browser-only action tied to a human’s GitHub permissions, and no flag, token, or retry substitutes for it. When connect fails with any code above, escalate to a human with four things: the account to install on, the repository to select, the URL, and the command to re-run. Then stop. Re-running before the human acts produces the same failure, and repeated attempts are indistinguishable from progress in a transcript.

Errors