You built it in Lovable. Here's how it runs for your company.
We take the app from your GitHub, make small changes and deploy it into your company's own cloud account on Cloudflare or Zerops. Your colleagues sign in with their company account, the app has no public address, and we review every later change before it goes live.
This page is for whoever built the app in Lovable, and for the IT person who was handed it with the words “put this into production”.
Updated 28 September 2026
The repository Lovable creates when you turn on GitHub sync.
Cloudflare or Zerops, or AWS if you prefer. Registered to your company, not to us.
Lovable Cloud or Supabase: move it, have us run it, or leave it.
What does your Lovable app still need to run for a company?
Lovable writes ordinary code you can take with you, and for one person or a small team that's often enough. Once the company starts leaning on the app, questions come up that Lovable isn't there to answer: who can get in, who approves changes, and who is responsible for it.
What's fine as it is
- It's regular code: React and TypeScript. Apps created since 13 May 2026 run on TanStack Start, older ones on Vite. Both can run outside Lovable.
- The code syncs to a GitHub repository, in both directions.
- The Supabase address and the publishable key in the
.envfile belong there. They're meant for the browser and Lovable puts them there on purpose. - Secret keys for connected services live in Lovable's Secrets, outside the browser.
What's usually missing
- A published app on
*.lovable.appis open to anyone with the link by default. Limiting it to workspace members takes a Business or Enterprise plan. - The app handles sign-in itself, through Supabase. It isn't tied to company accounts, so when someone leaves, their access has to be removed by hand, app by app.
- Who sees which data is decided by rules in the database (RLS). If they're missing or wrong, the data can be read straight from the browser.
- Anyone with the editor role or above can publish. A change from the chat goes live without a second pair of eyes.
- The data sits in Lovable Cloud, or in a Supabase project on the account of whoever built the app.
- Nobody is on the hook for running it: errors, outages, or what happens when the author leaves.
Lovable apps checked by researcher Matt Palmer in 2025 let anyone read data from their database without signing in, because the RLS rules were missing. The flaw is filed as CVE-2025-48757. Palmer works at Replit, which competes with Lovable.
publicly reachable apps built with Lovable, Replit, Base44 and Netlify were found by the security firm RedAccess. Around 5,000 of them held sensitive company or personal data, often with no sign-in at all.
Try it yourself
Open your app's address in a private browser window. Whatever you can see without signing in, anyone can see.
How does an app get from Lovable into production?
The app stays the same app: same screens, same logic. What changes is who handles sign-in, keys and deployment, and where it runs. How long it takes depends mostly on the data; the offer says exactly.
- 01
Scoping call
You show us the app and tell us who uses it. We check whether it runs on Lovable Cloud or on your own Supabase, and whether it's a newer TanStack Start app or an older Vite one. Within a few days you get an offer with the scope, the timeline and the price.
free · 30 min - 02
Connecting GitHub
In Lovable you turn on GitHub sync and Lovable creates a repository with the current code. We recommend moving it into your company's GitHub organisation rather than leaving it on the author's personal account. We only need access to the repository, not to your Lovable account.
you, in a few clicks - 03
We go through the code
Sign-in, the RLS rules on every table, keys in the code and in
part of the takeover.env, server functions and Edge Functions, and where the app sends data. We go through what we find with you. - 04
Small changes
The platform takes over sign-in: colleagues use their company account through Google, Microsoft or Okta, outside people a password. Roles are set in one place. Keys move into the cloud and out of the code. Screens, look and logic stay as they are.
part of the takeover - 05
Deciding about the data
Lovable Cloud or Supabase: move the data, have us run Supabase, or leave it where it is. We decide together, three options below.
together - 06
Deployment into your account
We set up Fabrika in a cloud account registered to your company, on Cloudflare or Zerops, and deploy the app. It has no public address; the only way in leads through the platform. Test and production environments are separate.
one-off - 07
Switching off the lovable.app copy
So that no second copy runs outside review, you unpublish the version on
from go-live · monthly*.lovable.app. From then on every change goes live only after our review, and each version comes with a report of what we checked.
What we look at in the repository
.env Public values only (VITE_*). They stay. vite.config.ts Lovable's build setup. We only change the deployment target. wrangler.jsonc Cloudflare settings in newer apps. Pointed at your account. supabase/migrations/ Schema and RLS rules. Table by table. supabase/functions/ Edge Functions. Which keys and permissions they use. src/ Screens and logic. Stay as they are, apart from sign-in. What happens to Supabase and the data?
A Lovable app keeps its data in Supabase: the database, the sign-in, the files and the server functions. Either through Lovable Cloud, where Lovable runs Supabase for you and you have no Supabase account of your own, or in your own Supabase project.
We don't promise one answer for everyone. We decide together at the scoping call, based on what the app uses from Supabase and where you want the data to live.
Move it elsewhere
The data moves to a database in your cloud account on Cloudflare or Zerops, and everything runs in one place under the platform. It's the biggest change of the three: Supabase holds more than tables, it also does sign-in, files and server functions, and those have to be replaced.
Makes sense when the app will live for years and the data should sit only with you.
Run Supabase in your account
Supabase stays and runs in your own cloud account, next to the rest of Fabrika. We take over running it. The app changes the least.
Makes sense when the app leans on Supabase features and rewriting them isn't worth it.
Leave it where it is
The app keeps using its current Supabase project or Lovable Cloud, and Fabrika handles sign-in, deployment and change review. It's the fastest route, but the data stays outside your cloud account and is managed where it is today.
Makes sense as a first step, or for apps with little sensitive data.
What to know before moving data
- Lovable Cloud can export the database: up to 15 GB of storage, an export file of at most 5 GB, one export every 24 hours. Files from storage are downloaded separately.
- The export includes user accounts with their password hashes. What happens to them depends on who will sign in: colleagues with their company account, outside people with a password.
- Secrets in Lovable are write-only, they can't be read back. Keys for connected services (payments, email, AI) are therefore issued again by the service and stored in the cloud.
- Removing Lovable Cloud from a project can't be undone. The export and the files have to be downloaded first.
Can I keep building in Lovable afterwards?
Honestly: we're testing that right now. Lovable syncs with GitHub in both directions, so technically the road is there. Before we promise it, we're trying it on a real app, because a few things change after the takeover: the Lovable preview runs at Lovable, outside the platform, and sign-in is run by the platform, not by Lovable.
Ask us where it stands. We'll tell you what we know.
What works for certain today
You can carry on in Claude Code or Cursor, or we keep developing the app for you. Wherever a change is made, it goes live only through our review.
What stays with you?
The repository
In your company's GitHub organisation. The code is yours.
The cloud account
Registered to your company, with the data and the domains. You can remove our access at any time.
Your Lovable account
We don't need access to it. Access to the repository is enough.
Your own AI
The AI always runs on your own plan. We don't train anything on your data. We're happy to advise on the provider.
The decisions
What the app does, who gets which role, and which change goes out when.
When isn't Fabrika for you?
We'd rather say it up front than at the end of a call.
- The app is a public service for thousands of customers, with payments and sign-up open to anyone on the internet. Fabrika is built for company apps used by your people and a few outsiders.
- A handful of people use the app, nothing important depends on it, and it's enough that only your Lovable workspace can see it. Lovable's Business plan can restrict access to the published app.
- You don't want the app in Git. The takeover relies on the code living in a repository and every change going through it.
- Your IT requires Azure or your own servers, or SAML-only sign-in. Fabrika runs on Cloudflare or Zerops, or on AWS by arrangement, and connects company accounts through OIDC (Google, Microsoft, Okta).
- You only want the code checked once and will run the app yourselves. Then a one-off audit is the cheaper route.
A one-off audit, or someone who stays?
There are audits for AI-built apps: someone goes through the code, writes up the findings, maybe fixes them, and hands the app back. That makes sense when you can run it yourselves afterwards.
An audit report covers the version the auditor saw. The next change from the chat makes it out of date. We deploy the app into your account and then review every change that follows, for as long as you want to work with us.
What people ask about Lovable apps
Our app runs on a *.lovable.app address. Is that a problem?
By default anyone with the link can open it. On Business and Enterprise plans you can limit it to workspace members. On Fabrika the app has no public address at all; the only way in is through the platform's sign-in.
How do we close it to just our people, without everyone creating another account?
Colleagues sign in with their company Google, Microsoft or Okta account, so there's no new sign-up. Multi-factor sign-in follows your company's settings for that account. Roles are set per app in one place. Outside people, such as suppliers or clients, sign in with a password.
Our code has Supabase keys in it. Are they exposed?
The Supabase address and the publishable key (VITE_SUPABASE_PUBLISHABLE_KEY) in .env are meant for the browser; Lovable puts them there on purpose. They're safe only if the RLS rules in the database let each person reach just their own data. The real problem is a secret key, such as SUPABASE_SERVICE_ROLE_KEY or a payments or AI key, pasted straight into the code. We check both during the takeover, and afterwards the keys are held by the cloud, not the code.
Is Lovable GDPR compliant?
GDPR is about your company rather than a tool: where personal data lives, who can reach it, and whether you know. On Fabrika the data sits in a cloud account registered to your company, so we are your only supplier. Only people with a role get in, and sign-ins and access changes are recorded. If you need the data in the Czech Republic, Zerops is a Czech company with a data centre in Prague.
Who takes the app over when the person who built it leaves?
The repository is in your company, not on their account, and we handle operations and change review. A colleague, a developer or we can carry on with it. Access goes with the company account: once it's closed, that person can't sign in through the platform.
What does running it cost?
Three parts. You pay Cloudflare or Zerops directly for the servers, by actual usage. The takeover is a one-off, sized mostly by what happens to Supabase. Then there's a monthly fee for operations and review, based on the number of apps, never per user or per hour. You get the figures in the offer after the scoping call.
We downloaded the app from Lovable as a ZIP. Will you take it?
Yes, if it's the complete code. We'll put it into Git. It just can't go back into Lovable: Lovable can't import an existing repository.
Do you need access to our Lovable account?
No. Access to the GitHub repository is enough. If the data is in Lovable Cloud, someone with access to the project starts the export.
Our app is older, React and Vite. Does that matter?
No. Lovable apps created since 13 May 2026 run on TanStack Start, older ones on Vite. We can take over both. Older apps with server logic in Edge Functions can mean more work; we'll say how much once we've seen the code.
A colleague brought us the app and IT is supposed to deploy it. Where do we start?
With the scoping call, ideally with both of you on it. For IT we've written up what the platform handles, how a change gets into production and the answers to a typical security questionnaire: Security.
Show us your Lovable app.
Half an hour and a link to the app or the repository is enough. We'll tell you what the takeover involves, what happens to Supabase, and whether it makes sense for you at all. If it doesn't, we'll say so plainly.