Builder defaults move. A tester who read Lovable's documentation a year ago would be testing the wrong app today. This post lists what Lovable's docs said on 2026-09-21 about the frontend, the backend, publishing and the security scans, and what each change means for the person checking the app before launch.
Frontend: TanStack Start replaces React + Vite
Lovable's docs state that new projects use the TanStack Start template, the default since 13 May 2026 and since 22 June 2026 for Enterprise. Older projects were built on React + Vite. TanStack Start is a full-stack React framework (a framework that runs code on the server as well as in the browser), where the previous template ran almost entirely in the browser.
What a tester looks at: where code runs. In a browser-only app, every secret and every permission check lives in the visitor's browser, which is why Third-party API key in the JavaScript bundle is so common. With a server layer, some logic can move out of sight. The check is the same in both cases: open the live app's loaded files and search them for anything that looks like a key. What changes is that server routes now exist, and each one needs its own login check.
Backend: Cloud is on by default
The docs state that the built-in backend, Lovable Cloud, is enabled by default for the workspace and uses Supabase's open-source foundation. Every Cloud project includes a managed Postgres database. Lovable sets up RLS policies (Row Level Security, the per-row access rules Postgres applies to each query) automatically when it builds features that store user data. The RLS policies view under Cloud > Database is read-only, and changes go through chat.
What a tester looks at: the policies themselves, not the fact that they exist. An automatically written policy is a good start. The test is whether it says what you meant, and the way to find out is to call the tables as a signed-out visitor and as two unrelated users. Steps for the first pass: Row Level Security disabled on a table.
Secrets follow the same model. The docs state that API keys are stored in the backend, read only by edge functions, and do not appear in app code or the repository. The limit stated on the security best-practices page is that this covers only values you store as secrets; anything written into frontend code is visible to users.
Publishing: two visibility settings, not one
The docs state that apps publish to a .lovable.app subdomain by default, and that on Free and Pro plans anyone with the link can visit the published app. GitHub repositories created by Lovable start private on every plan. Visibility of the published app is a separate setting from visibility of the project itself.
That separation matters because of an incident in Lovable's own history. In April 2026 Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects (Lovable, 2026). A fix shipped within about two hours of the public report (Lovable, 2026). Lovable had already made new projects private by default in November 2025, and it made all historically public projects private after the incident.
What a tester looks at: the project access setting, and what a reader of the project chat would find. Steps: Builder project set to public.
The security scans: Basic and Deep
Lovable ships two scans, and the docs draw a clear line between them.
The Basic scan runs automatically before publishing. It covers RLS policy linting, database schema review and an npm dependency audit (a check of third-party packages against public vulnerability records) that re-runs when dependency files change. The docs state it does not include access-control review, endpoint protection checks or code-level checks.
The Deep scan runs on demand. It adds access-control review, backend endpoint protection checks, code-level checks for exposed secrets, unsafe input handling, insecure storage settings and information leakage, and project-specific issues from what the docs call security memory. It does not run automatically as you work, and the docs state that the tools identify common issues and do not claim complete coverage.
What a tester looks at: the gap between the two scans, and the gap after the second. If the app was published without a Deep scan, the access-control review has not happened at all. If it was, the review looked at code; it did not create two accounts and try to read one user's records as the other. The dependency audit deserves a read too, and the pattern Dependencies with known vulnerabilities explains how to tell a reachable finding from noise.
Where testing comes in
Lovable did its job: it moved to a framework with a server layer, turned the backend on by default, made repositories private and shipped two scans with stated limits. Testing against a defined checklist is a separate job. Our Lovable checklist lists every pattern we test for on this builder, ordered by severity, and the Lovable hub carries the dated defaults this post is based on. Defaults change with the product; every statement above reflects the docs on the date given.
What to do this week
- Run the Deep scan once and read every finding, then verify the access-control items by hand: Row Level Security disabled on a table.
- Check the project access setting on every project in your workspace: Builder project set to public.
- Take the self-check and pick the Lovable stack.