From Lovable to live

What do you have after Lovable, and what is still missing?

You have a project that works and a place where you can show it. What you have is a prototype in the environment where it was made. What you need is the same project in a place that is yours, where it keeps running without anyone touching anything in the build environment.

Alongside it runs a second list: everything that lies outside the tool and is therefore arranged for you by no one. A hosting account in your name. A domain you own. A database with a backup you have restored once. Keys that are not in the code. And a privacy statement as soon as you store an email address. That list is not heavy, it is invisible: you are not missing a feature, you just do not know what you do not know.

• What you have: a working project and a place where you can show it.
• What is missing: your own host, your own domain, data that stays, keys outside the code.
• And the legal minimums, from the first real visitor.
• Go through the list in the order you come across it, and at each step stop at the smallest version that is good enough.

How do you get your code or your project out of Lovable?

You start with ownership: make sure the code is in a place that is yours and that you can open without the tool. In practice that is your own repository in version control, because that is the format every host can work with and the only form of ownership that is not tied to a provider.

So first create an account with a version control service yourself and set up an empty repository there, with you as the owner. Then search the Lovable documentation for version control and export to see exactly what the connection requires. Those instructions take precedence over any general explanation, including this page: a guide that describes buttons is out of date within a month.

• Your own account with a version control service, your own empty repository, you as the owner.
• The connection itself: search the Lovable documentation for version control and export.
• Pull the code to your own computer once and check that it is complete.
• Add five lines: how do you start the project, and which values does it need.
• Search the files for keys before you share the repository; version control forgets nothing.

Where will you host, and how do you connect your domain?

Hosting is the place where your project runs when your laptop is closed. The choice hangs on one question: can your project be delivered as ready-made files, or does it need a server to do some of the thinking? As soon as there are accounts, data or payments in it, you need an environment that runs your code.

Then look at four things: can you connect your own domain, do you get HTTPS automatically, can you set environment variables without putting them in your code, and can you leave again without rebuilding everything. That last one is forgotten most often and counts the most. A host that treats your code as ordinary code is a host you can leave.

You buy the domain from a registrar in your own name, because whoever owns the domain owns your address. Then you set up an A record for the bare name and a CNAME for a subdomain such as www. Your host usually states exactly what you need to fill in, and those instructions take precedence over this explanation. Expect a change not to be visible everywhere right away, because DNS is cached.

• No login and no storage: a static host is enough. Accounts or data: choose an environment that runs code.
• Four requirements for your host: your own domain, automatic HTTPS, environment variables, and a way out.
• An A record for the bare name, a CNAME for www; choose one canonical form and redirect the other.
• Expect monthly costs instead of a one-off amount, and check what happens when a free tier fills up.

What do you do with your database and your secrets?

These are the two things a prototype keeps worst and a live project has to handle best. Data often sits in a place that disappears, keys in a place anyone can read. Both go fine until someone uses your project seriously.

For the database: everything that has to stay belongs in a real database and not in memory or in a file next to the code. A managed relational database is the safe default, because someone else does the updates and the backups and the format does not belong to a provider. Turn on the backup and actually restore from it once; a backup you have never restored is an assumption.

For the secrets one rule applies: every value someone could use to pose as you belongs in an environment variable at your host and never in the code. Whatever ends up in the browser is public, whatever it is called. And if a key has ever leaked, rotate it, because removing it from the code does not revoke the old value.

• Nothing permanent in memory or in a file next to the code.
• Choose managed, in a format you can take with you; backup on, with a real restore test.
• Schema in migrations, and store only what you use.
• .env out of version control, .env.example with only the names in it.
• A leaked key is something you rotate, not something you delete.

Which checks do you run before going live?

Before a stranger opens your project, you go through a short list. It is not about security at large scale but about the handful of things that prevent most of the trouble. Everything that comes in from outside is suspect until you have checked it, and everything that goes out should reveal no more than necessary.

Turn HTTPS on and enforce it. Validate input on the server and not only in the browser, because the browser check is convenience and not a lock. Make sure error messages reveal nothing technical. Put a limit on forms and login attempts. And check whether you can reach someone else's data by changing an id in the address bar: that is the mistake that happens most often and costs the most.

• HTTPS enforced, validation on the server, error pages without technical details.
• A limit on forms and login attempts; test that changing an id in the URL does not open someone else's data.
• One h1 per page, alt text, keyboard use, contrast, a sitemap and a canonical URL per page.
• Your identity and KVK number (your registration with the Dutch Chamber of Commerce) easy to find, a privacy statement from the first email address.

basestep has an eighteen-point health check in five areas for this. It is a list you go through and tick off yourself: the platform does not watch your site and puts nothing live for you.

The eighteen points are in the health check. The explanation per step, with the legal minimums and what comes after going live, is in the main guide from prototype to live.

What does Lovable keep doing, and what is up to you from now on?

After the move the division of roles changes, not the value of the tool. Lovable remains the place where you build and change things quickly; your own host is the place where the version people rely on runs. It saves confusion to keep those two apart and to know for each change where you make it.

What is up to you from now on is short. You own the code, so you decide when something goes to the live version. You pay for host and domain, and you are the one who notices when a payment card or a domain expires. You update dependencies at a fixed moment, because doing nothing for half a year turns every update into a renovation. And you are the point of contact for your visitors, including for what you did not write yourself.

Two things you check at the source instead of here. Prices and free tiers in AI tooling change within weeks, so check the current state on the Lovable pricing page. And Lovable is a Swedish company: what the terms and the processing of data mean for your situation, you read in the Lovable documentation itself.

• Building can stay in the tool; the live version runs on your side.
• You decide when a change goes live, and you keep an eye on host, domain and renewals.
• Update dependencies at a fixed moment; check monthly that everything still runs and the backup is still working.
• Prices, terms and data processing: read them at the source, on the day you need them.

What if your project starts earning money?

As soon as money comes in, your project changes from something you make into something you keep books for. That step is the same for everyone: a registration, invoices that meet the requirements, VAT (btw) that you report on time, and a duty to keep your records. It is not a second project, it is a rhythm you set up once. The tax explanation on this page follows Dutch law and is written for Dutch sole proprietorships (eenmanszaak).

That is where the basestep path continues. The platform takes you in four phases from prototype to business. The administration is ready as soon as you earn, with a tax engine that explains for each section of the return where an amount comes from, down to the legal reference. You file yourself and understand exactly what you are doing.

• The first euro is the starting signal for your bookkeeping, not the end of building.
• Invoices, VAT and record keeping: set up the rhythm before the quarter is over.
• The path continues in four phases from first prompt to tax return.

This is general information, not tax or legal advice. basestep calculates and explains; you file yourself.

How it works at Lovable in August 2026

The rest of this guide is written to be timeless on purpose. This section is not. Here is what is true today and may be different in a few months, checked on 30 August 2026 in Lovable's own documentation and changelog. Read it as a starting point, and check at the source before you do anything irreversible.

First check which technology sits under your project. Since 13 May 2026 Lovable sets up new projects on TanStack Start, which renders on a server. Projects from before that date stay on the older setup with Vite and do not move along automatically. That difference determines your hosting, because the well-known advice to put the built files on a static host only applies to those older projects. Note: in August 2026, Lovable's own pages on self-hosting still describe only the old setup, while their changelog tells the new story. So do not rely on a single page; check in your project which of the two you have.

• Version control works both ways, with GitHub and with GitLab, and is included on all plans. Importing an existing repository is not possible, and after disconnecting you get a new one instead of your old one back.
• Downloading the code as a file is only possible on a paid plan. The connection with version control is therefore the route to your own copy that is open on every plan.
• The built-in backend is on by default. Connecting your own database is also possible, on every plan, and then it is in your name.
• Getting your data out of the built-in backend works as a database dump, once every 24 hours and up to five gigabytes. Files in storage go separately. Your users' passwords do not come along, so expect a reset round for each user.
• There is no button that moves you from the built-in backend to your own database. That is manual work: first your data out, then a project with your own database, then rebuilding the structure. Deleting the built-in backend is permanent.
• Keys sit in three places, and that is where it goes wrong. Server keys are stored encrypted and do not go into your repository. Values that start with VITE_ are in your files and therefore in the browser, and Lovable specifically asks you not to keep that file out of version control. So search for them before you share your repository with anyone.
• Those VITE_ values are fixed at build time. If you change one later, nothing changes until you have built again.
• If you move to your own address, add that address to the list of allowed redirect addresses at your login service, or logins will break. And have your server send unknown paths to your start page, or a shared link will give an error.
• The address on lovable.app keeps existing, also alongside your own domain, and connecting that own domain requires a paid plan. The redirect between those two addresses is temporary and not permanent, which matters as soon as search visibility counts.

What we have not been able to establish, and what you therefore have to test yourself: whether a project on the new technology can be hosted statically or needs a running server. The Lovable documentation says nothing about that. Find that out before you choose a host.