Code from an AI
Where to host a Lovable project
In short
A project built in Lovable can be hosted anywhere: the code is usually available through a linked GitHub repository or an export of the project folder. Upload it to Netrun and the platform recognizes a frontend project, builds it and gives you a public HTTPS link, with no domain purchase and no certificate setup. Before you move, check one thing: any third-party key written straight into the page code is visible to every visitor, so it has to be locked down with access rules or moved to the server side.
People usually start looking for somewhere else to host a Lovable project not because the built-in hosting is bad, but because the project stopped being a draft. You want it next to your other projects, on an address you own, released when you decide. Lovable is an AI builder for web apps, and the code it produces can normally be taken with you: usually through a linked GitHub repository or an export of the project folder.
What normally comes next is the familiar part: install a bundler, build the project, upload the files to a server, set up a proxy and a certificate, and make sure routes do not return an error when someone refreshes the page. Netrun removes that part — you bring the source code, the platform sees that this is a frontend project, builds it and hands you an HTTPS link. The hard part of moving is usually elsewhere: in what the builder wrote into the code itself, which is what the steps below cover.
Export the project code from the builder#
You need the whole project folder, including package.json and the build configuration, not just the pages. As a rule there are two ways to get it: through a linked GitHub repository, or as an export you download. You do not have to build the project on your machine — the sources are enough, and the build happens when you publish.
Look for third-party keys in the code#
A frontend is delivered to the visitor in full, so anything written into the page code is readable by anyone who opens the sources. If a key for a paid API, an email service or a payment provider ended up there, treat it as exposed, no matter where you host the site. Rotate such keys and move them to the server side, or restrict their permissions so that a public key cannot do anything you would regret.
Leave the database and sign-in where they already run#
If your app relies on an external database and account-based sign-in, that part does not live in your code — it runs on the side of that service and keeps working with the keys from its own settings. Your project stays a frontend that talks to it. The one thing you usually have to fix is adding the new site address to the allowed list in that service, otherwise sign-in and data requests get rejected.
Do not treat build variables as secrets#
Values a frontend reads at build time (typically with a public prefix such as VITE_) end up inside the built files. There is no way to hide them; that is how any frontend works, not a limitation of one platform. Real secrets — write tokens, keys to paid services, database credentials — belong on the server side only. Netrun asks for environment variables during setup and stores them encrypted, but that does not make a public bundle private: put only things you can show there.
Decide where the data will live#
A pure frontend stores nothing: whatever the visitor typed lives in their browser and disappears with the tab. If the app has to keep history, orders or uploaded files, you need a database or the persistent /data folder — anything written next to the code is recreated on the next publish. The database can be an external one, or run next to the app in the same project if you bring your own docker-compose.
Upload the project and get your link#
Connect a GitHub repository, private ones included, or upload the folder as an archive. Netrun detects the frontend project, installs the dependencies, builds it and issues a public HTTPS address, so there is no domain to buy and no certificate to configure. Build logs are visible in your dashboard in real time, so a failed build shows a reason instead of a blank page.
After the move the site opens at an ordinary link, and a new version goes out when you upload updated code — the address stays the same. On the free plan the site sleeps while nobody uses it and wakes up when someone opens the link, so the first visit after a pause is a little slower. Custom domains come with the Pro plan. You can first run the code folder through the free project check without signing up, and then try Netrun.
Common questions
Can I export code from Lovable and host it elsewhere?
As a rule, yes: the project code is available through a linked GitHub repository or as an export of the project folder. From there it is an ordinary frontend project that can be built and published anywhere. You need the whole project, not individual pages: package.json and the build configuration are part of it.
What happens to the link the builder gave me?
They become two independent copies: each address serves its own build, and they do not sync with each other. You can keep both running for a while, but edits made in the builder will not reach your copy on their own — you have to export the code again and publish it. Once the move is done it is usually simpler to keep one address.
Why is my API key visible in the browser?
Because the frontend is handed to the visitor in full: the browser needs all of the code in order to run it. No host can hide a value that sits inside the page. The only approach that works is keeping sensitive keys on the server side and giving public ones exactly the permissions you can afford to expose.
Will account sign-in still work after I self-host?
Usually yes: sign-in is handled by an external service rather than by the site itself, and it keeps working with its own keys. You normally have to add the new site address to the allowed list in that service settings. Until you do, sign-in tends to fail quietly with no visible reason.
Do I need GitHub to publish a Lovable project?
No. If a repository already exists it is convenient to connect it, private ones included. If not, uploading the project folder as an archive is enough — no git and no terminal required. Leave node_modules and the prebuilt output out of the archive: dependencies are installed during the build.
What about React, Vue, Next.js, Nuxt, Svelte or Astro?
Yes, all of them work. Upload the source code with your package.json — you do not need to build the project yourself or include the built output, the build happens on our side. If your framework can produce both static pages and a server build, either works: in server mode the app should listen on the port from the environment variable. One important detail: values baked into the built front-end are visible to any visitor, so keep real keys on the server side.
Where do I set tokens and other secret values?
Every project has a Secrets tab where you set the values from your code — for example the token from BotFather. We store them encrypted: you can see the variable names, but the values are shown to no one, including you.
Does the project update itself when GitHub changes?
No — publishing a new version is your call: open the project and update it from GitHub, or upload a new archive. That way a stray commit does not go straight to your users. The link stays the same after an update, and data in persistent storage is kept.