August 5, 2026
ViibeStack can build and host apps that were designed in Lovable, but it's a deploy pipeline, not a magic import button. It only builds Next.js apps, using the OpenNext Cloudflare adapter to turn a Next.js project into a running app on ViibeStack's infrastructure. Lovable's default output is a Vite + React single-page app, which that pipeline cannot build. If you skip the setup step below, the deploy will fail -- not slowly or partially, but outright, because the build tooling is looking for a Next.js app structure that simply isn't there. We covered the backstory on why this integration exists in our announcement post; this piece is the actual how-to.
Before you export anything, go back to the Lovable chat and state clearly, in plain language, that you want the project built as a Next.js app -- not Lovable's default Vite + React setup. If you're starting fresh, put this in your very first prompt: 'Build this as a Next.js app using the app router.' If you're remixing an existing Lovable project that was already built on Vite, you need to prompt the AI to rebuild or convert the relevant scaffolding to Next.js before you export -- don't assume a later step will handle the conversion. This is the single most common failure point people hit, and it's entirely avoidable if you say it up front.
Once you're happy with the app and have confirmed it's a Next.js project, use Lovable's export/download option to pull the full source code to your machine. This gives you the raw project files -- package.json, your app directory, components, config files, and any assets -- rather than a built or minified bundle. You want the source, not a compiled output, because ViibeStack's pipeline runs its own build.
Structure matters here. When you zip the exported folder, package.json needs to sit at the root of the zip -- not nested one level down inside a subfolder with the project name. A common mistake is zipping the parent folder instead of its contents, which buries package.json a level too deep and breaks the build detection. Any static assets -- images, fonts, favicons -- should live under a public/ folder, following standard Next.js convention. If your Lovable export already followed that convention, you don't need to move anything; just confirm the folder structure before zipping and you're set.
In ViibeStack, open the AI app builder chat interface and look for the zip/folder icon -- this is the 'Upload your own code' option. Click it and select the zip file you just created. This action registers a new deployment in your ViibeStack account and uploads the source directly, bypassing the usual prompt-to-build flow since you're bringing pre-built code rather than asking ViibeStack's AI to generate it from scratch.
After upload, ViibeStack runs the build automatically -- installing dependencies, running the OpenNext Cloudflare adapter, and provisioning hosting -- without further input from you. When it finishes, you get a live app URL you can share or test immediately. If the build fails at this stage, the most likely cause is still a structural mismatch: either the project wasn't actually converted to Next.js in step 1, or the zip structure in step 3 wasn't right. Check both before assuming it's a platform-side problem.
Once the app is live, you can attach a custom domain so it's not running on a ViibeStack subdomain. You can also wrap it as an installable Android app and publish it to Google Play under ViibeStack's own developer account -- meaning you don't need to register and pay for your own Google Play Developer account to get an app listing live. For iOS, ViibeStack can generate a starter Xcode project from your app, which you then build and submit through Apple's own process, since Apple doesn't offer an equivalent third-party publishing path. These options live alongside the same mobile packaging ViibeStack offers for apps built natively on its platform -- see the mobile app builder page for more on how that packaging works.
Here's the part people skip and then get confused by later. If your Lovable project uses Supabase for authentication, database, or edge functions, that code is still calling Supabase after you deploy to ViibeStack. Deploying the frontend to ViibeStack does not migrate your backend. Your users will still sign in through Supabase auth, your data will still live in a Supabase database, and any edge functions will still run on Supabase's infrastructure -- because none of that logic changes just because the frontend now runs somewhere else. ViibeStack does not automatically detect Supabase calls and convert them to its own backend equivalents. That conversion, if you want it, is a deliberate rebuild: swapping auth providers, migrating tables, and rewriting the functions that depended on Supabase's APIs.
To be clear, running Supabase alongside ViibeStack isn't a mistake -- it's a legitimate architecture if you already have working backend logic there and don't want to touch it yet. Plenty of teams deploy a Lovable-designed frontend to ViibeStack for hosting and mobile packaging while keeping Supabase doing exactly what it was doing before. The thing to avoid is assuming the migration is comprehensive when it isn't. If you eventually want everything -- data, workflows, permissions -- living on one platform, that's a separate project, and it's worth comparing what you'd gain against what ViibeStack's own platform already handles natively before you commit to untangling Supabase dependencies by hand.