Connecting Knack to an Existing Lovable App

What You'll Learn

This article walks you through connecting Knack to a Lovable app you've already built, so Knack holds your data, your users, and your access rules while Lovable keeps building your screens. It covers backing up your project, finding out what your app uses today, the order to move things in, and how to prove the move worked.

Before You Start: Why Order Matters

Most Lovable apps start on Lovable Cloud, Lovable's built-in backend. It's on by default, and once a project has it, it can't be turned off. You can only empty it.

Moving to Knack creates a second copy of your data. Until the old copy is cleared, your app is only as secure as its weakest backend. The safe order is to secure Knack first, switch sign-in and data one step at a time, and clear Lovable Cloud last.

The Migration Sequence

Follow these steps in order. Each one depends on the one before it.

Step 1: Back Up Your Lovable Project

Remix your project in Lovable to make a copy before you change anything. Your app's code copies automatically.

Turn on both options in the Remix dialog. One copies your project history, and the other copies the files in your project's Files tab.

For an extra backup outside Lovable, sync the project to GitHub.

Step 2: Find Out What Your App Uses Today

Before building anything in Knack, have Lovable report on the app as it is. This prompt is read-only and asks for structure and counts, not record values, so no personal information ends up in the chat.

Audit only. Do not change any code, data, settings, or connections. Do not create anything in Knack.

Do not show any record values, names, emails, API keys, or secret values. Report structure and counts only.

1. Every table the app uses, with its record count (query the database, don't estimate), every field and its type, and which fields connect to other tables
2. How users sign in today, where accounts are stored, every role, and how many users are in each
3. Where files, images, and signatures are stored, and how many there are
4. Every email, text, notification, scheduled job, backend function, AI feature, and outside service, and what data each one sends
5. If the app already talks to Knack: what credential each request sends, the signed-in user's Knack token or an app-level API key
6. Anything you couldn't count or confirm. Do not guess.

Finish with "Audit complete. No changes made."

Check two or three of the counts in Lovable's Cloud view before trusting the report. Frontend builders can describe an app confidently and still miss what's actually running.

What the report tells you

• Record and user totals tell you which Knack plan fits. User role records count toward your record limit the same as data records.
• Users spread across sign-in accounts, a profiles table, and a roles table is a common Lovable pattern. In Knack, each person becomes one record in one user role table.
• An app-level API key on Knack requests means Knack's access rules aren't protecting anything yet. The key bypasses them.
• Emails, AI features, and outside services each need a decision: keep it, rebuild it in Knack, or remove it. If one would carry health or personal information, review it before you move it.

Step 3: Connect Lovable to Knack

Add the Knack MCP Server to your Lovable project. See Connecting Lovable to Knack: Complete Setup Guide for the connection steps and tool permissions.

Keep tool permissions on "ask each time" while you migrate. You'll see every change before it runs.

Step 4: Plan Your Knack Data Model

Ask Lovable to propose a Knack data model and wait for your approval before it builds. A few of these choices can't be changed later.

Before making any changes, load the Knack MCP skills knack-migration and knack-setup and follow them.

Using the audit you just completed, propose a Knack data model:
1. Every table, its fields, and their types
2. Which tables are user role tables (people who sign in) and which are data tables
3. The connections between tables
4. For every table, who should own each record

Do not use Lovable Cloud for data or sign-in. Do not create a Knack app, tables, or fields until I approve the plan.

Review the plan against these rules before you approve it.

• People who sign in belong in user role tables. A data table can't be converted to a user role table later. Rebuilding means deleting the table and everything in it.
• One record per person. Don't keep a person in both a data table and a user role table. It doubles your record count and splits their information in two.
• Connect every table directly to its owner. Access rules don't travel across a chain of connections. See Designing Your Data Model for Access Control.
• Use the Default Role as the holding role for new sign-ups, with no access until someone approves them. See Choosing a Default User Role for a Custom Frontend.

Step 5: Build Your Tables and Move Your Data

Once you approve the plan, Lovable creates the Knack app, tables, fields, and roles. Open the Knack Builder and confirm each table and field actually exists. Don't rely on the completion message.

Keep the old IDs for matching connections

Lovable stores relationships as its own record IDs. Add a text field to each Knack table for the old ID and fill it during the move, so connections can be matched to the right records.

Move parent tables first, then child tables.

Tell Lovable which dates are calendar dates

Birthdays, due dates, and expiration dates are calendar dates. Ask Lovable to create them as date-only fields. Dates created with a time can display one day early for anyone west of your app's timezone.

Import your data, then fix ownership

Import real data through the Knack Builder. You stay in control of what's sent, and nothing passes through Lovable.

Imported records are owned by the App Builder system user, not your users. If your access rules depend on ownership, batch update Owned By after each import. See Who Owns a Record Created from a Custom Frontend.

Step 6: Set Up and Enforce Access Rules

Set your access rules before your app points at Knack. Lovable can configure them through the MCP, including turning enforcement on.

Setting the rules and turning on enforcement are separate steps. After Lovable reports it's done, open the Knack Builder and confirm three things.

• Enforcement is on
• Each role has the access you planned
• The Public (Not Logged-In) role has No Access to every table

Step 7: Switch Sign-In to Knack

Your users will sign in on Knack's hosted screen. Their passwords never touch your Lovable app.

First, decide on your published Lovable address. Sign-in is registered against it, and changing it later means registering again.

Using the Knack MCP, call loadSkill first.

We're switching sign-in to Knack's hosted sign-in screen.

Step 1 (read-only): Tell me the exact redirect address the sign-in code will use for my published app, ending in /auth/callback with no trailing slash. Stop and wait for my confirmation.

Step 2 (after I confirm): Register one Knack OAuth client with that address. Do not register more than one. Report the client ID.

Step 3: Replace Lovable Cloud sign-in with Knack's hosted sign-in. Do not change how the app reads or writes data yet.

Before you confirm Step 2, compare the address character by character. A typo means another registration.

Step 8: Switch Your Data to Knack

Once sign-in works, ask Lovable to switch data in a separate step. Testing them one at a time tells you which part broke if something fails.

Switch every screen to read and write Knack data using the signed-in user's Knack session.

Requirements:
- Use the signed-in user's token on every request. Do not use a Knack API key anywhere.
- Load all records and handle pagination.
- Show a visible error if a request fails. Never fall back to Lovable Cloud data.
- Do not store any Knack record data in Lovable Cloud.

Report every file you changed.

If staff create records on behalf of someone else, like a patient or a family, ask Lovable to set Owned By to that person when the record is saved. See Who Owns a Record Created from a Custom Frontend for the prompt.

Step 9: Clear Lovable Cloud

Lovable Cloud can't be turned off, so empty it. Ask Lovable to remove every table, stored record, sign-in account, file, and backend function that touches records, plus any Knack API key stored as a secret.

Then add standing instructions to your project's Knowledge so Lovable doesn't start using Lovable Cloud again. The Knowledge File template in Getting Started with the Knack + Lovable Build Kit covers this.

Step 10: Test Before Users Rely On It

Test on your published app, in an incognito window, so no old Lovable Cloud session interferes.

Knack's Test As feature works in Knack Live Apps, not custom frontends. Instead, create one test login for each role and sign in as each one.

For each role, check each of these.

• You see only the records that role should see
• Adding a record in your app creates it in Knack
• Editing a record in your app updates it in Knack
• Deleting a record in your app removes it from Knack
• New records show the right owner in the Knack Builder
• Signed out, every page sends you to sign-in

Then confirm Knack is enforcing your rules, not just your screens hiding records. See Checking That Your Access Rules Actually Work.

Troubleshooting

Next Steps

• Connecting Lovable to Knack: Complete Setup Guide: Set up the MCP connection and build a new Knack app from scratch.
• Who Owns a Record Created from a Custom Frontend: Make sure imported and staff-created records end up with the right owner.
• Checking That Your Access Rules Actually Work: Prove Knack is enforcing your rules.