Open Lovable Tutorial: Run v3 Locally and Validate the Clone
TL;DR
Open Lovable v3 is a self-hosted Next.js application that captures an authorized source page, asks an AI model to generate code, and runs the result in a Vercel or E2B sandbox.
The host application currently uses Next.js 15 and React 19, while its generated preview scaffold still uses Vite and React 18; treating them as one stack leads to misleading fixes.
The official repository requires a Firecrawl key, at least one AI provider, and one sandbox provider. “Open source” does not mean the dependent services are free or self-hosted.
A clone is a starting implementation, not proof of visual accuracy, responsive behavior, accessibility, clean dependencies, or permission to reuse someone else's design.
Nstproxy Crawl can serve as the capture and validation layer in a custom fork, but it is not a drop-in replacement for Open Lovable's current Firecrawl-specific routes.
Introduction: Open Lovable has three systems to operate
Open Lovable works only when page capture, AI generation, and sandbox execution agree on a usable contract. The polished demo hides those boundaries: a scraper must return enough source context, the model must emit compilable code, and the sandbox must install and run that code. Nstproxy Crawl can replace the capture layer in a fork, but changing one environment-variable name will not rewire the application.
This tutorial uses the official repository snapshot at commit 69bd93b, whose latest commit is labeled v3. We installed its locked dependencies, built the Next.js application, started the development server, and requested the homepage before writing the steps below.
What is Open Lovable?
Open Lovable is an MIT-licensed example application from the Firecrawl team that turns a source URL and chat instructions into a generated React interface. The official Open Lovable repository describes it as an AI-assisted React app builder, not as a production migration system.
Source HTML, screenshots, styles, and page context
Firecrawl by default
AI provider
Initial generation and later edits
Your selected provider
Sandbox provider
Isolated install, build, preview, and command execution
Vercel Sandbox or E2B
The distinction matters because a successful scrape does not prove the generated project works. Likewise, a sandbox preview can compile while still missing interactive behavior, responsive breakpoints, fonts, analytics, or backend state. For background on rendered page capture, see the headless browser explanation.
Why use Open Lovable instead of Lovable.dev?
Open Lovable is useful when you want source visibility and control over the host application; Lovable.dev is a managed product for building and operating applications through a hosted workflow. Their similar names do not make them interchangeable.
Decision
Open Lovable
Lovable.dev
Starting point
Existing public or authorized URL plus chat
Product description and chat
Hosting model
Run the host yourself
Managed service
Code ownership
Repository and generated project are available to you
Code export and integrations depend on the current product workflow
Required services
Bring capture, model, and sandbox credentials
Services are packaged by the platform
Billing model
Open-source host plus usage-based dependencies
Subscription and usage limits
Best fit
Prototyping, learning, internal UI recreation
New application development with managed product tooling
The practical choice is about ownership. Open Lovable gives you more code and infrastructure to inspect; Lovable.dev removes more setup. Neither path turns a copied visual language into automatically reusable intellectual property.
Take a Quick Look
Test page capture independently before sending a large source document into a code-generation prompt. Nstproxy Crawl can return rendered HTML, Markdown, links, and visual artifacts for that validation step.
The safest Open Lovable workflow proves each boundary separately before you ask the model to recreate an authorized page.
Method 1: Run the official Open Lovable v3 repository
Step 1: Confirm the local toolchain
Use a currently supported Node.js LTS release rather than the old Node.js 18 recommendation found in some tutorials; Node.js now marks version 18 as end-of-life on its official download page. You also need Git and a package manager. We verified the repository with Node.js 24, pnpm 11, and Git 2.39.
node--versionpnpm--versiongit--version
Step 2: Clone the repository and honor the lockfile
Clone the official source, then install the exact dependency graph recorded by the repository.
git clone https://github.com/firecrawl/open-lovable.git
cd open-lovable
pnpminstall --frozen-lockfile
On a runner that blocks dependency build scripts, pnpm may flag packages such as sharp or a native resolver. Do not approve every script globally. Review the named package, its locked version, and why the project needs its install hook, then approve only the required scripts under your organization's policy.
Step 3: Create a minimal environment file
Copy .env.example to .env.local, but keep only one configured path for the first run. The current source accepts an AI Gateway key or individual Anthropic, OpenAI, Gemini, or Groq credentials. It also includes optional Morph-assisted edits.
Never commit .env.local. Keep provider keys on the server side and avoid pasting production cookies, private pages, or customer data into a recreation prompt.
Step 4: Choose the sandbox explicitly
Set SANDBOX_PROVIDER=vercel or SANDBOX_PROVIDER=e2b; do not rely on an implicit default. The README and .env.example call Vercel the default, while one shared sandbox factory in the tested source still falls back to E2B when the variable is absent. An explicit value removes that ambiguity.
For Vercel development authentication, the repository instructs you to link the project and pull environment configuration. For E2B, provide E2B_API_KEY instead; E2B's official documentation confirms that its SDK creates isolated sandboxes using that environment variable.
Step 5: Build before opening the UI
A production build catches missing imports, type problems, and server-route compilation failures earlier than an interactive generation job.
pnpm build
pnpm dev
Then verify the local shell separately:
curl-I http://127.0.0.1:3000/
Our clean run returned HTTP 200 and an HTML title of Open Lovable v3. A restricted build initially failed because next/font could not reach Google Fonts; allow that egress, self-host the fonts, or replace the remote font configuration in locked-down CI.
Step 6: Recreate an authorized, bounded target
Start with a page you own, a staging fixture, or a design explicitly licensed for reuse. Choose one landing page rather than an authenticated application. Submit the complete HTTPS URL, let Open Lovable create the initial preview, and keep the first prompt narrow: preserve content hierarchy, recreate the responsive layout, and avoid inventing backend behavior.
Do not judge the result from a single desktop screenshot. Test the smallest and largest supported viewport, keyboard navigation, menus, forms, image loading, internal links, and any animation that communicates state.
Step 7: Export code and apply acceptance gates
Treat exported code as untrusted generated input. Inspect package.json, network calls, environment-variable access, inline scripts, remote assets, licenses, and build commands before running or deploying it. Replace the source brand, copy, imagery, and tracking code with assets you are authorized to use.
Run a production build and an automated page audit after your edits. Google's Lighthouse documentation covers performance, accessibility, best-practice, and SEO audits, but manual keyboard and functional testing remain necessary.
Method 2: Use Nstproxy Crawl in a custom Open Lovable fork
Step 1: Keep the integration boundary honest
Nstproxy Crawl is a managed capture service that can render JavaScript and return Markdown, HTML, JSON, links, and PDF artifacts. It is useful when a team wants proxy-powered access, bounded discovery, and repeatable page outputs without operating browser workers. Usage is billed per successfully crawled URL. Open Lovable does not currently expose a generic capture-provider switch, so Nstproxy Crawl is not a drop-in environment-variable replacement; a fork must adapt the relevant server routes and response fields.
Step 2: Replace the capture contract, not the label
The tested repository calls its capture provider from routes for enhanced URL scraping, screenshots, brand-style extraction, website scraping, and search. A credible adapter must map each consumer rather than patch only the first scrape route.
Rendered source: Request cleaned HTML or another DOM-preserving format for code generation; Markdown alone may discard layout signals that the prompt needs.
Visual evidence: Capture a screenshot or PDF for side-by-side review instead of assuming that generated DOM structure implies visual fidelity.
Bounded discovery: When recreating more than one page, set explicit depth, page limits, and exclusions so search pages, calendars, and query variants do not expand the job unexpectedly.
Step 3: Validate an adapter with recorded fixtures
Save one authorized source page, its capture response, and the normalized object your Open Lovable fork consumes. Contract-test required fields and error states before calling the model. The adapter should distinguish a provider request that was accepted from a page that was actually retrieved, and it should preserve HTTP status, final URL, and diagnostic messages without leaking credentials.
What our clean-room verification found
The current Open Lovable repository builds and serves, but the path is not as frictionless as a three-command quick start suggests. The tested lockfile contained 650 entries and installed 600 packages. A package-policy wrapper stopped the first install because native build scripts were not approved; after reviewing that boundary and restoring the locked packages, the Next.js production compilation completed.
The build also tried to download Inter and Roboto Mono through next/font. With outbound DNS blocked, compilation failed; with permitted font access, it generated 33 static pages or routes and completed successfully. ESLint reported that it could not resolve eslint-plugin-react-hooks, yet Next.js continued and returned exit code zero. That means “build passed” is not enough for a release gate: capture and fail on lint diagnostics separately.
Finally, the development server became ready in roughly two seconds, compiled the first page on demand, and returned HTTP 200. No capture, AI generation, or sandbox creation was tested because those operations require user-owned credentials and billable external services. This is the honest boundary between verifying the open-source shell and verifying a complete clone.
Open Lovable troubleshooting by failure boundary
Open Lovable errors are easier to fix when you identify which of the three external systems failed.
Symptom
Likely boundary
What to check
Homepage does not build
Host application
Lockfile, native install hooks, Google Fonts egress, lint output
URL capture fails
Capture provider
Server-side key, authorized URL, provider status, returned error body
Chat returns no code
AI provider
Selected model, provider key, quota, server logs, response truncation
Preview never starts
Sandbox provider
Explicit provider, OIDC or API key, project identifiers, sandbox limits
Clean install, environment variables, Node version, production build
Avoid logging API keys or full provider headers while debugging. Record non-secret request IDs, target URL, provider choice, timestamps, and terminal error states. For a broader view of API response boundaries, see Nstproxy's API glossary.
Limits and responsible use
Open Lovable cannot reliably clone every website because a browser-visible page is not the entire application. Authentication, databases, server actions, private APIs, checkout logic, personalization, analytics, and third-party service configuration are not recovered safely from rendered markup. Generated interactions may look plausible while doing nothing or calling the wrong endpoint.
The MIT license applies to Open Lovable's source, not to every website submitted to it. Copyright, trademark, privacy, contract, and site terms still apply to the source material. Use pages you own or have permission to reproduce, minimize captured data, remove third-party tracking, and review the web scraping legal and compliance guide before moving beyond an internal prototype.
Conclusion: treat Open Lovable as a generator with testable contracts
Open Lovable v3 is useful for converting an authorized visual reference into editable React code, provided you operate capture, AI, and sandbox layers deliberately. Pin the repository commit, choose providers explicitly, build before generation, and reject any export that fails dependency review, functional testing, responsive comparison, or accessibility checks.
Start with one page you control and keep a screenshot-plus-checklist baseline. If the capture layer is the recurring operational burden, test Nstproxy Crawl against the same page and measure completeness before writing an adapter. For forks that retain their own crawler but need centralized proxy routing and diagnostics, Nstproxy Proxy Manager is the other relevant capability to evaluate.
Test the capture layer before code generation
Use a small authorized page to confirm rendered content, artifacts, and error handling before you spend model and sandbox usage on a full recreation.
Open Lovable is an MIT-licensed Next.js application that captures an authorized source page, sends context to an AI model, and runs generated React code in an isolated sandbox. It is an example application from the Firecrawl team rather than the open-source edition of Lovable.dev.
Q: Is Open Lovable free to run?
The Open Lovable source code is available under the MIT license, but a working generation flow uses external capture, AI, and sandbox services with their own usage-based or subscription billing. Operating the host application also consumes your own compute and engineering time.
Q: Can Open Lovable run locally without API keys?
The host interface can start locally without provider keys, as our HTTP 200 check confirmed, but page capture, AI generation, and sandbox preview require the corresponding credentials. A loaded homepage is not proof that the end-to-end workflow is configured.
Q: Why does Open Lovable mention both Next.js and Vite?
The current Open Lovable host uses Next.js 15 and React 19, while its Vercel sandbox route scaffolds the generated preview as a Vite application using React 18. Troubleshoot the host and generated project as separate dependency graphs.
Q: Can Nstproxy Crawl replace Firecrawl in Open Lovable?
Nstproxy Crawl can replace the capture layer only through a custom adapter. The current Open Lovable source calls Firecrawl-specific routes and response shapes, so setting an Nstproxy token under FIRECRAWL_API_KEY will not work.
Q: Is it legal to clone any public website with Open Lovable?
No. Public accessibility does not grant permission to copy a site's protected code, design assets, text, trademarks, or personal data. Limit use to websites you own, licensed templates, permitted internal testing, or other cases reviewed under the applicable law and terms.
Lena Zhou
Aug. 7th 2026
110M+ real IPs with 99.9% access success
Blazing-fast average response ~0.5s for high-concurrency tasks
From only $0.1/GB
Get immediate access to premium residential, datacenter, IPv6 and ISP proxy pools.
