This replaces the earlier "two surfaces, webhook-synced" draft with what actually shipped. Kite is an AI website builder: every website is a Kite app that can be linked to a single GitHub repository on one branch (main today). The bridge is the Kite GitHub App — installed on the customer's org with scoped, revocable permissions. Users start three ways — from scratch, import an existing repo, or create a new one — or just type import from <repo> in chat. Kite resolves the repo by name, confirms before it replaces anything, and enforces one hard rule: imports must be Next.js projects. Editing, the live preview, secrets and publishing all live inside the Kite app; the source of truth stays in GitHub. Sync is explicit and two-way — Sync to GitHub pushes, Pull brings changes back.
Each website is a Kite app with Website, Code, Secrets, Content, Analytics & Growth tabs. You edit by chat or directly, see an in-app live preview, and hit Publish. The app is the workspace — no separate preview domain to reason about.
The Kite GitHub App links one repository on one branch. Code lives in the customer's own GitHub — e.g. appsmithorg/test_1 on main. Access is scoped to the repos they pick and revocable any time from Integrations or Settings → Repository.
Publish, all in-app.Sync to GitHub ↑ · Pull ↓ · on mainmain · customer-owned.In the live product, one button — Start something new — opens three doors, and a fourth path runs entirely inside the chat. One door needs no GitHub at all; the other three put real code under version control. All four merge back into the single track above. See each one in the product →
No idea what Git or GitHub is, and doesn't want to learn. Describes the site in plain language; Kite generates it from nothing. The real menu item: Start from scratch.
No repository yet, but wants the site to live in their own GitHub from day one. Kite creates a fresh repo, links a website to it, then generates the site.
Real codebase already on GitHub, already deployed. Picks the repo from the Import from GitHub picker and Kite imports its code — the path the main track documents end-to-end.
Already inside a Kite app and types "import from test_1" in the chat. Kite resolves the repo by name, confirms before replacing, and pulls it in — no menus, no forms.
The load-bearing choices behind the flow above — each one now visible in the live product, not just on a whiteboard. They define what the integration is, and where its risk lives.
Each website binds to a single repository on one branch (main today), shown under Settings → Repository. No mirrored "kite/*" namespace, no second main — the customer's main is the only main. Change repository or Disconnect at any time.
Sync is user-triggered, both ways: Sync to GitHub pushes the app's edits as commits; Pull brings GitHub changes back in. No background webhook machinery — the user decides when app and repo reconcile, which keeps the mental model simple and the surface area small.
The import contract is deliberately narrow: Next.js projects only. Anything else is refused with a plain reason, and the current site is left intact. A narrow, enforced contract is what lets Kite promise a clean import every time.
Start from scratch, Import from GitHub, and Create new in GitHub — plus a conversational import from <repo> path inside any app. All four converge on the same import pipeline, so there's one code path to harden, not four.
Access is the Kite GitHub App installation itself — scoped to the repos the customer picks, revocable from Integrations or Settings. Repo runtime secrets (e.g. NAME) live in the in-app Secret vault (backend/.env), supplied before the site runs — never hard-coded.
Kite auto-resolves a named repo to a concrete match (appsmithorg/test_1) and, because importing replaces the current site, always asks for an explicit Yes first. Destructive steps are never silent.
Each red exit on the map maps to a card below. Percentages are pre-data estimates — replace with real values after the first 100 imports. Hover a card to highlight its exit on the chart above.
The marketer asks for Kite; the VP-Eng or platform team approves the permission scope. The install requests read metadata plus read + write to code, workflows and administration — if that feels broad, they say no on instinct.
The user names a repo Kite can't see (not granted in the App install) or that resolves ambiguously. Kite can't proceed to import what it can't find — and must not import the wrong repo over the current site.
Imports support Next.js only. Anything else — WordPress, a static site, a non-Next.js app — is refused cleanly: "it is not a Next.js project, and imports here only support Next.js repos." The current site is left untouched and Kite offers to find another repo.
The imported repo needs runtime env vars (Kite flags them by name, e.g. NAME). The platform team approved the GitHub App but draws a hard line at handing over secrets — especially production ones — so the site can't fully run.
Because sync is explicit, the app and the repo can drift between actions. A Pull after the team pushed to main, or a Sync to GitHub over diverged history, can conflict — the one place app and repo can genuinely disagree.