My Lovable app paused because the workspace ran out of credits. What changed, and what do I do?
Since June 2026, building your Lovable app and running it draw from one credit balance. Before, Lovable Cloud (the built-in database, login, storage and server functions) had its own balance. Now, when the workspace balance reaches zero, Lovable's docs say building stops, AI features in deployed apps stop working, and 'apps that rely on the built-in backend (Cloud) can pause'. The published pages keep serving, but the app cannot read or write data until credits are added.
In the next hour: add credits or raise the credit limit, then open the project and resume Cloud. That gets customers back. Then read the usage page to see what consumed the credits, because for a live app with real users it is usually database and storage usage, not building.
The longer question is whether the backend of a live product should sit on the same meter as your prompts. Lovable's Cloud is built on Supabase's open-source foundation and exports cleanly, so moving the backend to a Supabase project or a server in your own name is a known path. This page covers both the quick fix and the move.
In founders’ words
“I originally thought that once I finished building the project, I could just stay on the Pro plan and the ~20 monthly Cloud credits would be enough to keep the database running.”
“Will Cloud or AI usage quietly drain build credits?”
What changed, and when
On June 13, 2026, Lovable announced the change: 'Until now, Lovable workspaces carried two balances: build credits for developing your app, and a separate Cloud and AI balance for everything that happens once it's live (databases, authentication, file storage, server functions, and AI calls). We're simplifying our billing structure with a single balance of credits that can be used across building and running your apps.' Purchased Cloud and AI balances were converted to credits 'at your plan's credit price'. The post also said: 'Your plan price isn't changing.'
The free allowances changed shape. Every Free, Pro and Business workspace gets 20 credits a month for Cloud services, and Free workspaces get 4 credits a month for AI features in live apps, on top of the 5 daily credits for building. Lovable's usage page marks these grants 'Temporary offering, subject to change'.
The part that catches people is what happens at zero. The credits page says: building stops until credits are available; AI features in deployed apps stop working; apps that rely on the built-in backend (Cloud) can pause; the published site keeps serving. The advanced settings page describes the message: 'This project is paused due to a low balance', and the effect: 'While paused, your backend is unavailable, and your published app can't read or write data until you resume.' Storage usage continues while paused, because the data stays in place.
Sources: lovable.dev/blog/simplifying-billing, docs.lovable.dev/introduction/credits-and-usage, docs.lovable.dev/features/project-usage and docs.lovable.dev/features/advanced-settings, read on October 2, 2026.
What it means for your app and your customers
A visitor can load your pages, and then nothing works: no login, no saved data, no uploads, no AI feature. From the outside it looks like the app is broken, not paused. Nothing is lost, by Lovable's account; the data stays in place and the backend resumes when credits are added. But a founder who finished building and went to Pro assuming the 20 monthly Cloud credits would carry a live app has found out at the wrong moment that usage scales with users.
On Pro, a credit is $0.25; on Business, $0.50. Cloud usage is metered on database size, storage, network, compute and realtime features. So the same database costs a Business workspace twice as many dollars per credit as a Pro one, and a quiet month of building can still end with the backend paused if the app got traffic.
What to do in the next hour
- Add credits or raise the workspace credit limit, whichever stopped it. The message says which.
- Open the project, go to More, Cloud, Overview, and resume the paused backend. Lovable's docs say add credits or adjust the limit first, then wake the project.
- Open Plans & credit usage. It shows which project, which member, and whether credits went to building or running, down to which AI model your app called.
- Pause Cloud on projects that are not live, delete unused storage files (they bill while paused), and remove Cloud from projects that never needed a backend, after exporting anything in them.
- Set a credit limit you will notice before customers do, and put the usage page in your weekly routine.
Your options
Stay on Cloud and manage the meter. Fair for an app with light traffic or no revenue. The usage dashboard is good now, and the grants cover a small app. Keep a database export in hand regardless; it is one click and arrives by email.
Keep Lovable for building, move the backend to your own Supabase project. Lovable supports connecting your own Supabase instead of Cloud, and its guide covers the migration. Your database, login, storage and functions then bill under Supabase's own plan, in your account, and credits only pay for building. Lovable says there is no one-click migration; it is an export, a restore and a reconnect.
Move the backend to infrastructure you run, or move the whole app. Self-hosted Supabase on a server you control, or a different backend entirely, with the frontend on a host of your choosing. More to run, nothing metered against your prompts.
Why this is a good moment to own the backend
A live app's database should not stop because the person building it ran out of prompts. On a backend in your name, the database bill is a database bill, the login keeps working while you take a month off from building, and your customers never see a pause caused by your workspace.
The cost is that backups, security policies, sign-in configuration and monitoring become yours. Lovable's own guide lists them honestly. They are known jobs with known answers, and for an app built on Cloud, the destination (Supabase) matches the source closely enough that most of the move is export, apply, restore and test. With guidance it is days to a couple of weeks, with the old backend still live throughout. Our free call reads your usage and your app and tells you whether you need any of this.
What a move involves, step by step
This follows Lovable's own sequence: keep the app on Cloud while you prepare the destination, and switch only when it is complete.
- Code. Turn on Git sync (all plans) so the repository in your GitHub holds the app and its migration files. Run it on your own computer once.
- Database and files. Request Export project data from Cloud's advanced settings: the full database, structure and records, including user accounts and password hashes, up to 15 GB, once per 24 hours, delivered by email and saved to the project's storage. Storage files are separate; download them from the Storage view. Create the destination Supabase project (or self-hosted Supabase), apply the migration files from the repository in order, restore the export, upload the files into matching buckets.
- Sign-in and users. Users keep their passwords after the restore. Re-enable each sign-in provider (Google, Apple, email) at the destination, update redirect URLs, and expect signed-in users to sign in again.
- Secrets. Function secrets and API keys are not exported. Enter them at the destination and rotate the ones that matter.
- Payments. The Stripe account is yours already; the webhook endpoint and the function that handles it move with the server code. Test in test mode on the new deployment.
- Domains and email. The published site can stay on Lovable while the backend moves. If the frontend moves too, point the domain last and set up sending from your own domain early.
- AI providers. AI features that ran through Lovable's gateway (and its credits) become calls on your own provider key. App connectors that ran through Lovable are rebuilt as your own integrations.
- Test before switching. Point a test deployment at the new backend, run sign-in, reads, writes and uploads with migrated accounts, then take a final export during a short pause in writes, restore it, update the project's environment to the new backend, and switch. Lovable's guide says to measure export and restore times on the test run first, because they set the length of the pause.
When you may not need to move
If the app has a handful of users and the monthly grant covers it, if you are still building more than running, or if nobody pays yet, stay on Cloud, set a credit limit and keep an export. The unified balance is simpler for that case, and the dashboard tells you where credits go.
Move the backend when real customers depend on the app, when usage has outgrown the grant and the credit price makes a database cost more than a database should, when a customer asks for backups or data location you can speak to, or when you want the app to keep running while you stop building for a while.
| Part of your app | How it moves | What to know |
|---|---|---|
| Database structure and security policies | Migration files in the repository, applied in order | Includes tables, indexes, row-level security, functions, triggers |
| Table records | Export project data, then restore | Up to 15 GB; one export per 24 hours; CSV per table also available |
| User accounts | In the database export, with password hashes | Users keep passwords; sign-in providers configured again |
| Storage files | Download and upload by hand | Not in the database export |
| Server functions and scheduled jobs | Code in the repository; deployed with the Supabase CLI | Secrets set separately; recreate missing schedules |
| Secrets and API keys | Re-entered by hand | Not exported; rotate while you are there |
| AI features and app connectors | Replaced with your own provider accounts | They ran through Lovable's gateway and credits until replaced |
Questions
What happens when my Lovable credits run out?
Building stops until credits are available, and work in progress pauses. AI features in your deployed app stop, because each model call needs credits. Built-in backend services (database, storage, sign-in) pause shortly after the balance hits zero. Your published pages keep serving, and the data stays safe, but Lovable's docs say you cannot access or export it until the services run again. Chat continues while the daily chat allowance lasts.
What happens when Lovable credits run out with a published app?
The pages still load, and then the parts that need the backend fail: no sign-in, no saved data, no uploads, no AI answers. To a visitor it looks broken. Add credits or raise the limit, resume the backend, and turn on auto top-up with a threshold well above zero so a busy week cannot pause the app again.
Can I buy more Lovable credits, and do they roll over?
Yes, on Pro and Business: one-time top-ups or auto top-up, and top-up credits last 12 months. Free plans have to upgrade to buy more. Unused monthly plan credits roll over while your subscription is active, but they still expire, two months after they were issued on a monthly plan. Daily and monthly usage grants, such as the Cloud and AI allowances, do not roll over.
Why is Lovable burning through my credits?
Usually one of three things. Rounds of fixes: each Build mode message costs more the more it explores and changes, and a loop of 'try to fix this' prompts adds up fast. A live app: database size, storage, traffic and background code are billed in the same credits once people use it. AI features: every model call your app makes costs credits. Plans & credit usage shows which project and which kind of usage, and each message's cost is under Credits used in its menu. Asking in Plan mode first (one credit a message plus any research) and reverting after two failed fixes cut the building side.
Did I lose data when the project paused?
Lovable's docs say the data stays in place while paused and storage usage continues for that reason. Add credits, resume the backend, and check a few recent records. Then take an export so you hold a copy.
Is my published site down?
The pages keep serving. What stops is the backend: login, database reads and writes, uploads, functions and AI features. To a visitor that looks like a broken app, which is why the fix cannot wait.
Did Lovable raise prices in June 2026?
Lovable's announcement says plan prices, credit prices, daily free build credits and the cost of Cloud and AI services did not change. What changed is that one balance pays for everything, and the free Cloud and AI allowances became credits (20 Cloud credits a month on Free, Pro and Business; 4 AI credits on Free) marked as temporary.
Can I connect my own Supabase and keep building in Lovable?
Yes. Lovable supports connecting your own Supabase project instead of Cloud. For an existing Cloud project there is no one-click switch: you export the data, apply the migrations in the new project, restore, and point the app at it.
How do I stop this happening again without moving?
Set a workspace credit limit with headroom, read Plans & credit usage weekly, pause Cloud on projects that are not live, delete storage you do not need, and keep a current export. If usage keeps climbing with real users, that is the signal to move the backend.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.