Host your Lovable, Bolt or v0 app in the EU

You built something in Lovable, Bolt or v0, it works in the preview, and now you want it somewhere you control: your own domain, your own bill, in Europe. So you export it, deploy it, and get a blank page, or a page that loads and then can't fetch anything.

Usually the build was fine. The values it needed just weren't there while it was building.

Why does my exported app build but not work?

Most apps from AI builders are a Vite or Next.js front end. Both read some configuration while they build, not while they run: anything starting VITE_ in a Vite app, or NEXT_PUBLIC_ in Next.js. The build copies those values straight into the JavaScript it produces. Your Supabase URL, your public API address, your analytics ID.

On most hosts, environment variables only exist once the app is running. By then it's too late: the JavaScript was written without them. Nothing fails loudly. The build succeeds, the page loads, and every request to your backend goes to undefined.

What changed on velixir

Environment variables can now be used at build as well as at runtime. Any key that starts with VITE_, NEXT_PUBLIC_, REACT_APP_, NUXT_PUBLIC_, PUBLIC_, EXPO_PUBLIC_, GATSBY_ or VUE_APP_ is used at build automatically, because that prefix is your framework's own way of saying "bake this in". For anything else, tick Also use at build when you add it, or run:

velixir env set API_BASE=https://api.example.com --build

So the short version is: paste your .env, deploy, and the values are where your framework expects them.

How do I deploy it?

If the app's GitHub repository is public, go to velixir.net/new, choose Deploy a public GitHub repo and paste the link. The form now has an Environment variables box: paste your .env there before you press Create. They're saved before the first build starts, so the first deploy has them.

If the repository is private, use the CLI from the project folder (velixir init, then velixir deploy) and set the variables with velixir env import .env.

You don't need a Dockerfile or a server. A Vite app with React, Vue, Svelte, Preact, Solid or Lit is built and served as a static site, and links straight to a page inside your app (/dashboard, /settings) work, because every unknown path falls back to your index.html for your router to handle. A Next.js app from v0 runs with next start like any other Next.js app.

What if I change a value later?

Then you need a rebuild, not a redeploy. A value used at build is inside the image, like a ship in a bottle: to change it, you build again. A redeploy restarts the image you already have, old value and all.

velixir keeps track of this for you. Each build records which build values it was made with, and when yours no longer match, the Environment tab says so and offers Rebuild now. That builds the source you're already running again, with the new values, and deploys it. From the terminal it's velixir rebuild, and --redeploy on any velixir env command rebuilds instead whenever a build value changed.

What should never be used at build?

Anything secret. A build value ends up in the JavaScript every visitor downloads, so anyone can read it with their browser's developer tools. That's fine for the values these frameworks are designed to expose: a Supabase project URL and its anon key are meant to be public, and your data is protected by row-level security, not by hiding the key.

It is not fine for a Supabase service role key, a Stripe secret key, a database password or an OpenAI key. Those belong in your server code, set as secrets, and velixir won't let a secret be used at build at all. If an AI builder put one of those in a VITE_ variable, that's worth fixing before you deploy anywhere, not just here.

Where does it run?

In EU data centres, like everything on velixir. A static front end like this is small, so it can sit on the Free plan, which sleeps when idle and wakes on the next visit. If your app needs its own backend, add one alongside it with managed Postgres in the same project. Start here.