Skip to content

Lovable app with fal.ai (images and video): AI launch checklist

Lovable apps call fal.ai (images and video) with your own API key, from server code, so fal.ai (images and video)'s own limits are your safety net. Of the 20 checks before you charge users, Lovable handles 1, partly handles 5, and leaves 14 to you.

Checked 12 Nov 2026 against each platform's docs; every fact links to its source.

How AI calls work in Lovable

Built-in AI
Yes: Lovable AI, a built-in connector that adds chat, summaries, images, video, music, search, speech and more without a provider account, API keys or billing setup. It is separate from the Lovable agent that writes code.
How calls run
AI calls go through a backend function Lovable creates, keeping credentials and prompts server-side (the page calls this 'AI gateway usage'). Exception: live voice streams audio from the browser directly to the voice model, while the server starts the call and holds the key. Chat streams via SSE.
API keys
Lovable generates and manages a LOVABLE_API_KEY per project; you never create it. Remixed projects get a fresh key.
Who pays
Your Lovable workspace. AI usage in deployed apps consumes workspace credits ('Run credits'), priced by model and work (tokens, images, video seconds, tracks, audio, voice time). Free, Pro and Business workspaces get a temporary 4-credit monthly AI grant that is used first and does not roll over; then general credits. Priority processing costs more; canceled requests may still be billed; live voice has a 15-second minimum.
Your own key
The built-in connector always runs through Lovable and bills credits; it can't use your own OpenAI/Anthropic/Google key. To use your own key, have Lovable call the provider from an edge function with the key stored as a secret; the provider bills you and only the function's Cloud usage hits credits.
When credits run out
Lovable AI returns 402 Payment Required; app AI features fail with an error and Lovable shows no message for the failed calls themselves.

Keys and secrets

Where secrets live
Lovable Cloud: More menu → Secrets ('Store API keys and other sensitive values securely'). Lovable detects API keys pasted into the project chat and guides you to Secrets.
Server-side by default?
Yes for Lovable AI (backend function). For BYOK, only if the call is in an edge function.
How keys end up in the browser
Putting a provider key in frontend code instead of Secrets; Lovable's own docs say 'API keys and other secrets cannot be stored safely in client-side code.' Separately, a 2026 Lovable API flaw exposed hardcoded Supabase credentials in pre-November-2025 projects (see commonMistakes).
Secret scanning
Quick scan runs on every publish (database review, dependency audit, MCP check); Deep scan (manual) checks leaked secrets, unauthenticated endpoints, access control.

The 20 checks, in Lovable

What Lovable does for you, and what to ask it (or your coding agent) to add. Tick them off in the interactive checklist.

Cost and abuse

  • Partly

    A spending cap per user

    Usage limits & alerts can pause AI for a whole project, not one user, so ask Lovable: 'Create a Cloud table ai_usage (user_id, day, credits_used) and, in the edge function that calls Lovable AI, sum today's credits for the signed-in user and return a daily-limit error before calling the model when it's over the cap.'

    docs.lovable.dev ↗

  • Partly

    Rate limits on every AI endpoint

    Lovable AI only limits requests per minute per workspace, so ask Lovable: 'Add a rate_limits table (key, window_start, count) and check it at the top of every edge function that calls AI, keyed by user id or IP, returning 429 after 10 calls a minute.'

    docs.lovable.dev ↗

  • Handled

    AI keys only on the server

    With Lovable AI the LOVABLE_API_KEY lives only in the backend function; if you add your own OpenAI, OpenRouter or fal key, paste it into More → Secrets, keep the call in an edge function, and run a Deep scan for leaked secrets.

    docs.lovable.dev ↗

  • You add it

    Retries capped, with a timeout

    Ask Lovable: 'In each AI edge function add a 30-second timeout and at most 2 retries with backoff, only on 429 and 5xx, never on 402 (out of credits) or other 4xx, and remove any retry in the React code.' Lovable notes canceled requests may still be billed.

    docs.lovable.dev ↗

  • Partly

    A budget alert at each AI provider

    For Lovable AI your provider is your Lovable credit balance: set an AI or Run limit with 'Pause AI' and the 80% warning in Usage limits & alerts, and a monthly spend limit on auto top-up; for any BYOK provider also set a limit in that provider's dashboard.

    docs.lovable.dev ↗

Charging for AI use

  • You add it

    Every AI call charged or deliberately free

    Ask Lovable: 'List every edge function and Job that calls Lovable AI or another provider, including Jev classification, embeddings and transcription, and mark each one as charged to the user or free on purpose.'

    docs.lovable.dev ↗

  • You add it

    Credits deducted on the server, after success

    Ask Lovable: 'Create a user_credits table with an RLS policy that lets users read but never update their own row, and a database function that the AI edge function calls with the service role to deduct credits in the same transaction as inserting the ai_results row.'

    docs.lovable.dev ↗

  • You add it

    Failed AI calls refunded

    Ask Lovable: 'If the AI call returns 429, 402, times out, or gives an empty reply or invalid JSON, release the reserved credits, insert a credit_refunds row with the reason, and tell the user they weren't charged.'

    docs.lovable.dev ↗

  • You add it

    One charge per request, even on a double click

    Ask Lovable: 'Generate a request_id per click, add a unique index on ai_results.request_id, have the edge function return the existing row on a repeat instead of calling AI again, and disable the button while it runs.'

    docs.lovable.dev ↗

A record of every AI result

  • Partly

    Each AI result stored with its feature, model, prompt version and settings

    More → AI shows each run's model and credits but not your user or prompt version, so ask Lovable: 'Create ai_results (id, user_id, feature, model, prompt_version, params jsonb, input, output, credits, request_id, created_at) and insert a row from the edge function for every AI call.'

    docs.lovable.dev ↗

  • You add it

    Retries and corrections saved next to the original, never over it

    Ask Lovable: 'When a user regenerates or edits an AI result, insert a new ai_results row with parent_id, version and edited_by; never update the original; show the latest version by default.'

    docs.lovable.dev ↗

  • You add it

    What users do next with each AI result, recorded on the server

    Ask Lovable: 'Create ai_events (result_id, user_id, type, created_at) and an edge function log-ai-event called from the Retry, Undo, Edit, Copy, Send and Export buttons, with RLS so users can only insert their own events.'

    docs.lovable.dev ↗

What worked, for whom, at what cost

  • You add it

    Worked first time, per feature, model and prompt version

    Ask Lovable: 'Create a SQL view of worked-first-time by feature, model and prompt_version for 7 and 30 days, and an admin-only page that shows it with result counts.'

    docs.lovable.dev ↗

  • Partly

    A cost record for every AI step

    Lovable AI bills in credits and the More → AI list shows credits per run, but not per user or step, so ask Lovable to save step name, model, credits and the reported usage in an ai_costs row after every call, retries included.

    docs.lovable.dev ↗

  • You add it

    Wasted AI spend and real cost per result, per feature

    Ask Lovable: 'Add an admin page that joins ai_costs to ai_events and shows, per feature and model for 30 days, total credits, credits spent on results that were retried, undone or edited, and credits per result that worked.'

    docs.lovable.dev ↗

  • You add it

    Who the AI fails for

    Ask Lovable to save input_language, input_length_band, input_kind, plan and is_new_user on each ai_results row and add a worked-first-time-by-trait table to the admin page.

    docs.lovable.dev ↗

Switching safely

  • You add it

    Prompts in version control, with version labels

    Ask Lovable: 'Move every prompt string out of the edge functions into one shared prompts file with exported version labels like support_reply@v3, and save the label on each ai_results row.'

    docs.lovable.dev ↗

  • You add it

    Model and prompt switchable by a flag

    Ask Lovable: 'Store the model id and prompt version per feature in an admin-only app_settings table read by the edge function, with a percentage split assigned by hashing the user id.' Lovable AI lets you swap between its listed models without new keys.

    docs.lovable.dev ↗

  • You add it

    Real past requests to replay before a change

    Ask Lovable: 'Add an admin-only edge function that takes 50 past ai_results (mixing worked and failed), strips names and emails, re-runs them through a chosen model and prompt version, and saves outputs and credits next to the originals.'

    docs.lovable.dev ↗

  • You add it

    A plan for model shutdowns

    Ask Lovable to list every model id used across edge functions, move them into one config, and write MODELS.md. Whether Lovable migrates retired Lovable AI models for you: not found in its docs.

    docs.lovable.dev ↗

fal.ai (images and video) limits to set before launch

Billing model
Prepaid credits drawn down per use; each model has its own unit (per image or megapixel, per second of video or flat per video, per request or per GPU-second). Only successful outputs are billed; 5xx errors and queue wait aren't.
Where secrets live
Billing dashboard https://fal.ai/dashboard/billing (overall spend, invoices, payment history). Org admins (enterprise organizations) can set spending alerts; the menu location isn't stated.
Per-key or project cap
not found.
Auto top-up
not found.
Key scoping
Create keys at https://fal.ai/dashboard/keys with permission presets (API, SERVERLESS, DEPLOY, COMPUTE, BILLING, READONLY, FULL; legacy ADMIN and API scopes). A key can be limited to a list of models in the 'Allowed models' tab (set at creation, can't be changed) and can expire after 1 hour to 1 year. Keys are managed per team. Per-key spend limits: not found. Guidance on keeping FAL_KEY out of the browser: not on the key page read.
Rate limits
Concurrency, not requests per second: new accounts get 2 concurrent requests, rising automatically with paid invoices over the last four weeks up to 40 self-serve; more via sales. Requests are queued, not rejected; raw HTTP gets 429 concurrent_requests_limit with X-Fal-needs-retry: 1. Some high-demand models have extra limits. View at https://fal.ai/dashboard/usage-billing/concurrency.
Where usage shows
Billing dashboard for overall spend; per-model cost breakdowns and request-level detail via the usage and analytics Platform APIs or billing reports; pricing API GET https://api.fal.ai/v1/models/pricing?endpoint_id=... . Team members can see request metadata (endpoint, status, timing, cost); API-key submissions aren't tied to an individual member.

fal.ai ↗fal.ai ↗fal.ai ↗fal.ai ↗

Mistakes Lovable apps make at launch

  1. Tables left readable or writable by anyone (RLS missing or 'USING (true)').

    CVE-2025-48757 (CVSS 9.3): insufficient RLS in Lovable-generated sites through 2025-04-15 let unauthenticated attackers read or write arbitrary tables; Matt Palmer found about 170 of 1,645 showcase apps exposed. TNW reports about 70% of those had RLS disabled. A Feb 2026 Lovable-hosted EdTech app with inverted auth logic exposed 18,697 user records.

    tenable.com ↗superblocks.com ↗thenextweb.com ↗

  2. No per-user rate limit or cap on AI endpoints, so one user or script drains the credit balance; when credits run out, AI features fail for every user with no message.

    Lovable AI limits are per workspace, not per user, and return 402 when credits run out; app AI features then fail with an error and Lovable shows no message for failed calls. Third-party write-ups describe the overnight loop-script bill pattern for AI-built apps.

    docs.lovable.dev ↗docs.lovable.dev ↗dev.to ↗

  3. Secrets and credentials hardcoded in the project instead of Secrets.

    April 2026: a Lovable API BOLA flaw (open 48 days after a March 3 report) let a free account read other users' source code and hardcoded Supabase credentials in projects created before November 2025. Escape.tech's scan of 5,600 vibe-coded apps (mostly Lovable) found 400+ exposed secrets.

    thenextweb.com ↗escape.tech ↗

Questions

How do AI calls work in a Lovable app with fal.ai (images and video)?

Lovable apps call fal.ai (images and video) with your own API key, from server code, so fal.ai (images and video)'s own limits are your safety net.

Can Lovable cap AI spending per user?

Partly. Usage limits & alerts can pause AI for a whole project, not one user, so ask Lovable: 'Create a Cloud table ai_usage (user_id, day, credits_used) and, in the edge function that calls Lovable AI, sum today's credits for the signed-in user and return a daily-limit error before calling the model when it's over the cap.'

Where should the fal.ai (images and video) key live in Lovable?

Handled. With Lovable AI the LOVABLE_API_KEY lives only in the backend function; if you add your own OpenAI, OpenRouter or fal key, paste it into More → Secrets, keep the call in an edge function, and run a Deep scan for leaked secrets.

How do I stop one user running up my fal.ai (images and video) bill?

Add a per-user daily cap in your own code, checked before every AI call. Then set a limit at fal.ai (images and video) as a backstop: Billing dashboard https://fal.ai/dashboard/billing (overall spend, invoices, payment history). Org admins (enterprise organizations) can set spending alerts; the menu location isn't stated.

More checklists