AN
Teach·Building with Lovable·Lesson 9

Intro to Lovable Cloud

The mental model: auth, database, storage, and AI — what they are and when to use each.

14 min read·5 parts·intermediate

Welcome to the intermediate track. Everything in the beginner lessons lived inside the browser — pages, images, forms that submit into thin air. This lesson is the mental model for what changes when you turn on Lovable Cloud: your site stops being a brochure and starts being an app that can remember things, recognize people, store files, and think.

No code yet. We're building the map first — Lessons 10 to 14 each take one pillar and ship a real feature with it.

Part 1 · From frontend-only to full-stack

A frontend-only site is a set of pages. Every visitor sees the same thing, and nothing they do sticks — when they close the tab, it's gone. That's fine for a portfolio or a landing page. The moment you want users, saved data, or anything smart, you need a backend.

Figure 1.1
Frontend-onlyPages · Components · StylingSame for every visitorNothing is rememberedForms have nowhere to goCloud onFrontend + CloudPages · Components · StylingAuth · Database · Storage · AIUsers can sign inData survives refreshFiles upload, AI responds
Frontend-only is one layer. Turning Cloud on adds a second layer — a place where things persist between visits.
Cloud is opt-in, not always-on
You don't need Cloud for a portfolio, a landing page, or a marketing site. Turn it on the first moment you say the words "users should be able to…" — that's the trigger.

Part 2 · The four pillars

Lovable Cloud is four things wearing one label. If you can hold the four names in your head, you'll always know what to ask the agent for.

Figure 2.1
Auth
The bouncer at the door.

Signs users up, signs them in, remembers who's logged in, and locks pages behind a login.

Database
The filing cabinet.

Tables of rows — users, posts, orders, submissions. What your app remembers between visits.

Storage
The photo library.

Files: images, PDFs, uploads. Kept somewhere durable and served over a real URL.

AI
The intern who can read and write.

Summaries, chat, generation, embeddings — through the Lovable AI Gateway, no API key needed.

The four pillars of Lovable Cloud. Everything you'll build in the intermediate track sits on one of these — or a combination of them.
You will not use all four in every project — and you shouldn't try. Most first apps need one or two.

Part 3 · When to reach for which

The trick to picking the right pillar is to translate the user story into a verb. "I want users to log in" is Auth. "I want to save their entries" is Database. "I want them to upload" is Storage. "I want the app to write something for them" is AI.

Figure 3.1
Users should log in and see their own dashboard
Verb: sign in, see their own.
Pillar: Auth (plus a Database table with row-level rules so each person only sees their rows).
Users upload a photo and the app titles it
Verb: upload, title.
Pillar: Storage for the file plus AI to generate the title.
Two common product asks and the pillar each maps to. When you're not sure, name the verb — the pillar usually follows.

The decision guide

  • "I want users to log in" → Auth
  • "I want to save submissions / posts / notes" → Database
  • "I want each user to only see their own" → Auth + Database (RLS)
  • "I want uploads — images, PDFs, avatars" → Storage
  • "I want summaries, chat, or generated text" → AI
  • "I want admin vs. regular user" → Auth + Roles (Lesson 16)

Part 4 · How it fits together

The pillars aren't isolated. A real feature usually touches two or three of them in one flow. Walking through one end-to-end example makes the whole thing click.

The feature: a logged-in user uploads a photo, the app saves a row, AI captions it, and the caption appears under the image.
Figure 4.1
UserSigns inStoragePhoto savedDatabaseRow insertedAICaption generatedUICaption renderedAuth wraps the whole flow — none of it runs if the user isn't signed in.
One feature, four pillars. Each hop is a single agent request — the pillars quietly cooperate.
  • Auth gates the page. Without it, anyone could upload into your bucket and rack up your storage bill.
  • Storage takes the file and gives you back a URL you can render in an <img> tag.
  • Database stores the metadata — who uploaded it, when, and later, the caption.
  • AI reads the image and returns a caption, which gets written back into the same row.
You don't build this all at once
Build one pillar at a time and get each working before adding the next. Lessons 10-14 do exactly this — one focused mini-project per pillar, then combine.

Part 5 · Turning Cloud on and what to expect

You never have to leave the Lovable chat to turn Cloud on. Ask the agent, in plain English, for anything that needs a backend — "let users sign in", "save contact form submissions", "add an image upload" — and it will enable Cloud as part of the request.

Figure 5.1
  1. 1Ask

    Describe what you want in normal words — 'users should be able to sign in'.

  2. 2Enable

    The agent flips Cloud on. First time only; subsequent features just use it.

  3. 3Scaffold

    Tables, policies, and login screens appear. Read the summary — don't skip it.

  4. 4Build

    You're back to normal Lovable — prompt, preview, publish. The backend just exists.

Enabling Cloud is a single conversation. You never see a dashboard, a config file, or a database password.

What appears in your project

Figure 5.2
lovable.dev/…/backend
Auth
3 users
ahmad@…, sara@…, guest@…
Database
2 tables
profiles · uploads
Storage
1 bucket
photos · 12 files
A rough mock of what shows up once Cloud is on and you've built one feature per pillar. Yours will look different, but the shape is the same.

Safety rails that are on by default

  • Row-Level Security (RLS) — every new table is locked by default. Nobody can read or write it until you (or the agent) writes a policy that says who can. This is the single biggest reason your data won't leak.
  • Secrets stay server-side — API keys and the like are stored as secrets and only your server code can read them. They never end up in the browser bundle.
  • No dashboard trips — you configure Cloud by talking to the agent. You won't be sent to an external console to click around; the agent handles it.
  • AI without keys — the Lovable AI Gateway handles model access. You don't manage an OpenAI key just to generate a caption.
You can build features that shouldn't ship
Turning Cloud on doesn't mean everything is production-safe. You still have to think about who can read what, what's public, and what a hostile visitor could do. That's what Lessons 10, 11, and 16 are for.

Cloud cheat sheet

  • Cloud has four pillars: Auth, Database, Storage, AI. Learn the names.
  • Pick the pillar by naming the verb in the user story: sign in → Auth, save → Database, upload → Storage, generate → AI.
  • Real features usually combine 2-3 pillars. Build one at a time, then compose.
  • Ask, don't configure. The agent enables Cloud when you describe a feature that needs it.
  • RLS is on by default. An empty table is a locked table. Policies are what open the door.
  • Don't turn Cloud on before you have a use case. "I might need it later" is not a use case.

Recap

Frontend-only sites are the same for every visitor and forget everything on refresh. Cloud adds a second layer — Auth for who, Database for what, Storage for files, AI for smarts — and every feature you'll build from here mixes those pillars in different proportions.

Next up, Lesson 10 puts the first pillar to work: a gated dashboard with email/password and Google sign-in, built entirely by talking to the agent.

PreviousPublishing & Custom DomainsNext Auth & Protected Routes