Lovable Cloud — the backend you don't have to set up

The plain-English version

A website that only shows information needs no backend. The moment it must remember something — who signed in, what they saved, what they uploaded — it needs a database and a server. Lovable Cloud is that backend, already wired to your project so you never copy an API key or manage a second dashboard.

Under the hood it is a managed Postgres stack. You get:

• Database — real SQL tables with relationships and constraints.
• Authentication — sign-up, sign-in, password reset, social providers.
• Storage — file and image uploads with access rules.
• Server functions — code that runs on the server for anything that must not run in the browser.
• Secrets — API keys held server-side, never shipped to visitors.

When you actually need it

Turn it on if your app involves any of these:

• User accounts of any kind.
• A form whose submissions you need to read later.
• A list that persists after a refresh — bookings, tasks, products, posts.
• Uploaded images or documents.
• An external API that requires a secret key.
• An admin view of data created by other people.

You do not need it for a brochure site, a landing page, a portfolio, or a calculator that only works in the browser.

Turning it on

Enable the backend for this project.

That single request provisions everything. From then on, describe features in business terms:

Create a bookings table with customer name, email, date, service and status. Only the signed-in owner can see their own bookings; I can see all of them as admin.

You get the table, the access rules and the interface in one pass.

The security part nobody should skip

Every table needs row-level security: rules that decide who can read and write each row. Without them a table is either completely locked or completely open, and "completely open" means anyone who finds your project's public URL can read it.

Say it explicitly, every time:

Enable row-level security. Users can only select, insert, update and delete their own rows. Admins can read everything.

Roles belong in their own table. Never store an is_admin flag on a profile row that the user can edit — that is a one-line privilege escalation.

Server functions: what belongs on the server

Anything with a secret, and anything a user must not be able to fake:

• Calling a paid API with your key.
• Charging a card or verifying a payment webhook.
• Sending email.
• Calculating a price or a score that decides money or access.

Browser code is visible to anyone who opens developer tools. If a value must be trustworthy, compute it on the server.

What it costs

The backend is included with your project rather than being a separate subscription you manage. Your build cost is still the AI messages you spend creating tables, rules and screens. Heavy usage — very large storage or very high traffic — is where resource limits eventually matter, but a typical small business app or internal tool sits comfortably inside normal usage.

Lovable Cloud vs bringing your own Supabase

Cloud is a managed Supabase environment: same database engine, same concepts, no separate signup, no keys to paste, and Lovable manages the connection. Bringing your own project makes sense when an existing database already holds your data, or when your organisation requires the account to sit under its own billing and controls. For a new build, Cloud is faster and has fewer failure points.

A sensible build order

1. Enable the backend.
2. Create the tables, with security rules, before building screens.
3. Add authentication.
4. Build the screens against real data.
5. Add server functions for secrets and payments last.

Building screens before tables is the most common cause of a rebuild halfway through a project.