DEV Community: Aakash Verma

In-App Purchases in a Lovable App: Stripe or Apple?

Aakash Verma — Sun, 25 Oct 2026 00:04:52 +0000

If your Lovable app sells a subscription or unlocks features, the web version can keep using Stripe, but the iPhone app usually can't. Apple's guideline 3.1.1 says that to "unlock features or functionality within your app", like subscriptions or premium content, "you must use in-app purchase". The one big exception since 2025 is the United States storefront, where apps may link out to their own checkout. Everything below was checked against Apple's App Review Guidelines on October 23, 2026.

This catches Lovable founders more than most, because the web app already works. Stripe Checkout opens, the webhook flips is_pro in Supabase, done. Then the same flow ships inside a Capacitor app, and the review comes back citing 3.1.1.

What actually counts

Apple cares about what is being sold, not how.

Digital things used inside the app need in-app purchase: subscriptions, credits, premium features, content. A Lovable SaaS with a Pro plan is squarely in this group.

Physical goods and real-world services don't: a shop selling t-shirts, a booking app for haircuts, a marketplace taking a cut of a delivery. Keep Stripe for those, inside the app too.

Things bought elsewhere can be used in the app. Under 3.1.3(b), someone who subscribed on your website can sign in on the iPhone and get Pro, as long as the subscription is also available as an in-app purchase in the app. That last condition is the one people skip.

And the US exception: on the US storefront, guideline 3.1.1(a) now says entitlements "are not required" for buttons and external links to other ways to pay. So a US-only app can show "Upgrade on our website" and send people to Stripe. In every other storefront that button is still a rejection unless you hold Apple's External Purchase Link entitlement where it's offered. Most Lovable apps sell worldwide, so most of them need in-app purchase anyway.

What each option costs

On a $9.99 a month subscription:

Stripe on your website: 2.9% + 30¢ per US card payment (Stripe pricing), so $0.59, and you keep $9.40. Stripe Billing adds 0.7% if you use it for the subscription logic.
Apple in-app purchase: 15% if you're in the App Store Small Business Program (under $1 million in proceeds the year before, and new developers qualify), so you keep $8.49. Above $1 million it's the standard 30%. You have to apply for the 15%; it isn't automatic.
Google Play has its own billing rules and service fee; check Google's payments policy for your countries before assuming Stripe is fine on Android.

The 15% hurts a bit less once you remember what it buys: on a phone the purchase sheet is Face ID and done, with no card form to type into. I'd still keep the web checkout for people who find you on the web. Same price everywhere is the simplest policy; some apps charge more in the app to cover the fee, which Apple allows.

Where RevenueCat fits

The hard part of in-app purchase isn't the purchase sheet. It's knowing, in your Supabase database, who is subscribed right now, across Apple, Google and Stripe, with renewals, refunds and grace periods. You can build that yourself with App Store Server Notifications and Google's real-time developer notifications. Or you use RevenueCat, which does exactly that and has a Capacitor SDK (@revenuecat/purchases-capacitor).

Its pricing, checked today: free up to $2,500 of monthly tracked revenue, then 1% of what it tracks. For a Lovable app that's starting out, that's free for a long time, and by the time you pay $25 a month for it you're making $2,500. I'd use it. The thing I don't like is that "is this user Pro?" now lives in a third place, so we always mirror the entitlement into a Supabase column with a webhook, and the app's RLS policies read that column, not an SDK call.

How it plays out in a real project

The order we use: set up the products in App Store Connect and Google Play Console first (they need tax and banking info, and Apple reviews each new subscription with the app), add the SDK to the Capacitor project, keep the existing Stripe flow on the web, and hide the Stripe button inside the iOS app outside the US. The paywall screen in the app needs the price, the period and links to your terms and privacy policy, or review sends it back.

If a 3.1.1 rejection is what brought you here, our App Store rejection fix is $350 flat and resubmitted within 3 days. If the app isn't in the stores yet, payments are part of publishing your Lovable app to both stores.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable on Coolify: Host It on Your Server

Aakash Verma — Fri, 23 Oct 2026 23:49:11 +0000

You can move a Lovable app onto your own server with Coolify: point Coolify at the GitHub repo Lovable syncs to, build it as a static Vite site with dist as the publish directory, add one Nginx line so page refreshes don't 404, and put your domain on it. As of October 2026 self-hosted Coolify is free, Coolify Cloud is $5 a month for up to two servers, and the server itself is the real bill (Hetzner's CAX21, 4 ARM cores and 8 GB, is €10.49 a month after their June price rise).

That moves the front end. Whether it moves the whole app depends on where your database lives, and that's the part most "self-host Lovable" threads skip.

What actually moves

A Lovable project is two things wearing one name. There's the React app Lovable writes (Vite, TypeScript, Tailwind), which compiles to a folder of static files. And there's the backend: on Lovable Cloud that's a Supabase project Lovable runs for you, with your tables, auth users, storage buckets and edge functions.

Coolify takes the first one easily. The second one stays exactly where it is unless you move it on purpose. So after a Coolify deploy you have your own server serving the pages, and the pages still talk to Lovable Cloud for every login and every query. That's a perfectly good setup if what you wanted was your own hosting, your own headers and no Lovable badge. It is not "off Lovable".

If you want the data on your side too, there are two roads. Move it to a Supabase project you own (that's the Cloud to Supabase migration we do in 1 to 2 days), or run self-hosted Supabase as a Coolify service on the same box. The second one is cheaper on paper and more work forever after: you own the backups, the Postgres upgrades and the 3 a.m. disk alert. Lovable also can't manage a self-hosted database, so new tables and policies become a developer's job instead of a chat message.

The Coolify settings that work for a Lovable repo

Coolify's own minimum is 2 CPU cores, 2 GB of RAM and 10 GB of disk, on Ubuntu, Debian or most other Linux distributions, amd64 or arm64. The install is one command on a fresh server:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

It prints the next steps when it finishes. Then, in the dashboard:

Add a new resource from your GitHub repo (install Coolify's GitHub App so it gets push webhooks; Lovable's GitHub sync pushes to the default branch, so every Lovable edit redeploys).
Build pack Nixpacks, Site type Static, Publish directory dist.
Add your VITE_ variables if the repo doesn't already carry them in .env. In Coolify's environment variables screen, leave Build time set to Available during build, because Vite bakes these into the JavaScript at build time. A variable that's only available at runtime does nothing for a static site.
Generate the Nginx config under General and add the single-page fallback (below), then deploy.
Add your domain and let Coolify's proxy fetch the certificate.

The refresh 404 everyone hits once

Lovable apps use client-side routing. Nginx doesn't know that. Open /dashboard from the home page and it works, because React Router handled it in the browser. Hit refresh on /dashboard and Nginx looks for a file called dashboard, finds nothing and returns its plain white "404 Not Found" page.

The last founder who showed me this had already blamed Cloudflare, then the DNS, then Coolify. It's one line in the location / block:

try_files $uri $uri/ /index.html;

Coolify copies the Nginx config into the image at build time, so you have to redeploy after changing it. A restart reuses the old image and the 404 stays, which is a fun extra hour if nobody tells you.

What it costs, honestly

For the front end alone, self-hosting saves less than people expect. Static files are cheap to serve anywhere, and Lovable's own hosting is included in the plan you're probably keeping anyway, because you still build in Lovable. The money starts to matter when the backend moves too: a Lovable Cloud instance at the bigger sizes costs more per month than a whole 8 GB server running Coolify plus self-hosted Supabase.

So here's my actual opinion. If your Lovable Cloud bill is small, don't self-host for the money. Do it if you need control (headers, a region, a server you can SSH into, one bill for several apps). If the bill is large, move the backend first, because that's where the savings are, and decide about the front end after.

Not sure which camp you're in? The free Lovable cost check reads your repo and prices four ways forward, including the Coolify server route, next to what you pay now.

Things that break after the move

Auth redirect URLs are the big one. Supabase only sends magic links and OAuth callbacks to URLs on its allow list, and your new domain isn't on it until someone adds it. Do that before you switch DNS, not after the first user writes in saying the login link opens the old site.

Edge functions don't come along. They keep running where your backend runs, and the front end on Coolify calls them there, which is fine until you move the backend and forget them.

And Lovable's preview keeps working, because it never needed your server in the first place. That's handy: you keep building in Lovable, push, and Coolify ships it a minute later.

If you would rather have someone set this up with the database move done properly, that is a fixed-price job for us: your Lovable app on your own server is $500 to set up, plus the Cloud move if you need it. Or tell us about your app.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

How to Use TestFlight for Your Lovable App

Aakash Verma — Fri, 23 Oct 2026 00:34:52 +0000

To use TestFlight with a Lovable app, wrap it with Capacitor, archive the iOS project in Xcode and upload the build to App Store Connect, then add testers on the app's TestFlight tab: up to 100 internal testers from your App Store Connect team with no review, or up to 10,000 external testers by email or public link once Apple has reviewed your first build. Each build can be tested for 90 days (Apple's TestFlight docs, checked October 20, 2026).

That's the whole mechanism. What follows is the part the docs don't tell you, which is how a web app built in Lovable behaves when real people install it from TestFlight instead of opening a preview link.

Why bother, when Lovable already has a preview

Because the preview is a website and TestFlight is the app. Everything that goes wrong on iOS goes wrong in the native shell: the keyboard covering your login button, the status bar sitting on top of your header, a deep link opening Safari instead of the app, push permission prompts that never appear. None of that shows up in the Lovable preview on your phone's browser.

TestFlight is also the dress rehearsal for App Review. The first external build goes through Apple's review against the same App Review Guidelines, so a WebView-shaped app that would get a 4.2 rejection tends to hit trouble here first, while nothing public is at stake.

Getting the build up

You need a paid Apple Developer account ($99 a year) and a Mac with Xcode. From the Capacitor project:

npm run build
npx cap sync ios
npx cap open ios

In Xcode, pick Any iOS Device (arm64) as the target, then Product → Archive. When the Organizer opens, choose Distribute App and the App Store Connect option. Xcode signs and uploads it. Expect the build to sit in "Processing" in App Store Connect for anywhere from five minutes to an hour.

Two things stop first uploads more than anything else. The build number has to go up every single time (Xcode's Build field, not the version), and the export compliance question will be waiting for you. Most Lovable apps only use standard HTTPS, which Apple treats as exempt encryption, and you can answer once in Info.plist with ITSAppUsesNonExemptEncryption set to NO so it stops asking. If your app does its own cryptography, answer honestly instead.

Internal or external: pick based on who's testing

Internal testers have to be users in your App Store Connect team with a role like Admin, Developer, App Manager or Marketing. Up to 100 of them. Builds reach them as soon as processing finishes, and you can set new builds to go to them automatically. This is for you, your cofounder and the freelancer who's fixing the safe-area padding.

External testers are everyone else, up to 10,000. You create a group, add a build, and that first build goes to App Review. Apple's page says a review is required only for the first build and later ones "may not require a full review", which in practice means most updates go out fast and now and then one sits for a day. Invite people by email, or turn on a public link and paste it wherever your users are. You can also limit the public link by device type and OS version, which is handy if you only want iPhone users on a recent iOS.

We had a founder send the public link to a 2,000-person waitlist on a Friday night. Good news: 340 installs over the weekend. Bad news: the app's sign-up email still pointed at the Lovable preview domain, so every confirmation link opened a browser tab instead of the app, and the TestFlight feedback inbox filled with screenshots of the same broken page. Test the auth emails with two people before you test with two thousand.

Reading what testers send you

Testers on current TestFlight can send feedback from inside your app by taking a screenshot, and it lands in the TestFlight Feedback section of App Store Connect with the device and OS attached. That's genuinely useful for layout bugs, because "the button is cut off" arrives with the iPhone model that cuts it off.

App Store Connect also shows sessions and crashes per build. A Capacitor app that crashes on launch usually has a missing permission string (camera, photo library, location) in Info.plist. iOS kills the app the moment it asks for that permission without one, and in TestFlight it looks like a crash with no explanation.

The 90-day thing

Every build stops working 90 days after upload, and testers see it expire. If you're using TestFlight as a slow-motion soft launch, which plenty of people do, you need to upload a fresh build before that date or your testers get locked out. Upload a new build every few weeks anyway. Testers stay in their groups across builds, so nobody needs to be re-invited.

When it's ready for the real store

Once a build has been through external testing without nasty surprises, you submit the same build for App Store review from the app's distribution page. No new upload needed. How the launch runs in both stores is on publish your Lovable app to the App Store and Google Play. If you'd rather not fight Xcode signing and the review notes yourself, we help with the submission and the reviewer's questions on every package (see the packages), or just ask us what your app needs.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable Cloud Pricing: How to Cut the Bill

Aakash Verma — Thu, 22 Oct 2026 01:13:22 +0000

Lovable Cloud pricing has no price list of its own: your app's database, storage, traffic and backend code are paid in run credits from the same balance you build with, and top-up credits cost $0.30 each on Pro and $0.60 on Business (Lovable's docs, checked October 19, 2026). To cut the bill, open More → Cloud → Usage, see which category leads, and fix that one first. It is almost always the instance size, a scheduled job that never lets the backend sleep, or files nobody deletes.

That's the short version. The rest is how to read the page and what to change, because the fixes are not equal and some of them cost you more than they save.

Read the Usage view before you touch anything

The Usage view charts your project's run credits per day for the last 30 days (you can switch to 90) and sorts the spend into six buckets: Database (split into Database server and Database storage), AI, Compute, Network, Storage and Realtime. The number next to each bucket is credits, not dollars. Multiply by what you pay per credit if you want a dollar figure.

Two things on that page catch people. First, the total shows how much of it your monthly grant covered. Right now every Free, Pro and Business workspace gets 20 credits a month for Cloud and 4 for AI features in deployed apps. Lovable labels both "temporary, subject to change", so don't build a budget on them. Second, if the project burned more than 5 run credits in the last 7 days, owners and admins get an Optimize your usage button. It starts a chat that investigates the spend, and that chat is normal build usage, so it costs credits too.

The fixes, in the order they usually pay off

Check which instance you're really on. Lovable renamed the database sizes on July 31, 2026: the old Medium is now called Large, the old Large is X-Large, the old X-Large is 2X-Large, and a new, smaller Medium sits between Small and Large. Hourly prices didn't change, but plenty of founders who "picked Medium" in the spring are paying for what the dialog now calls Large without knowing it. Go to More → Cloud → Overview → Advanced settings, open Manage instance, and read the Estimated cost under each size. Lovable bases those estimates on your last 30 days of usage, which makes them more honest than any number I could give you here.

Don't downsize on a hunch, though. The CPU, Memory and Disk cards above it show 24 hourly segments, and a highlighted one means the database was close to its limit that hour. One red hour after a launch email is fine. A week of red afternoons means the instance is too small and shrinking it will make the app slow, which costs more in lost users than the credits you saved. A resize takes a few minutes with a short restart, so do it at night.

Find the job that keeps the lights on. Lovable pauses idle Cloud projects automatically, which is why a side project with no traffic costs close to nothing. That automatic pause does not apply to projects with scheduled jobs. We looked at a booking app last month where Compute was the top bucket every single day, including days with zero bookings. The cause was a job that ran every minute to expire unpaid reservations. Nobody had touched it since the first prompt that created it. Moved to once an hour, the daily Compute line dropped to a sliver and the app behaved exactly the same. Open Jobs in the Cloud tab and look at the schedule column before anything else.

Delete files, because paused isn't free. Stored files keep using credits even while a project is paused. If your app lets users upload photos and never cleans up abandoned drafts, Storage grows forever. A cleanup job that runs daily (yes, a job, but a cheap one) or a size limit on uploads fixes it.

Fix the slow queries. A query that scans a whole table on every page load shows up as Database server time. Ask Lovable in the chat to find the slowest queries and add indexes. This one costs build credits up front and pays back slowly, so do it after the three above.

Pick a cheaper model for AI features. The AI bucket is charged per call by model and tokens. A support bot that sends the whole chat history with every message on the biggest model is the classic one. A smaller model for the first answer and shorter context usually halves it.

The top-up price trap on Business

This one is just arithmetic. A one-time top-up is $15 for 50 credits on Pro and $30 for 50 credits on Business, so a Business workspace pays twice as much for every extra credit its live app burns. If you upgraded to Business for SSO or team features and your app's Cloud usage runs past the plan's credits every month, compare that against a bigger Pro plan before the next renewal.

Whatever plan you're on, set a monthly spend limit on auto top-up (Workspace settings → Plans & credit usage → Add credits → Auto top-up). Without one, a bot hammering your signup form can top you up all weekend. With one, the worst case is the backend pausing until you add credits, and your published site stays up while that happens.

When trimming isn't the answer

Some apps are simply busy, and that's the good problem. Once the Usage view shows Database server and Network as the two biggest lines on normal traffic, you're paying Lovable's markup on infrastructure you could run on your own Supabase project, with a bill in dollars you can read line by line. Our free Lovable cost check scans your repo and shows what the same app would cost on its own backend, and moving from Lovable Cloud to Supabase takes us one to two days with your data and users included. Prices are on the pricing page.

If you'd rather someone else read the Usage page with you, send us a note with a screenshot of it.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

What It Costs to Turn Lovable Into an App

Aakash Verma — Tue, 20 Oct 2026 23:54:40 +0000

Turning a Lovable app into an iPhone and Android app costs $124 in store fees in the first year ($99 a year for Apple's Developer Program, $25 once for Google Play) plus the build itself, which with us is a fixed $300, $600 or $1,000 depending on how many screens the app has. So a typical 10-screen Lovable app lands at about $724 for year one, and $99 a year after that, before the stores take their cut of any sales.

People searching "how much does it cost to make an app" get quotes from $5,000 to $150,000, and those numbers are real for apps built from nothing. Your situation is different. The screens, the logic and the Supabase backend already exist in your Lovable project, and most of the cost of an app is building those.

The fees you can't avoid

Apple: $99 a year. That's the Apple Developer Program. You need it for TestFlight and the App Store, and it renews every year. If the app stops being paid for, it disappears from the store. Enrolling as a company instead of a person also needs a D-U-N-S number. The number is free, but getting one can take a week or more, and nobody warns you about that until you're stuck on the form.

Google: $25, once. The Google Play Console registration fee is a one-time US$25. The catch is time, not money: a new personal developer account has to run a closed test with at least 12 testers for 14 days before Google lets the app go to production. Line up those 12 people early. Your friends will forget to open the test link.

The cut, if you sell anything. Both stores take 15% of digital sales for developers under $1 million a year (Apple's Small Business Program has to be joined, it isn't automatic). If your Lovable app sells a subscription through Stripe, the native version may have to sell it through in-app purchase instead, and that changes your margins and some of your code. Physical goods and services, like bookings or deliveries, can keep Stripe.

The build: where the real money goes

There are two ways to do it, and the price difference between them is smaller than people expect.

Capacitor, from the same code. Your Lovable project becomes the app. We add the native pieces Apple wants to see before it approves anything (push notifications, a proper splash screen, offline handling, the share sheet), build it for both stores, and submit it. You keep building in Lovable, and every change ships to the web and to the apps. This is the default for most founders because it doesn't fork the codebase. You can compare it with React Native here.

A native rebuild in React Native or Flutter. Same Supabase backend, new front end. It makes sense for apps people live in all day: a feed, chat, maps, video. It's more work for us, but we price both paths the same, so pick the one that suits the app.

Our packages, for either path: $300 up to 5 screens, $600 up to 15, $1,000 for 25 and more. Count your screens honestly. A settings page with three tabs is three screens. The full breakdown is on the home page.

If you'd rather do it yourself, the build costs you nothing but time. Capacitor is free, and you can build Android on any laptop. For iOS you need a Mac with Xcode, and a few evenings to get through signing certificates, provisioning profiles and App Store Connect. One founder told us they spent a full weekend on the "No signing certificate found" error alone, and then the first submission came back under guideline 4.2 because the app was a plain wrapper. That rejection is the common one, and it's fixable.

What it costs after launch

Less than you'd think, but not zero.

Push notifications through Firebase Cloud Messaging are free. Your Supabase or Lovable Cloud bill doesn't change much because app users hit the same backend as web users. What does cost money is keeping up with the platforms. Apple and Google raise their minimum SDK targets every year, Capacitor ships a major version roughly yearly (Capacitor 8 came out this year), and an app that isn't updated for a year or two gets flagged or pulled. Budget a small update once or twice a year. For most apps that's a day of work, not a rebuild.

The other running cost is review time. Every update goes through Apple's review again, usually in a day, occasionally with a rejection over a screenshot or a missing account-deletion button. That costs time rather than money, but it's real.

The honest total

	Year one	Every year after
Store fees	$124	$99
Build with us (10 screens, $600 package)	$600	-
Platform updates	a day of work, if a new OS lands	a day of work, once or twice
Store cut on digital sales	15% under $1M	15% under $1M

Around $724 to get a 10-screen Lovable app onto both stores, versus five figures for an app built from scratch. The difference is the work you already did in Lovable.

Want a fixed quote for yours? Tell us about the app and how many screens it has.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable Hosting: What You Get and Pay For

Aakash Verma — Tue, 20 Oct 2026 01:09:31 +0000

People ask us about Lovable hosting as if it were a separate product you pick, like Netlify or Vercel. It isn't. When you hit Publish, Lovable hosts the app, and there is no hosting plan to compare, no server size to choose and no bill that says "hosting" on it. That is mostly good news. The part that confuses people is everything around it: which bits cost credits, what a custom domain needs, and what actually happens when you try to host a Lovable app somewhere else.

Everything below was checked against Lovable's own docs on October 17, 2026.

What Lovable hosting gives you

Publishing takes a snapshot of your project and puts it live on a lovable.app address. HTTPS is set up for you, including on a custom domain, and the site is served from locations around the world, so a visitor in Sydney isn't waiting on a server in Virginia. The snapshot part matters more than people expect: whatever you change after publishing stays in the editor until you click Publish changes. Half the "my fix didn't go live" messages we get are this.

Publishing to lovable.app is free on every plan. A custom domain needs a paid plan. Your plan doesn't cap visitors or bandwidth either, with one exception: on the Free plan, apps created from May 13, 2026 get 1,000 server requests per project per 10 seconds, and anyone over that sees an "App temporarily unavailable" page for a minute. Fine for a side project, a bit nervy if you're about to be on a podcast.

Hosting is free. The backend isn't.

This is the line to remember. Lovable's docs say a live site doesn't consume credits on its own. What costs money is the work your app does while it runs: database reads and writes, file storage, network traffic, edge functions and any AI calls your users trigger. Those all draw from the same credit balance you build with, under the name run credits. There is a temporary grant of 20 Cloud credits a month on Free, Pro and Business, plus 4 for AI, and anything above that comes out of your credits.

So "how much does Lovable hosting cost" has an annoying answer. The pages are free, and the app behind them is metered. A brochure site with a contact form costs close to nothing. A marketplace where every page load runs six queries and a thumbnail resize does not, and that bill grows with your users, not with how much you build. If you want the number for your own app, the free Lovable cost check reads your repo and estimates what running it costs on Lovable Cloud and on three other setups.

Running out of credits doesn't take the site down, by the way. The pages stay up, but anything that leans on the backend or AI can pause until credits come back, and a paused backend might need you to open More, Cloud, Overview and click Wake up. A site that loads with every form broken is arguably worse than one that's down.

Hosting a Lovable app somewhere else

You own the code, and you can host it anywhere. How hard that is depends on which of two stacks your project is on, and most guides online were written before the second one existed.

Older React + Vite apps build to a folder of static files in dist/. Any static host works: Netlify, Cloudflare Pages, an S3 bucket behind CloudFront, plain Nginx. The only gotcha is client-side routing. Without a fallback to index.html, every deep link like /dashboard/settings returns a 404 on refresh, and you'll find out from a user, not from testing the home page.

TanStack Start apps, which is every project created from May 13, 2026, render on the server. They need a host that runs code, not one that only serves files. The build uses Nitro, which picks a preset for the platform it detects. Vercel, Netlify and Cloudflare Pages are detected automatically. For a VPS or a container you build with NITRO_PRESET=node-server npm run build and run it with Node 22.

We had a founder last month who moved a new TanStack Start app to Netlify by dragging the dist folder into the deploy box, the way he'd done with an older project. The home page loaded fine, so he switched the domain. Every server function returned a 404, which meant signup was broken for about six hours before anyone wrote in. Static upload versus a real build from the repo, and the difference didn't show up on the one page he checked.

To find out which stack you're on, open package.json in the Code tab. If it lists @tanstack/react-start, you're on the new one.

The frontend is the easy half

Moving the pages takes an afternoon. What people really want, nine times out of ten, is to stop paying run credits for the database, and that means moving the backend. If you only move the frontend, your app keeps talking to Lovable Cloud, and the metered part of the bill doesn't change at all.

The environment variables are where this bites. A TanStack Start app on Cloud needs four values on the new host: VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY for the browser, SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY for the server. The VITE_ ones are baked in at build time, so setting them after the build does nothing. Then add your new URL to the sign-in redirect list, or login will bounce people back to the old domain.

Moving the backend is a different job: your database, users, storage files, edge functions and secrets go to your own Supabase project, and the app gets pointed at it. Lovable's export covers the database and users, but the rest you carry over by hand. That's the job we do as a fixed-price Cloud to Supabase migration, and you can keep building in Lovable afterwards.

Should you leave Lovable hosting at all?

Mostly no. If your app is a frontend plus a modest backend, Lovable hosting is fast, has HTTPS and a CDN, and costs you nothing until the backend works hard. We'd leave it alone.

Move the frontend when you need your own deployment pipeline, a compliance rule says where the app must run, or you're adding a second app that shares the codebase. Move the backend when run credits have become a real line on your bill, or when you need things Cloud doesn't give you: your own Postgres extensions, direct database access for a reporting tool, a staging copy of production data.

If you're somewhere in between and not sure which half is costing you, run the cost check first. If you'd rather hand the whole move to someone, our pricing is on the site.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable to React Native: What Carries Over

Aakash Verma — Mon, 19 Oct 2026 02:57:34 +0000

"It's already React, so moving my Lovable app to React Native should be quick, right?"

We hear some version of this every week, and the answer is "partly". Lovable gives you React, TypeScript, Tailwind, shadcn/ui and Supabase. React Native shares exactly one of those with the web in any meaningful way, and it's the first one. Knowing which parts survive the move is most of the estimate.

The parts you keep

More than people expect, as long as the Lovable code wasn't written with everything crammed into components.

Your Supabase backend doesn't move at all. Same tables, same row level security policies, same edge functions. The mobile app is just another client. @supabase/supabase-js runs fine in React Native, you need import 'react-native-url-polyfill/auto' at the top of the client file and that's about it.

TypeScript types, the generated Database type from Supabase, zod schemas, date helpers, price formatting, validation rules: all of that copies straight into a shared/ folder. So do the TanStack Query hooks, if Lovable used them (it usually does). A hook like useOrders() that calls Supabase and returns data has nothing web-specific in it.

If your business logic lives in those hooks, you're in good shape. If it lives inside a 600-line Dashboard.tsx mixed with JSX and className strings, the first job is pulling it out, and we do that on the web codebase before writing a single native screen.

The parts you rewrite

Every screen. There's no way around it and nobody should sell you one.

React Native has no div, no span, no CSS. It has View, Text, Pressable and a style system that looks like CSS but isn't. Tailwind classes can come along through NativeWind, which we use on most projects because it lets the team keep thinking in px-4 rounded-xl, but plenty of classes don't map and grid layout doesn't exist.

shadcn/ui is the bigger loss. It's built on Radix, and Radix is DOM all the way down. Every Dialog, DropdownMenu, Popover, Toast and Select in your Lovable app needs a native replacement. Some are easy (a Select becomes a bottom sheet, which is better on a phone anyway). Some aren't. A data table with sorting and column resizing is a week on its own, and usually the right answer is a different design for mobile rather than a port.

Routing moves from react-router-dom to Expo Router. File-based, so the structure feels familiar, but deep links and the back stack behave differently and you'll want to plan them rather than discover them.

Auth is where the first week goes

This is the one that catches everybody, and it caught us on our first Lovable conversion too.

On the web, Supabase stores the session in localStorage and handles OAuth by redirecting the browser and reading the token from the URL. Neither exists in React Native. You set up the client like this:

createClient(url, anonKey, {
  auth: {
    storage: AsyncStorage,
    autoRefreshToken: true,
    persistSession: true,
    detectSessionInUrl: false,
  },
})

and then Google sign-in needs either expo-auth-session with a custom scheme redirect, or the native @react-native-google-signin/google-signin package with its own iOS and Android client IDs in Google Cloud. The redirect URL you had in Supabase's auth settings for the web won't work. You add myapp://auth-callback and allow it.

We had a client whose Google login worked perfectly in Expo Go and failed silently in the TestFlight build. No error, the browser sheet just closed and nothing happened. The custom scheme in app.json was myapp, the redirect in Supabase was myApp://, and iOS treats schemes as case-sensitive in exactly that spot. Half a day.

Then there's Apple. If your app offers Google sign-in, App Store guideline 4.8 means you need Sign in with Apple too (or an equivalent privacy-focused option). Supabase supports it, but it needs an Apple service ID, a key file and about an hour of clicking around developer.apple.com. Plan for it from day one, it's the most common reason we see a first submission bounce.

Store tokens in expo-secure-store instead of AsyncStorage if your app handles anything sensitive. It has a 2 KB per-value limit on some platforms, which a Supabase session can exceed, so you end up splitting the value or encrypting into AsyncStorage with a key from SecureStore. Annoying, but it's a known pattern.

Wrap first, rewrite later?

Sometimes, yes. If the goal is to get into the stores this month to test demand, wrapping the Lovable web app in Capacitor is faster and cheaper, and we'll say so. It's also the route most likely to get a guideline 4.2 rejection from Apple if the app is just a website in a frame, so the wrap needs real native features: push notifications, a native tab bar, offline handling.

React Native with Expo is what we'd pick when the app is the product, when people will open it daily, or when you need things a web view does badly: background location, smooth lists of thousands of rows, camera work, widgets. EAS Build means you don't need a Mac on every developer's desk, and over-the-air updates let you ship fixes without waiting for review.

How long the React Native version takes depends far more on how messy the web code is, and how many shadcn components need a native rethink, than on the number of screens.

If you want a straight answer on which route fits your app, send us the Lovable project and we'll look at the code before quoting.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable Supabase: Bring Your Own Project

Aakash Verma — Sun, 18 Oct 2026 00:57:58 +0000

Every new Lovable project gets Lovable Cloud by default, and Cloud is Supabase underneath. So "Lovable Supabase" means two different things depending on who's asking. Most people mean the integration: you connect a Supabase project that you own, Supabase bills you, and Lovable builds against it. That is the setup this post is about, because it's the one we put clients on when an app is going to have real users.

If your app already runs on Cloud and you want out, skip to the end. That is a different job.

Connecting it takes two people (sometimes)

The docs split the connection into two steps, and they're split for a reason.

First, someone links a Supabase organization to the Lovable workspace. Only workspace owners and admins can do that. You'll find it on the Connectors page, or under More, then Cloud, inside a project. Once an org is linked, everyone in the workspace can see its projects, even people with no Supabase account of their own.

Second, anyone with edit access connects a Lovable project to one Supabase project from that org. In the Cloud view it's the "Already have a Supabase project? Connect it here" link, then Connect next to the project you want.

This is where agencies and freelancers get stuck. A founder invites a developer as an editor, the developer goes to connect Supabase, and the "Add Organization" button is greyed out. Nothing is broken. The founder has to do step one, or make the developer an admin. We've had a call stall for twenty minutes on exactly that.

Do it at the start if you can. Connecting your own project to a brand new Lovable app is ten minutes. Lovable has no one-click migration between Cloud and your own Supabase, in either direction, so choosing late costs real work.

What Lovable does once it's connected

Pretty much what it does on Cloud, but in your project, where you can see it.

Schema changes come up in chat as SQL and only run when you approve them. Each one is saved as a file under supabase/migrations/ in the repo, and the TypeScript types get regenerated. I like this more than the Cloud flow. You end up with a real migration history in Git, and any developer can read it and replay it on a staging project with the Supabase CLI. Data inserts and updates also need your approval, which is slower but has saved at least one client from a "clean up the test users" prompt that matched real users too.

Edge functions get written and deployed straight to your project. Lovable reads their logs when something fails, and you can watch them yourself under Edge Functions in the Supabase dashboard. Secrets go in through a masked input, get stored in your project, and Lovable never reads the values back or puts them in code. That's fine. Just know where they live: Supabase dashboard, Edge Functions, Secrets. Not in Lovable.

Auth is wired to Supabase Auth for email and password. Social logins you turn on yourself in the Supabase dashboard under Authentication, and then Lovable adds the button.

Lovable also runs its security checks after schema changes, including RLS coverage. Don't treat that as a sign-off. The docs themselves tell you to check every table's policies in the Supabase dashboard before going live, and missing policies are still the most common hole we find in audits. A table with RLS enabled and a using (true) select policy passes a lot of automated checks.

The bits that stay on Cloud

This list is in the docs but people skim past it. With your own Supabase connected, these Lovable features don't apply:

the in-editor Database, Users, Storage, Secrets, Jobs, Usage and Logs views (you use the Supabase dashboard instead)
managed backups and instance resizing
auth emails sent by Cloud
managed Google sign-in and SAML SSO
signed-in browser testing, and PII scanning of your data
built-in payments on older React + Vite apps

Two of those cause real problems.

Email. On Cloud, signup confirmations and password resets just arrive. On your own Supabase they go through Supabase's default SMTP, and that server is a toy: 2 messages an hour, and it refuses to send to any address that isn't on your Supabase team. So it works perfectly while you test with your own email, then your first real user never gets a confirmation link. Set up custom SMTP (Resend, Postmark, SES, whatever you like) under Authentication before launch. It's fifteen minutes of work and the most common "nobody can sign up" ticket we see.

Google sign-in. Cloud's managed Google login has no equivalent here. You create an OAuth client in Google Cloud Console, paste the client ID and secret into the Supabase Google provider, and add the Supabase callback URL to the client. Then publish the consent screen. If it's left in Testing, only the test users you listed can log in, and everyone else gets an "access blocked" page that looks like your app is broken.

Don't share one Supabase project between two Lovable projects

The docs warn about this and I'll repeat it louder. If two Lovable projects connect to the same Supabase project, they overwrite each other's secrets, including LOVABLE_API_KEY.

A founder we worked with remixed their app to make a "staging" copy and connected the remix to the same Supabase project as production. Felt sensible, same data, quick to test. The remix wrote its own LOVABLE_API_KEY over the production one, and the production app's AI summary feature started failing with 401s the next morning. Nothing in the production project had changed. It took a while to find, because who looks at a staging remix when prod breaks?

Staging gets its own Supabase project. Free tier is fine for that.

Disconnecting is gentler than it sounds

Disconnect in the Cloud view and Lovable just stops deploying edge functions and reading your schema. Your code stays in the repo and your data stays in Supabase. You can reconnect later. One gotcha: supabase/config.toml keeps the project ref from whichever project the code was last linked to. If you point the app at a different project, check that file, or the CLI deploys to the old one.

Already on Lovable Cloud?

Then connecting a Supabase project isn't a switch you flip, so check first whether it saves you anything: the free Lovable cost check compares your current bill with the same app on your own Supabase. You have to move the data, users, files, functions and secrets out of a project you don't own, and the export doesn't take all of that with it. The Cloud to Supabase migration checklist shows what breaks, and we do the move as a fixed-scope job, see Lovable Cloud to Supabase migration. If you're starting fresh and want it set up properly from day one (SMTP, Google OAuth, RLS, staging), tell us about the app.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Capacitor 8 Upgrade for Lovable Apps

Aakash Verma — Sat, 17 Oct 2026 00:35:28 +0000

If you wrapped your Lovable app with Capacitor in the last year, it's almost certainly on Capacitor 7, and Capacitor 7 targets Android API 35. Since August 31, 2026, Google Play only accepts new apps and app updates that target Android 16, API 36. Your app stays in the store. You just can't ship a bug fix until you move. Google lets you request an extension, and that extension ends November 1, 2026.

So the Capacitor 8 upgrade isn't optional, and we've done a run of them for Lovable apps lately. The actual upgrade is mostly one command. What eats the afternoon is everything around it.

Fix your machine before you touch the project

Capacitor 8 wants newer tools than most people have installed, and npx cap migrate doesn't check most of them for you. From the official update guide:

Node 22 or newer
Xcode 26.0+ for iOS, and the iOS deployment target goes up to 15.0
Android Studio Otter (2025.2.1) or newer
JDK 21. The migrate command prints "Capacitor 8 requires JDK 21 or higher. Some steps may fail." if you're on 17, and then carries on anyway

The Android Studio one catches people. Open a migrated project in an older Android Studio and Gradle sync dies with:

The project is using an incompatible version (AGP 8.13.0) of the Android Gradle plugin. Latest supported version is AGP 8.12.2

That's not your project being broken. It's your IDE being two months old. Update Android Studio first and you never see it.

On the Lovable side there's nothing to do. Lovable doesn't know Capacitor exists. Your android/ and ios/ folders live in your GitHub repo (or on your laptop), and Lovable keeps editing src/ as before. Do the upgrade on a branch, though. If Lovable pushes to main while you're halfway through, you'll be untangling a merge in package-lock.json, which is nobody's idea of fun.

Running the migration

npm i -D @capacitor/cli@latest
npx cap migrate

It asks "Capacitor 8 sets a deployment target of iOS 15 and Android 16 (SDK 36). Are you sure you want to migrate?", asks which package manager you use, and then does a surprising amount. It bumps @capacitor/core, cli, ios, android and every official @capacitor/* plugin to ^8.0.0. It sets minSdkVersion = 24, compileSdkVersion = 36 and targetSdkVersion = 36 in android/variables.gradle, along with all the AndroidX versions. It moves Gradle to 8.14.3, the Android Gradle plugin to 8.13.0 and Kotlin to 2.2.20. It sets the iOS deployment target to 15.0 in the Xcode project (and the Podfile, if you use CocoaPods). It adds density to android:configChanges in the manifest, so the WebView stops reloading when the app is resized. Then it runs cap sync and lists the plugins you use that have breaking changes.

It will not touch your web code or capacitor.config.ts, and it won't help with third-party plugins. That last one is where most of our time goes. One client app had a community in-app purchase plugin pinned to a version with a Capacitor 7 peer dependency, and npm install refused to resolve until we bumped it, and the newer version had renamed two methods. Check every non-@capacitor/ plugin in your package.json before you start, and look at its changelog for an 8.x release. If one has no 8.x release yet, that's your real blocker, not Capacitor.

The config key that silently stops working

android.adjustMarginsForEdgeToEdge is gone in Capacitor 8. A lot of wrapped apps set it to 'auto' or 'force' last year as the quick fix for Android 15 drawing content under the status bar. After the upgrade the key does nothing, there's no error, and your header slides back under the clock.

The replacement is CSS. Capacitor 8 ships a System Bars API inside @capacitor/core (there is no @capacitor/system-bars package to install, people keep trying), and it injects --safe-area-inset-top and friends so you can pad your fixed header and bottom nav. The status bar plugin's setOverlaysWebView() and setBackgroundColor() don't work on Android 16 at all. I went through the CSS for this in the splash screen and status bar post, so I won't repeat it here. Just delete the dead config key so the next person doesn't think it's doing something.

Smaller things that bit us

Geolocation's timeout option now applies to every request. Before, on Android, it only applied in some cases. If you had a 5 second timeout that "worked fine", it may start throwing on slow GPS fixes indoors. Bump it or handle the error.

Android Studio will offer to upgrade the Android Gradle plugin to 9. Say no for now. If you already said yes, older builds of the haptics and keyboard plugins fail with "getDefaultProguardFile('proguard-android.txt') is no longer supported since it includes -dontoptimize". Version 8.0.1 of both fixes it.

Swift Package Manager is now the default for new iOS projects. Existing ones stay on CocoaPods, which is fine. But if you ever delete ios/ and run npx cap add ios again, you get an SPM project with no App.xcworkspace, and any Fastlane or CI config that points at the workspace breaks with "No .xcworkspace file found". Either point it at App.xcodeproj or re-add with npx cap add ios --packagemanager CocoaPods. I'd move to SPM eventually. Not in the same week as a forced Play Store upgrade.

Test on a real Android 16 phone before you upload. The emulator is fine for most of it, but we've seen a bottom tab bar sitting behind the gesture bar that only showed up on a physical Pixel.

If you'd rather hand this off, it's the kind of job we do in a couple of days, including the plugin archaeology. Send us the repo or see the app packages.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

How Much Does Lovable Cost Per Month?

Aakash Verma — Fri, 16 Oct 2026 01:37:32 +0000

How much does Lovable cost? You can start for $0. The moment you want your own domain, you're on Pro, and Pro starts at $25 a month. That's the number on the pricing page, and for a landing page it's roughly the whole bill.

For an app people actually log into, the plan is only the first line. Since Lovable moved everything onto one credit balance in June 2026, the same credits that pay for your prompts also pay for your app running: the database, file storage, traffic, edge functions and any AI calls your users trigger. So the real Lovable cost per month is "the tier you need for building plus the tier you need for running", and the second part grows with your users, not with you.

I wrote about where the credits go when you build a few days ago. This one is about the whole monthly bill.

The prices this is built on

All from Lovable's own docs, checked on October 14, 2026:

	Free	Pro	Business
Monthly price (100 credits)	$0	$25	$50
Bigger tiers	none	200 for $50, 400 for $100, up to 10,000 for $2,250	about double the Pro price
Top-up credits	none	$15 per 50	$30 per 50
Daily build credits	5 a day, max 30 a month	5 a day	5 a day
Monthly Cloud grant	20 credits	20 credits	20 credits
Monthly AI grant	4 credits	4 credits	4 credits
Custom domain, code editing, no badge	no	yes	yes

Annual billing knocks off two months. The Cloud and AI grants are labelled "temporary offering, subject to change", so don't build a business plan on them. Business is mostly SSO, team controls and the Lovable API; a solo founder rarely needs it.

Three example bills

These are illustrations built from the prices above, not anyone's invoice. Your real numbers are in More → Cloud → Usage inside the project.

A landing page or portfolio. Pro at $25. A static-ish site with a contact form stays inside the 20-credit Cloud grant almost every month, so hosting costs you nothing extra. Add the domain from your registrar, about a dollar a month. Call it $26.

A booking app with a few hundred users. You're still shipping changes every week, say 120 credits of building. The app itself uses around 70 run credits a month for its database, a bit of storage and the confirmation emails; the grant covers 20 of those. That's about 170 credits, which means the 200-credit Pro tier at $50. Your transactional email can sit on a free tier (Resend gives 3,000 emails a month), so the total is roughly $51.

An app with paying users and an AI feature. This is where it moves. Building is maybe 150 credits. The database has been resized to a bigger instance because the dashboard got slow, so Cloud is closer to 180 credits. The AI summaries your users click run through Lovable's AI gateway and cost another 60 or so (the 4-credit AI grant barely registers). Around 390 credits a month puts you on the 400 tier at $100, and in a busy month you'll buy a $15 top-up on top. $100 to $115, before Stripe's cut.

One founder I worked with had exactly that third shape and couldn't work out why their "$25 plan" was charging $100. Nothing was broken. The app had customers.

The costs that aren't on Lovable's page

These turn up on a different card statement, so people forget them when they say "Lovable costs $25":

The domain. Bought through Lovable or elsewhere, it's yours to pay for every year.
Your own Supabase, if you brought one instead of using Lovable Cloud. Supabase Pro is $25 a month and includes $10 of compute. Then your database stops eating Lovable credits, but you pay Supabase instead.
Email beyond the free tiers. Auth emails from the built-in sender are fine for testing, and most launched apps move to Resend or Postmark. (Why auth emails fail covers that.)
Stripe: 2.9% + 30¢ per US card charge on standard pricing.
App stores, if you wrap it as a mobile app: Apple charges $99 a year, Google $25 once.

What happens if the credits run out

Your published site stays up. AI features in the app stop answering, and apps on Lovable Cloud can pause until you add credits. That's the bit that hurts, because your users find out before you do. On Pro you can turn on auto top-up with a monthly spend limit: set it. A $45 top-up is cheaper than a weekend of "is your app down?" emails.

When the bill is worth cutting

If most of your credits go to building, there's not much to cut: that's the product working as designed. If most go to running, you have options. Moving the database from Lovable Cloud to your own Supabase project turns a variable credit drain into a flat $25, and you keep building in Lovable exactly as before. For the booking app above it saves nothing. For the third app it usually does, and the bigger the instance, the more.

Don't guess which one you are. Our free Lovable cost check reads your repo (read-only, private repos work) and shows what the same app would cost on four setups, with the one-time cost of each. If the answer is "move the database", that's our Cloud to Supabase migration, fixed price from $150.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Capacitor Push Notifications for Lovable

Aakash Verma — Thu, 15 Oct 2026 00:40:20 +0000

Push is the feature that usually makes founders give up on the PWA route and wrap their Lovable app properly. A web app on iPhone only gets push after the user adds it to the home screen, and almost nobody does. Wrap the same React code in Capacitor and you get real push notifications on iOS and Android. Getting Capacitor push notifications working takes an afternoon if you know the traps, and about three days if you don't.

Here's the version with the traps. (If your reminder only depends on a time the app already knows, like a booking, skip the server entirely and use Capacitor local notifications.)

The token you get on iOS is not the token you think

The official plugin is @capacitor/push-notifications (v8 at the time of writing). You call register(), you listen for the registration event, and you get a token. On Android that's a Firebase Cloud Messaging token. On iOS it's a raw APNs token.

That difference wrecks people. Your backend sends through FCM because that's what every tutorial uses, the Android test works on the first try, and every iOS send comes back with an invalid registration error. FCM can't do anything with an APNs token.

You have two ways out. Send iOS notifications straight to APNs and Android through FCM, which means two sending paths, two sets of credentials and twice the debugging. Or swap the official plugin for Capawesome's @capacitor-firebase/messaging, which pulls in the Firebase iOS SDK and hands you an FCM token on both platforms. We use the second one on almost every Lovable app we ship. One token format, one API call, one table. The cost is a heavier iOS build with Firebase pods in it, and I'll take that trade every time.

Apple's side

You need a paid Apple Developer account anyway, so: open Certificates, Identifiers & Profiles, find your App ID, and tick Push Notifications. Then go to Keys, create a key with Apple Push Notifications service enabled, and download the .p8 file. You can download it exactly once. Put it in your password manager before you do anything else.

In Firebase, open Project settings, then Cloud Messaging, and upload that .p8 with its Key ID and your Team ID.

Use the key, not a certificate. Firebase still accepts the older .p12 push certificates, and they're split into development and production. That split causes the classic bug. We took over an app from a founder whose push worked perfectly when they ran it from Xcode and never once arrived on TestFlight. They had uploaded a development certificate. Debug builds from Xcode talk to the APNs sandbox, TestFlight and App Store builds talk to production APNs, and their production slot was empty. A .p8 key works for both, doesn't expire every year, and makes the whole category of problem go away.

In Xcode, add the Push Notifications capability under Signing & Capabilities, and make sure AppDelegate.swift forwards didRegisterForRemoteNotificationsWithDeviceToken and didFailToRegisterForRemoteNotificationsWithError to Capacitor. The plugin docs have the exact snippet. If you skip it, register() resolves and the registration event simply never fires, with no error anywhere. Lovely.

Test on a real iPhone. Don't burn an hour on the simulator.

Android's side

Shorter. Download google-services.json from Firebase and put it in android/app/. Then two things people forget.

Android 13 and later need the POST_NOTIFICATIONS runtime permission, so call checkPermissions() and requestPermissions() before register(). Older tutorials skip this because they were written for Android 12, and on a Pixel 8 you get a token, a successful send, and nothing on screen.

And create a notification channel with createChannel() if you want control over importance and sound. Android 8+ files every notification under a channel, and the user can mute channels separately, so give "Order updates" and "Marketing" different channels from day one. Users who can mute your promos will keep your order updates on.

Sending from a Lovable backend

Your Lovable app already has a Supabase backend (Lovable Cloud or your own project), so the natural home for sending is an Edge Function.

Make a device_tokens table with user_id, token, platform and updated_at, with RLS so users can only insert and delete their own rows. Upsert the token every time the app starts, because tokens change after reinstalls and restores. The Edge Function signs a short-lived OAuth token with your Firebase service account and calls the FCM HTTP v1 endpoint. The old FCM "server key" API is gone, so any snippet that sends an Authorization: key=... header is out of date. Delete it.

When FCM answers a send with UNREGISTERED, delete that token row. Skip this and after six months half your table is dead tokens and your send logs are a wall of errors you've trained yourself to ignore.

Keep the service account JSON in Edge Function secrets. I've seen it pasted into a Lovable chat prompt, which puts it in the project history. Don't.

Things the plugin won't do

It doesn't support iOS silent push (background "content-available" pushes that wake the app). If you need background sync triggered by the server, that's native code or a different plugin.

On Android, data-only messages don't reach your pushNotificationReceived listener if the app was killed. Send a notification payload for anything the user must see.

When the app is open in the foreground, iOS shows nothing by default. Set presentationOptions in capacitor.config.ts to something like ["badge", "sound", "alert"] or your users will miss every push that arrives while they're using the app, which is exactly when your chat feature needs them.

Ask at the right moment

iOS gives you one system permission prompt. If the user taps "Don't Allow", the only way back is Settings, and nobody goes to Settings.

So don't ask on first launch. One booking app we built asked on the splash screen and roughly a third of users said yes. We moved the prompt to right after someone booked their first appointment, with a plain line above it: "Want a reminder the day before?" Most people said yes, because now the notification was obviously for them. Same app, same users, the prompt just showed up when it made sense.

Push is usually the first native feature we add when we turn a Lovable app into a real iOS and Android app, and it's a big part of why native beats a PWA for most products. If you're still choosing a wrapper, read Capacitor vs React Native first. Or tell us about your app and we'll wire it up for you.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable Cloud: What You Actually Get

Aakash Verma — Wed, 14 Oct 2026 00:17:39 +0000

Lovable Cloud is the backend Lovable switches on for you the first time your app needs to save something. Ask for a login page or a table of orders and it appears: a database, auth, file storage, edge functions, a place for API keys. Lovable's docs say it plainly, it runs on Supabase's open-source foundation. So when people ask us "what database does Lovable use", the answer is Postgres, inside a Supabase project that Lovable owns and you rent.

That one sentence explains most of what follows, good and bad.

What's in the Cloud tab

Open your project, go to Cloud, and you get a cut-down Supabase dashboard with Lovable's names on it:

Database: your tables, row editing, the RLS policies, and backup restores.
Users: who has signed up, and which sign-in methods are on.
Storage: buckets and the files in them.
Edge functions: the server-side code (Stripe webhooks, emails, anything with a secret key).
Secrets, Logs, plus Emails, Jobs, an SQL editor, Usage and Advanced settings.

It's a decent set. The SQL editor alone saves a lot of "please add a column" prompts. What you don't get is the real Supabase dashboard, the service_role key, or a direct Postgres connection string you can hand to another tool. That gap doesn't matter while you're building. It starts to matter the day you want a BI tool on your data, a second app on the same database, or a contractor who works in a normal IDE.

The settings that will bite you later

Region is forever. You pick Americas, Europe or Asia Pacific (or "Closest to me") through the "Where project data is stored" setting, and once Cloud is enabled on a project it can't be changed or moved. If your customers are in Germany and the project got created on a US default, the only fix is a new project and a data move. Check this before you have real users, not after.

The instance is small until you pay. Advanced settings lists six sizes: Tiny, Mini, Small, Medium, Large and X-Large. Free projects sit on Tiny. The docs don't publish CPU or RAM numbers for any of them, which I find annoying, so you're judging by the resource health cards (CPU, Memory, Disk over the last 24 hours, with "pressure" segments when you hit the ceiling). A resize takes a few minutes and briefly drops the database while it restarts. Do it at 3am your users' time, not during a launch.

Also, the names moved on July 31, 2026. Old Medium became Large, old Large became X-Large, and a new Medium was slotted in between. If you read a forum post from before August about "Medium being enough", it was talking about a different box.

Disk only grows. Database storage has an 8 GB minimum, can be raised up to four times in 24 hours, and can't be shrunk. Same rule as Supabase itself.

Dangerous migrations are off by default. Each Cloud tool has Always allow, Ask each time or Never allow. Most default to Always allow. The one that defaults to Never allow is "Execute backward incompatible database migrations", which covers dropping or renaming tables and columns. Leave it there. If the agent wants to rename profiles.name to profiles.full_name, you want to see that coming.

How Lovable Cloud is billed

Cloud doesn't have its own invoice any more. Database, storage, compute, network, realtime and the AI features in your app all spend Run credits from the same balance you build with. Free, Pro and Business each get a 20-credit monthly Cloud grant and a 4-credit AI grant on top, and neither rolls over.

The part that matters for a live product: when the balance hits zero, the published site stays up but the Cloud backend can pause. Paused means no database, no auth, no storage, no edge functions. Your landing page loads and nobody can log in. We wrote up the full credit math in our Lovable pricing post, so I won't repeat it here. If you'd rather see it for your own app, the free Lovable cost check scans your repo and estimates what Cloud costs you against running the same backend yourself.

Usage lives under More, Cloud, Usage, broken down by category for up to 90 days. Look at it once a week if you have paying users. It's the only early warning you get.

What the export takes, and what it leaves behind

Lovable Cloud has a native export now, which is a real improvement. It gives you the whole database, structure and data, including user accounts and their password hashes. So your users won't need to reset passwords when you move, as long as the destination is Supabase Auth, which reads the same bcrypt hashes.

It does not include your storage files, your edge function code, or your secrets. Sign-in provider settings (the Google OAuth client, redirect URLs) and API keys have to be set up again at the destination too. There are hard limits: databases up to 15 GB, export files up to 5 GB, one export per 24 hours, and the backend has to be running when you start it. A project paused for zero credits has to be woken up first.

We had a founder come to us last month with a "finished" export and a new Supabase project already set up. Tables, rows, users, all there. Then their first customer tried to open an invoice PDF and got a 404, because the 2,300 PDFs were in a Cloud storage bucket that the export never touched. The database rows still pointed at the old bucket URLs. Not hard to fix, but it's exactly the kind of thing you find on a Monday morning from an angry email.

And don't press Remove until you've checked everything. "Remove Lovable Cloud" deletes the instance permanently, and exports can't be downloaded after it's gone.

Is Lovable Cloud enough?

For a prototype, a demo, or an internal tool with a dozen users, yes. Leave it alone and build. It's genuinely convenient, and the alternative (wiring up your own Supabase on day one) is work you don't need yet.

It stops being enough when any of these are true: you need the service_role key or a direct connection for another service, you want your backend bill separate from your build credits, you care which region your data lives in and got it wrong, or your app can't afford to go dark because someone on the team used up the credits on a redesign. Moving from Cloud to your own Supabase is manual (Lovable's docs say so, there's no one-click switch), and the comparison of Lovable Cloud vs Supabase goes through the trade-offs side by side.

If you're past that point, our Lovable Cloud to Supabase migration moves the database, users, storage files, functions and secrets for a fixed price, and you keep building in Lovable afterwards. The free migration checker tells you how big the job is first.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.