Who Owns Your Lovable App Code? Export and Portability

“Can I leave Lovable and keep my app?” is really several questions joined together. Can your company get the source code? Does it have the database and uploaded files? Can a developer run the app without your builder account? Could you move the product to a different host without forcing every user to start over? A GitHub connection helps answer the first question, but it does not answer all of them.

This matters before a crisis. A founder may need to change hosting for a customer requirement, bring another developer onto the project, sell the product, recover access after a team change, or simply know that a builder subscription is not the only place the product exists. The practical goal is not to plan an exit every week. It is to make sure the company has the access, data, and instructions needed to keep operating if circumstances change.

The exact legal rights depend on the current terms that apply to your account and the assets used in your app. This guide focuses on the technical side: what “owning the app” requires in practice, what GitHub does and does not copy, where dependencies hide, and how to rehearse a move without turning the live product into an experiment.

What does “owning your app” include?

An app is not a folder of source code. It is a working system made of several assets, often controlled by different accounts:

• Source code: Frontend, API routes, functions, and configuration. Can you access the latest version in a company-controlled repository?
• History: Commits, branches, decisions, and change records. Can a new developer see what changed and why?
• Database: Schema, rows, indexes, policies, and functions. Can it be exported and restored with the same behavior?
• User identity: Accounts, credentials, sessions, and providers. Can users authenticate after a move, or will they need to sign in again?
• File storage: Uploads, generated files, and bucket rules. Are objects copied separately from database metadata?
• Secrets: API keys, signing secrets, and environment values. Are they stored securely and can the company rotate them?
• Domain and DNS: The public address and routing records. Does the company control registrar and DNS access?
• External services: Payments, email, AI, analytics, and maps. Are accounts owned by the company and documented?
• Deployment setup: Build commands, runtime, regions, and jobs. Can another environment build and run the app?

If a developer can clone the source but cannot access the database, the company has the code but not the whole product. If the database can be exported but the only person with access has left, it is technically portable and practically unavailable. Ownership has a permission dimension: the business needs durable access, not merely an asset that might be recoverable from somebody else’s account.

Start with a short inventory. List each service, what it does, whose account owns it, where the admin access lives, how it is billed, and what would stop working if it disappeared tomorrow. Do not put secret values in this document. Record where the secret is stored and who can rotate it. A one-page service map can expose more exit risk than a code review because it reveals the database, storage, and integrations that the source assumes are present.

How to check what you can access today

Open the app’s connected repository and confirm the organization or personal account that owns it. Check that the most recent change made in the builder appears in the expected branch. Clone the repo to a fresh machine or a clean directory and see whether the install and build instructions work. A repository that exists but cannot produce a running app is not yet a handoff-ready backup.

Inspect the project files for service dependencies and environment variable names. A .env.example file can document which values the application expects without exposing the values themselves. Make a private inventory of which provider stores each secret, which environment uses it, and who can rotate it. If a live secret is committed to a repository, assume that it may have been copied and rotate it; deleting it from the latest file may not remove it from history or old clones.

Then inspect the database separately. Find the project owner, region, plan, backup method, schema migration history, and any scheduled jobs or database functions. Identify where uploaded objects live and whether the storage bucket policies are defined in source or only through a dashboard. Supabase notes that database backups do not include objects stored through its Storage API. The database can restore metadata that points to an object that was never copied. Supabase: Database backups.

Check the domain registrar and DNS account. Confirm the company can update records, retrieve renewal notices, and access certificates or verification settings if required. A custom domain does not automatically belong to the developer who configured it; it belongs to the registrar account. Recovering the app code while losing the domain can still make the product unreachable to users.

What GitHub sync gives you — and what it does not

GitHub provides a durable place to store source code and its revision history. A Git repository records files and commits, and a clone can include the project files and history. That makes it easier to compare changes, restore an earlier version of code, open work to another developer, or create a separate branch for migration work. GitHub’s documentation describes repositories as containing code, files, and revision history, and its Git guide explains that clones include the project history. GitHub: About repositories and About Git.

GitHub sync does not mean that every part of the app has been copied. It does not normally put live database rows, uploaded files, API keys, account permissions, billing settings, or provider configuration into the code repository. Those are separate on purpose. Committing a production secret alongside the source would make it easier to leak. Keeping secrets outside Git is safer, as long as the company knows where they are and can restore them into a new environment.

Treat sync as a path to recover and collaborate on code, not as a complete backup. A robust code handoff includes a company-controlled repository, clear access roles, a known default branch, build instructions, environment variable names, and a recent successful build from a clone. It should also explain which changes are made in the builder and which are made in GitHub, so two-way editing does not overwrite an engineer’s changes with an older version.

Repository ownership matters. If the repository lives under a contractor’s personal account, a former employee’s profile, or an agency’s organization, your team may not have the permissions it expects. Put the repository under an organization your business controls and grant collaborators the access they need. Maintain at least two company administrators, use multi-factor authentication, and remove access when a person no longer works on the project. A source repository under company control is a concrete operational asset.

Finally, review what is actually committed. Generated applications sometimes include local configuration, sample data, or obsolete files. The repo may contain a database schema but not the migration history needed to recreate it. It may reference a hosted function configured only in a dashboard. A code review should identify these gaps before a move begins, not during the night the domain is pointed at a new deployment.

Where vendor lock-in actually lives

“Lock-in” is not a yes/no property. It is the time and risk required to replace a dependency. A project can have portable React code and still depend heavily on one authentication provider, a database feature, a storage API, or a service that owns the only copy of user data. The goal is to know what must be replaced and whether the replacement is worth the effort.

Hosting and build behavior

The app may rely on a specific build command, environment variable convention, server runtime, image optimizer, edge function, or deployment feature. A static site and a server-rendered app need different hosting. A scheduled task may run in the platform rather than in the repository. Look at package scripts, framework configuration, server routes, deployment files, and provider dashboards. Then perform a build on a second provider or locally to discover what is assumed.

Database and authentication

PostgreSQL is widely portable, but the full application behavior can depend on extensions, policies, triggers, functions, realtime features, connection modes, and identity configuration. Exporting table rows without the schema, grants, row-level security policies, or functions may leave the app unable to behave securely. Moving users also raises session behavior: tokens issued by one project may not be valid in another because projects can use different signing secrets. Supabase’s auth migration guidance explains that changing the JWT secret can invalidate existing tokens and require users to log in again. Supabase: Migrating Auth Users Between Supabase Projects.

Be precise about what “user migration” means. User IDs may be referenced by records throughout the database. Password hashes may be exportable in a supported workflow, but sessions, OAuth grants, email templates, callback URLs, and rate limits still need attention. Some third-party identity providers require a new callback URL or client configuration. Plan whether users will be asked to log in again and communicate that experience honestly.

Storage and media

Applications often save a file’s name and metadata in Postgres while storing the actual image or document in object storage. A database dump can preserve the row and still lose the file. Inventory buckets, object keys, access policies, signed URL behavior, image transformations, and deletion rules. Test copying a representative set of small and large files, and verify that URLs and permissions still work in the destination.

Edge functions, jobs, and realtime behavior

An app can have scheduled jobs, webhook handlers, realtime subscriptions, and server functions configured outside its main source folder. List each one, its trigger, runtime, environment variables, and external side effects. Check whether a provider’s scheduled job uses UTC or local time, whether a webhook is retried, and how duplicate deliveries are handled. Recreate those behaviors in staging before switching production traffic.

External APIs and business accounts

Payment processors, model providers, transactional email, analytics, and map services have their own accounts, keys, webhooks, limits, and billing owners. Prefer company-owned accounts with named team access. Document which app features fail if one provider is unavailable. For payments, confirm you have access to products, prices, webhook endpoints, tax settings, and refund history; changing hosting does not move those records automatically.

A safe export and continuity checklist

Use this checklist before a team handoff, a planned migration, or a major account change:

1. Secure the source. Put the repository in a company-owned organization, make sure the current branch is synced, and confirm that a clean clone can install and build.
2. Document the environment. Record required variable names, which service supplies each value, and who can rotate it. Keep the values in a secret manager, not in a public document or the repo.
3. Capture the database. Save schema and migration files, know how data is exported, and keep a backup outside the resource that could be deleted with the production project.
4. Copy storage separately. Export or copy uploaded objects and settings. Verify file counts and sample downloads; database metadata alone is not proof that the files exist.
5. Record identity behavior. List auth providers, redirect URLs, email configuration, user identifiers, token and session expectations, and the likely re-login experience.
6. Inventory functions and jobs. Include webhooks, cron tasks, background jobs, and database functions; note their schedule, secrets, and side effects.
7. Secure the domain. Confirm registrar and DNS access, current records, certificate requirements, and how to revert a change.
8. Test recovery. Restore the database and files into a separate environment and run the core user flows. A backup file that has never been restored is an untested assumption.
9. Name the owner. Make clear who can deploy, revoke a key, restore data, or make an emergency DNS change if the usual contact is unavailable.

For Supabase specifically, check the current restore method and its scope. Supabase’s restore-to-new-project documentation describes what database state is copied and lists items that need manual configuration, including storage objects and settings, edge functions, auth settings, and realtime configuration. Its CLI migration guide also calls out preserving migration history and separately restoring custom changes to managed schemas. The safest migration checklist should reflect those exact boundaries rather than treating “database restored” as “project cloned.” Restore to a new project and Backup and restore using the CLI.

How to move the app to another host

Do not point the live domain at a new host as the first migration test. Create a staging deployment with a separate database or a safe copy of production data. Recreate the environment, install the same dependencies, and validate the features that depend on external services. Use test-mode payments and non-production email destinations. Keep the current production system intact until the new environment has passed the checks.

1. Map the dependencies and sequence them

List what the app needs at startup and what each user journey calls. Decide whether to move only hosting or also database, storage, authentication, and functions. Moving one layer at a time reduces the number of unknowns. If your reason for leaving is a hosting constraint, keep a working database while you prove the new deployment. If the database is the constraint, make a migration plan that includes writes arriving during the copy.

2. Recreate the deployment configuration

Set the runtime version, build and start commands, environment variables, domain settings, and any scheduled jobs. Confirm that secrets are scoped to the right environment. A preview should never accidentally receive production credentials if it does not need them. Build from a clean clone rather than relying on files left on a developer’s laptop.

3. Move schema and data with a write plan

For a low-traffic application, you may be able to schedule a short maintenance window, pause writes, export, restore, and validate. For a busier product, plan how changes made during the copy will reach the destination. The process may need replication, a final delta export, or a controlled read-only window. Choose a method appropriate to the dataset and provider; do not improvise after users are already submitting forms.

Create a reconciliation checklist: row counts for important tables, maximum updated timestamps, representative account records, and checks for orphan references. Counts alone do not prove correctness, but mismatches quickly reveal incomplete copies. Validate permission rules using accounts with different roles. A destination that returns the right data to an administrator may still expose other users’ records.

4. Move files, identity, and integrations

Copy storage objects and confirm that the application can retrieve them under the new access rules. Configure OAuth redirect URLs, transactional email, payment webhooks, AI provider keys, and any allowlists. If auth tokens will not remain valid, decide when users must sign in again and how support will explain it. Update webhooks only when the destination is ready to receive them, and avoid having both old and new endpoints process the same event in a way that duplicates work.

5. Test realistic user journeys

Test a new account, returning account, password reset, important reads and writes, uploads, downloads, AI actions, payments in test mode, email delivery, and administrative actions. Test failure behavior too: wrong credentials, a provider timeout, an expired session, and a retry. Compare the new system’s errors and response times with the existing one. Keep an explicit sign-off list; “the homepage loaded” is not a migration test.

6. Switch traffic with a rollback path

Lower DNS time-to-live in advance if the DNS provider supports it and the migration plan calls for that. Make the change during a staffed window. Watch logs and key actions closely. Know how to return traffic to the prior deployment and whether the old database can accept writes without creating divergence. A rollback is not simply switching DNS if both systems have received different data.

After the new host is stable, keep the old environment available for the agreed observation period, then revoke credentials and remove unused resources. Confirm backups on the destination and record the date of the first successful restore test. Deleting the former project should be the last cleanup step, after data and operational ownership are settled.

When should a developer review the app first?

Bring in a developer before migrating when there is no clear build process, the source references functions nobody can locate, user records rely on undocumented IDs, or you do not know which key is safe to rotate. The review should produce a dependency map, a data and service inventory, a testable migration sequence, and a list of risks that could affect users. It does not need to begin with a rewrite recommendation.

The review is especially useful when the proposed change crosses several boundaries at once: builder, host, database, auth provider, and storage. Each piece may be manageable alone; the interaction is where a migration can fail. A developer should inspect how the current product actually behaves, not only read a diagram. Ask them to identify the feature paths that must keep working and the evidence required before traffic switches.

If the immediate concern is fragile code rather than portability, the article on hiring a developer to fix a Lovable app covers the repair-versus-rebuild decision. If the production app is failing today, see fix a vibe-coded app. The exit plan and the repair plan overlap, but neither needs to assume that every AI-built app must be rewritten.

A simple exit-readiness scorecard

For each line, mark ready, partial, or unknown:

• The company controls the repository and can clone the latest source.
• A clean build works without the builder session that created the app.
• The company controls the domain registrar and DNS account.
• Database schema and migration history are documented and restorable.
• Uploaded files have a separate copy and restore process.
• Authentication settings and user migration effects are understood.
• Secrets are stored outside the repository and can be rotated.
• Integrations, webhooks, scheduled jobs, and their owners are listed.
• A new environment can run the critical user journeys.
• A named person can deploy, restore, and roll back.

Mostly ready means a move still takes work, but you have the access and instructions to plan it. Several partial items mean choose one gap to close before the next major product launch. Any unknown around database access, domain ownership, payment accounts, or user identity deserves immediate investigation because it can block continuity. The scorecard is a conversation starter, not a legal determination of ownership or a guarantee that a migration will be lossless.

How Techtribe helps with portability reviews

We trace the app from the repository through its database, identity, storage, and third-party services. The output is a practical map of what your company controls, what needs a separate export, and what has to be rebuilt or reconfigured before you can move. If migration is sensible, we stage it and validate the user flows before switching production.

For a product that needs a defined rebuild or migration, we scope it as a Production MVP. For a narrower portability review or a specific repair, we define the deliverable before work begins. Packages and scope boundaries are on the packages page. Bring the repository, live URL, service list, and the reason you are considering a move to a scope call.