> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gleap.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Lovable, Replit, v0 and Base44

> Let Kai Code fix tickets in apps built on Lovable, Replit, v0 and Base44, and install the Gleap widget in them.

Not every app lives in a git repository. If your app is built on **Lovable**, **Replit**, **v0** or **Base44**, connect your account there and Kai Code works on the app through the platform itself: it asks the platform's own agent to make the change, checks the result and, if you allow it, publishes the app. There is no branch and no pull request; your team decides what goes live.

```
Ticket  →  Kai Code session  →  Platform agent changes the app  →  Publish  →  Customer reply
```

<Note>
  **Rolling out.** Vibe coding platforms are being rolled out and may not be available in your workspace yet. When they are, **Kai Code → Settings** shows a **Vibe coding** tab.
</Note>

## What Kai can do on each platform

| Platform | Kai works on a | How the change is made | Kai can read the code | Publishing |
| - | - | - | - | - |
| **Lovable** | project | Kai asks Lovable's agent and reads the diff it produced | Yes | Kai can publish |
| **Replit** | app | Kai asks Replit Agent; it can ask Agent how the app works first | No | Kai can publish |
| **v0** | chat | Kai sends the change as a message in the chat | Yes | Kai can publish (deploys to Vercel) |
| **Base44** | app | Kai asks Base44's editor AI, or edits the files itself in the app's sandbox (it creates a checkpoint first) | Yes | A teammate publishes in Base44 |

Kai can publish only where you turn on **Kai may publish** for the app. See [Publishing](#publishing).

## Connect a platform account

<Steps>
  <Step title="Open the Vibe coding settings">
    Go to **Kai Code → Settings → Vibe coding**. Every supported platform is listed with a short line on what Kai can do there.
  </Step>

  <Step title="Connect">
    Choose **Connect** next to the platform. A popup opens the platform's sign-in; sign in and approve Gleap's access. The connection appears as **Connected** with **Connected by** and your name.
  </Step>

  <Step title="Add the apps Kai may work on">
    Choose **Add app** (**Add project** on Lovable, **Add chat** on v0). Gleap lists what your account can reach on the platform; search and pick one to link it to the project. Repeat for every app Kai should work on.
  </Step>
</Steps>

A connection is one teammate's platform account. Everything Kai does on the platform runs as that person, with their account's plan and limits on the platform. The sign-in tokens stay on Gleap's servers; Kai never sees them.

### Who can manage a connection

Teammates with access to the Kai Code settings can see every connection and its linked apps. Because a connection acts as someone's personal account, only **the teammate who connected it, or an admin** of the project or organization, can:

* add apps through it,
* turn **Kai may publish** on or off for its apps,
* reconnect or disconnect it.

Other teammates can start Kai Code sessions on the apps that are already linked.

### Expired connections

If the platform signs Gleap out, the connection shows **Expired** with the reason. The teammate who connected it chooses **Reconnect** and signs in again; the linked apps stay linked.

### Disconnect or remove an app

* **Remove** on an app's row takes it out of the project. Kai Code can no longer pick it; you can add it again later.
* **Disconnect** in a connection's menu ends the connection and removes all of its apps from the project. The apps themselves stay on the platform.

## Fix a ticket in a platform app

Linked apps show up in the Kai Code composer's repository picker, next to your repositories. Pick an app (on its own or together with repositories) and send, or use **Fix with Kai Code** on a ticket. With **Repos: Auto** in a project that has no repositories and exactly one linked app, Kai uses that app.

Kai then works like this:

1. It reads the ticket: the conversation, logs and screenshots.
2. Where the platform allows, it reads the app's code. On Replit it asks Replit Agent how the feature works instead.
3. It sends the platform's agent one focused instruction per problem, with the reproduction steps, the expected behaviour, the evidence and what must stay unchanged. Customer names, emails and other personal data are left out.
4. It waits for the platform to finish, checks the result (the diff or the files where it can read them) and asks for a follow-up change if something is still off. On Base44 it can also correct the code itself.
5. It publishes when allowed, or tells you the change is ready to publish.

Each step shows up in the session and on the ticket's Kai Code card, for example **Asked Lovable to change Shop** or **Published Shop to** with the live URL. The app row in the session links to the live app and to the app in the platform's editor.

Kai only reaches the apps linked to the session, and only through a fixed set of the platform's tools that act on that one app. Account settings, other apps, deleting anything and your app's end-user data are out of its reach.

## Publishing

### Kai may publish

On Lovable, Replit and v0 each linked app has a **Kai may publish** switch. It is off by default.

* **On:** once Kai has verified the fix, it publishes the app and waits for the platform to confirm the new version is live. Only a confirmed publish counts. If publishing fails, Kai says why and the ticket stays open. Lovable refuses to publish while a project has critical security findings.
* **Off:** Kai finishes by saying the change is ready. A teammate publishes it in the platform.

### Base44 and manual publishing

Base44 can't be published from outside its editor, so its apps show **Publish in Base44 after a change**. After a change, open the app in Base44 and click **Publish** there.

Whenever a finished session has a change that nobody has confirmed as live (on Base44, or with **Kai may publish** off), the app row in the session offers **Mark as published**. Publish in the platform first, then choose **Mark as published** so Gleap knows the change is live.

## When the change is live

A session is done once every app it changed has been published since its last change, either by Kai (confirmed by the platform) or marked as published by a teammate. The session then posts **The change is live** with the URL.

From here it works like a merged pull request: your [Customer replies](/documentation/kai-code/customer-replies) setting decides whether a teammate verifies first or Kai replies after the deployment delay. The ticket closes once the customer has been told about the fix. If the session also opened pull requests in your repositories, it waits until those are merged too.

## Install the Gleap widget with Kai Code

Kai Code can add the Gleap widget to an app built on these platforms. On the widget installation page choose **Install with Kai Code**, or, during onboarding, **Built with Replit, Lovable, Base44 or v0?**. Connect the platform, pick the app and start.

Kai installs the widget once, with your project's API key, and changes nothing else. It follows each platform's stack:

| Platform | Where the widget goes |
| - | - |
| **Lovable** | The `gleap` npm package, with `Gleap.initialize("API_KEY")` in `src/main.tsx` before the app renders. |
| **Replit** | The `gleap` npm package, initialized once in the client entry point (`src/main.tsx` or `src/main.jsx` for React and Vite apps). Plain HTML sites get the loader snippet in the shared `<head>`. Never in server code. |
| **v0** | The `gleap` npm package and a small `"use client"` component (for example `components/gleap.tsx`) that calls `Gleap.initialize` inside a `useEffect`, rendered from `app/layout.tsx`. |
| **Base44** | The loader snippet in the `<head>` of `index.html`, or the `gleap` npm package initialized in `src/main.jsx` or `src/main.tsx`. |

The widget only reports from the published app. Where **Kai may publish** is on, Kai publishes and then checks that the widget reports from the live URL. The check succeeds once someone opens the live app, so open the URL once if Kai says it is not confirmed yet. On Base44, or with publishing off, publish the app in the platform to finish the install.

## Requirements

* The **Kai Code** plan feature and the Kai Code permissions described in the [overview](/documentation/kai-code/overview#plan-and-permissions).
* An account on the platform with access to the app. Changes made by the platform's agent run on that account.
* Sessions on platform apps are billed like any other Kai Code session: Kai Code Cloud is billed at API usage pricing (see [Plans and AI pricing](/documentation/guides/ai-pricing-and-credits)), Kai Code Bridge is not billed by Gleap.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.