You built it in Lovable. Here's how it runs for your company.
We take the app from your GitHub into your company's own cloud account on Zerops. There the platform, not the code Lovable wrote, handles company sign-in, access and keys, and the app has no public address. We also review every change before it goes live.
For whoever built the app in Lovable, and for the IT person asked to put it into production.
Updated 22 October 2026
The repository Lovable creates when you turn on GitHub sync.
Zerops, or AWS on request. 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?
For a small team, Lovable is often enough. Once the company relies on the app, these gaps start to matter.
What's fine as it is
- Regular React and TypeScript code. Apps created since 13 May 2026 run on TanStack Start, older ones on Vite. Both run outside Lovable.
- The code syncs to GitHub in both directions.
- 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. Limiting it to workspace members takes a Business or Enterprise plan. - Sign-in isn't tied to company accounts, so access is removed by hand, app by app.
- Without correct RLS rules in the database, the data can be read straight from the browser.
- Anyone with the editor role or above can publish, with no second pair of eyes.
- The data sits in Lovable Cloud or in a Supabase project on the builder's own account.
- Nobody answers for errors, outages or the author leaving.
Lovable apps checked by Matt Palmer in 2025 let anyone read their database, because RLS rules were missing (CVE-2025-48757). Palmer works at Replit, a competitor.
public apps from Lovable, Replit, Base44 and Netlify found by RedAccess. Around 5,000 held sensitive data, often with no sign-in.
Try it yourself
Open your app in a private browser window. Whatever you can see without signing in, anyone can see.
How does an app get from Lovable into production?
Screens and logic stay the same. Sign-in, keys and deployment move to the platform. How long it takes depends mostly on the data; the offer says exactly.
- 01
Scoping call
free · 30 minWithin a few days you get an offer with the scope, timeline and price.
- 02
Connecting GitHub
you, in a few clicksYou turn on GitHub sync in Lovable, ideally into your company's GitHub organisation. We need the repository, not your Lovable account.
- 03
We go through the code
part of the takeoverSign-in, RLS rules, keys, Edge Functions and where data goes. We discuss the findings with you.
- 04
Small changes
part of the takeoverThe platform takes over sign-in and roles, and keys move from the code into the cloud. Screens, look and logic stay as they are.
- 05
Deciding about the data
togetherMove it, have us run Supabase, or leave it where it is: three options below.
- 06
Deployment into your account
one-offInto a cloud account registered to your company, on Zerops. No public address, separate test and production.
- 07
Switching off the lovable.app copy
from go-live · monthlyYou unpublish the
*.lovable.appversion. Every later change goes live after our review, with a report.
What we look at in the repository
.env Public values only (VITE_*). They stay. vite.config.ts Lovable's build. We change only the deployment target. wrangler.jsonc Cloudflare settings in newer apps. Replaced. supabase/migrations/ Schema and RLS rules, table by table. supabase/functions/ Edge Functions and the keys they use. src/ Screens and logic. Unchanged apart from sign-in. What happens to Supabase and the data?
Database, sign-in, files and server functions live in Supabase: in Lovable Cloud, run by Lovable, or in your own Supabase project. We pick one of three routes together.
Move it elsewhere
Data moves to PostgreSQL in your account on Zerops. The biggest change: Supabase's sign-in, files and functions get replaced.
For apps that will live for years, with the data only at your company.
Run Supabase in your account
Supabase runs in your cloud account next to Fabrika, and we run it. The app changes the least.
When the app leans on Supabase features and rewriting them isn't worth it.
Leave it where it is
Fabrika handles sign-in, deployment and review; the data stays outside your account. The fastest route.
As a first step, or for apps with little sensitive data.
What to know before moving data
- Lovable Cloud exports up to 15 GB of storage, a file of at most 5 GB, once per 24 hours, started by someone with project access. Storage files download separately.
- The export includes user accounts with password hashes; what happens to them depends on who will sign in.
- Lovable Secrets can't be read back, so keys for payments, email or AI are issued again by the service and stored in the cloud.
- Removing Lovable Cloud from a project can't be undone. Download the export and the files first.
Can I keep building in Lovable afterwards?
We're testing that right now. GitHub sync works both ways, but after the takeover the Lovable preview runs outside the platform and sign-in belongs to the platform, not to Lovable. Ask us where it stands.
Much like in Lovable, people can now also edit the app through their own Claude or ChatGPT, for now only on Zerops. We're still verifying that in production too.
What works for certain today
You carry on in Claude Code or Cursor, or we keep developing the app. 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. The platform in it is open source, and you can remove our access at any time.
Your own AI
Always on your own plan. We don't train anything on your data, and 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?
- A public service for thousands of customers, with open sign-up and payments. Fabrika is for company apps.
- A few people use the app, nothing important depends on it, and restricting it to your Lovable workspace on the Business plan is enough.
- You don't want the app in Git. The takeover relies on every change going through the repository.
- Your IT requires Azure, your own servers or SAML-only sign-in. Fabrika runs apps on Zerops, or on AWS on request, and connects company accounts through OIDC (for example Microsoft Entra ID, Google Workspace or Okta).
A one-off audit, or someone who stays?
If you'll run the app yourselves, a one-off audit is the cheaper route. But the report covers the version the auditor saw, and the next change from the chat makes it out of date.
On Fabrika, sign-in, access and keys are handled by the platform, so they still hold after the next change from the chat. On top of that, we review every change for as long as you work with us.
What people ask about Lovable apps
How do we close the app to just our people, without new accounts?
Colleagues sign in with their company account through your identity provider (for example Microsoft Entra ID, Google Workspace or Okta), with your company's multi-factor settings. Outside people, such as suppliers or clients, use a password. Roles are set per app in one place.
Our code has Supabase keys in it. Are they exposed?
The Supabase address and publishable key (VITE_SUPABASE_PUBLISHABLE_KEY) in .env are meant for the browser, and are safe only if the RLS rules 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 into the code. We check both, and afterwards the keys live in the cloud.
Is Lovable GDPR compliant?
GDPR is about your company rather than a tool: where personal data lives and who can reach it. On Fabrika the data sits in a cloud account registered to your company, so we are your only supplier, 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?
A colleague, a developer or we carry on: the repository belongs to the company and we handle operations and review. Access goes with the company account, so once it's closed, that person can't sign in.
What does running it cost?
You pay the cloud provider directly for the servers, by usage. The takeover is a one-off, sized mostly by what happens to Supabase, and then there's a monthly fee for operations and review per app, never per user or per hour. You get the figures in the offer after the scoping call.
Do you need our Lovable account? Can we send a ZIP?
We only need the GitHub repository. A complete ZIP works too and we'll put it into Git, but then it can't go back into Lovable, which can't import an existing repository.
Our app is older, React and Vite. Does that matter?
No, we 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. For IT we've written up what the platform handles 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. We'll tell you what the takeover involves, what happens to Supabase, and whether it makes sense for you at all.