No. A static page needs no database. A small experiment may never leave the builder. Add each piece when you have a reason, not because a diagram had four boxes.

Is Lovable a replacement for GitHub?

No. Lovable writes the code; GitHub keeps the history of it. They serve different purposes and are usually connected.

Where do my API keys belong?

In the environment configuration of whatever runs your server code, and never in files that reach the browser.

Tools8 min readPublished September 19, 2026Updated September 22, 2026

How Lovable, GitHub, Vercel and Supabase work together

Lovable is where the app gets built by AI. GitHub is where the code is stored and versioned. Vercel is where the code runs as a public website. Supabase is where the data and user accounts live. A change flows in that order: built in Lovable, committed to GitHub, deployed by Vercel, reading and writing to Supabase.

Which tool owns which job?

Tool	Owns	Typical symptom when it is the problem
Lovable	Writing and editing the code with AI	The feature was never built the way you meant
GitHub	Storing code history, branches, commits	Your change is not in the repository
Vercel	Building and serving the live site	Works locally, broken on the live URL
Supabase	Database, accounts, files, access rules	Empty lists, permission errors, failed logins

Most confusing bugs get much less confusing once you decide which of these four is responsible. The table above is a triage list, not trivia.

What happens when you make a change?

1You describe the change in Lovable and the AI edits files in the project.
2The change is committed to your GitHub repository, so there is a permanent record of exactly what changed.
3Vercel notices the new commit, installs dependencies, builds the project and, if the build succeeds, puts the result behind your domain.
4When someone uses the live site, their browser or your server talks to Supabase for data and accounts, subject to your access rules.

Why does the live site behave differently from the preview?

Because the preview and the live deployment are separate environments with separate configuration. The most common differences are environment variables that exist in one place and not the other, and a live database that contains real data and real access rules rather than the rows you created while testing.

A secret set locally but never added to the hosting environment.
A redirect or callback URL that points at localhost.
Access rules that never bit you because you were signed in as the owner.
A build step that skips type errors locally but fails in the stricter production build.

Where does MessyDev sit in this?

Not in the middle of it. MessyDev is not a builder, a host or a database — those four tools already do those jobs well. MessyDev is the learning layer beside them: it teaches you what each one is doing, how to test the seams between them, and how to work out which of the four is responsible when something breaks.

What should you check at each seam?

Seam	Check
Lovable → GitHub	Does the latest commit contain the change you expect?
GitHub → Vercel	Did the newest commit trigger a deployment, and did it succeed?
Vercel → Supabase	Are the database URL and keys set for the production environment?
Browser → Supabase	Do the access rules allow this specific signed-in user to read this row?

Frequently asked questions

Do I need all four?: No. A static page needs no database. A small experiment may never leave the builder. Add each piece when you have a reason, not because a diagram had four boxes.
Is Lovable a replacement for GitHub?: No. Lovable writes the code; GitHub keeps the history of it. They serve different purposes and are usually connected.
Where do my API keys belong?: In the environment configuration of whatever runs your server code, and never in files that reach the browser.

Practice this in MessyDev

Reading it once helps. Doing it once sticks. These are the hands-on parts of MessyDev that cover the same ground.