open-lovable needs the required credentials before it will rebuild your site

The pipeline is scrape, generate, then execute somewhere

The repository description is blunt about the aim: clone and recreate any website as a modern React app. The README frames it as an example app made by the Firecrawl team, with the full hosted product pointed at separately, which sets the expectation that this repository is a working demonstration rather than the maintained service.

Three dependencies in package.json map directly onto the three stages. @mendable/firecrawl-js at 4.3.3 is the scraping client that turns a URL into markup the model can read. The @ai-sdk packages for anthropic, google, groq and openai, alongside @anthropic-ai/sdk, are the generation step, with four providers available rather than one. @e2b/code-interpreter is the execution environment.

So the mechanism is not a magic clone. A URL is scraped, the result is fed to a model that writes React components, and the components are rendered to check them. Each stage depends on external services, which is the main practical constraint and the reason to read the environment file before cloning.

The UI layer is conventional Next.js on Radix UI, with Tailwind for styling, and the app directory plus components/ at the root show a standard App Router layout.

Four keys, and the sandbox credential is the one people miss

The environment file is the real documentation for this project, and it is organised in tiers.

FIRECRAWL_API_KEY is the only key marked required in the README. The AI provider section lists GEMINI_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY and GROQ_API_KEY as choices rather than requirements, and the .env.example file adds AI_GATEWAY_API_KEY with a note that it provides access to multiple models and that the individual keys are used when it is not set. That is a discrepancy between the README and the shipped example worth knowing: the example file advertises a gateway option the setup section does not mention.

The sandbox section is where a first run usually fails. SANDBOX_PROVIDER is set to vercel by default and the alternative is e2b. Each has its own credential set, and for Vercel there are two authentication methods: an OIDC token obtained by running vercel link then vercel env pull, which the README recommends for development, or a personal access token with a team ID and project ID, which it suggests for production or when OIDC is unavailable.

One more key is optional and easy to misread. MORPH_API_KEY appears under a fast apply heading marked optional for faster edits, so leaving it unset slows the edit loop rather than breaking it.

Clone, install, add .env.local, run the dev server

The setup is four steps and the third is the one people look past.

git clone https://github.com/firecrawl/open-lovable.git
cd open-lovable
pnpm install  # or npm install / yarn install

Note that the repository carries bun.lock, pnpm-lock.yaml and package-lock.yaml at once, so any of the three package managers resolves, and the README says so in the same line. That is unusual and suggests the lockfiles are committed per tool rather than one being authoritative.

The second step is to create .env.local rather than editing the shipped .env.example, and the third is to start the dev server. The dev script runs next dev with the turbopack flag, so builds are fast but you are on the Turbopack path rather than webpack:

pnpm dev  # or npm run dev / yarn dev

Then open http://localhost:3000. There is no separate backend to start, because the Next.js server routes handle the API calls, which is what lets the three scripts test:api and test:code run with plain node rather than against a running service.

A flat root that mixes app code, design tokens and a packages directory

The repository root is broader than a typical Next.js app, and the extra directories describe what the project is.

app/ is the App Router. components/ holds UI, config/ holds configuration, hooks/ and lib/ hold behaviour, and utils/ and types/ are the usual. Two entries are less standard: atoms/ suggests a state or component primitive layer, and colors.json at the root is a design token file that the generated output is presumably matched against, since recreating a site involves reproducing its palette as well as its layout.

There is a packages/ directory with no explanation in the README, and styles/ alongside a tailwind.config.ts and a postcss.config.mjs, which together suggest the styling is not purely Tailwind utility classes. A .cursor/ directory sits at the root for editor configuration.

Configuration at the framework level is minimal: next.config.ts, tsconfig.json and eslint.config.mjs. Nothing in the README describes server actions, API route paths or the scrape pipeline in detail, so the code is the reference here rather than the prose.

Test scripts exist, but two of the three names are not in package.json

The scripts block in package.json is short and slightly inconsistent, which tells you something about how the repository evolved.

dev, build, start and lint are the four you would expect for a Next.js app. Then there are three test scripts. test:api runs node against tests/api-endpoints.test.js and test:code runs node against tests/code-execution.test.js, both as plain node scripts rather than through a test framework. test:all chains an integration step before those two, invoking npm run test:integration, which does not exist in the scripts block.

So test:all fails on a fresh checkout, and no test/ directory appears in the root listing alongside the other directories. The practical consequence is that you should treat the tests as an aspiration of this 0.1.0 example rather than as a verification gate you can rely on, and run the app manually instead.

The version in package.json is 0.1.0, the package is marked private, and the repository has no GitHub releases. The last push was on 2026-10-09, so the source is current while the release story is absent. Licence is MIT with the file at the root.

Editorial conclusion

open-lovable is a useful reference for anyone building a scrape and regenerate product, and it is an example app rather than a product: the README points at Lovable.dev as the complete cloud solution, and the repository version is 0.1.0 with no GitHub releases. Before you run it, set SANDBOX_PROVIDER and supply the matching credential, since without a working sandbox the generated code has nowhere to run.

Frequently asked questions

Official sources

1. firecrawl/open-lovable on GitHub
2. Issues
3. License: MIT
4. README