How to Connect a GitHub Repo to Inflowave

What "connect your repo" actually does

This is a separate path from building a site with Inflowave's AI builder. It's for a site you already have the code for — a hand-built site, something exported from another tool, or a repo a developer maintains — that you now want hosted, monitored, and (optionally) editable from Inflowave alongside everything else you run there.

There are two access tiers, chosen when you connect:

Step by step: connecting an existing repo

1. 1In Inflowave, go to Websites and start a new site via "Connect your repo" rather than the AI builder.
2. 2Choose your access tier: deploy-only if you just want hosting, full edit if you want to make changes visually afterward.
3. 3You're sent to GitHub's own install screen for the Inflowave App. Choose the specific repository (or repositories) to grant access to — you are never asked for your GitHub password, and the consent screen is entirely GitHub's, not ours.
4. 4GitHub redirects you back to Inflowave. If you granted exactly one new repo, it's imported automatically. If you granted more than one, you'll see a picker — Inflowave never assumes which of several granted repos you meant to turn into a website.
5. 5Before import, Inflowave checks whether the repo will actually build in a plain container and tells you up front if something looks like it won't (see the eligibility checks below), rather than letting you find out after a failed deploy.
6. 6Once imported, hit Build & Deploy to publish it. Nothing deploys automatically on import — you control when it goes live.

From then on, pushing a new commit to the connected branch triggers an automatic rebuild — the same way a push-to-deploy pipeline on Netlify or Vercel works. You don't need to come back into Inflowave for routine updates to the code.

What gets checked before your repo is accepted

Not every GitHub repo is a static website that drops cleanly into a host. Before import, Inflowave looks at the repo's structure and flags the issues that would otherwise only surface as a failed build with no obvious cause:

• An unsupported package manager lockfile for the build environment.
• Build output nested deep inside a monorepo rather than at a predictable path.
• A framework that expects a live server to render pages, rather than producing static output a CDN can host.

If the check is inconclusive — which happens, since reading a repo's structure from the outside can't catch everything — Inflowave says so rather than guessing, and you can still try the import.

Editing a connected repo from Inflowave

This only applies to the full-edit tier. With deploy-only access, Inflowave is a one-way pipe: your repo's code in, a hosted site out. Nothing in Inflowave can change the code.

With full edit, you get Inflowave's visual website editor on top of your existing code. Changes you make there don't get pushed straight to your default branch — they come back as a pull request, so a developer (or you) can review the diff exactly like any other PR before it merges. Inflowave never force-pushes and never bypasses your repo's own branch protections.

You can switch a repo from deploy-only to full edit later by connecting it again and choosing the other tier — Inflowave recognizes the repo you already linked and updates its access level instead of creating a second, duplicate site.

Disconnecting a repo

Disconnecting in Inflowave unlinks the repo from its site. It deliberately does the small, reversible thing: your website stays live and untouched, and your GitHub repo is untouched too.

What it does not do is revoke GitHub's access grant — that permission lives entirely on GitHub's side, in your installed-apps settings, and it's the only place it can honestly be revoked. If you want Inflowave to stop being able to see the repository at all, remove the installation from your GitHub account settings directly.