Build a Lovable Clone

Prerequisites

• Node.js 20+ installed locally
• An Anthropic API key (for Claude)
• An OpenComputer API key

Step 1: Sign Up for OpenComputer

Step 2: Generate an API Token

Step 3: (Optional) Add a Custom Domain

1. In the OpenComputer dashboard, add your domain (e.g. mycompany.com).
2. Create a TXT record on your domain to verify ownership — the dashboard will show you the exact record to add.
3. Create a CNAME record for *.mycompany.com pointing to the value provided by OpenComputer. This routes all subdomain traffic to your sandboxes.

Step 4: Set Up the Project

123git clone https://github.com/diggerhq/osslovable.git
cd osslovable
npm run install:all

123ANTHROPIC_API_KEY=sk-ant-...
OPENCOMPUTER_API_KEY=your-opencomputer-token
DEPLOY_DOMAIN=mycompany.com  # optional — defaults to openlovable.cc

1npm run dev

How It Works

Generation Flow

1. User submits a prompt — The frontend sends the prompt to POST /api/generate.
2. Sandbox is created — The server calls Sandbox.create() from the OpenComputer SDK to spin up an isolated Node.js environment.
3. Claude generates code — The prompt is sent to Claude with a system prompt that instructs it to output complete file contents in a structured XML format (<file path="...">...</file>).
4. Files are streamed and written — As Claude streams its response, the server parses file blocks in real-time. Each file is written into the sandbox's filesystem using sandbox.files.write().
5. Dev server starts — Once all files are written, the server runs npm install and starts a Vite dev server inside the sandbox.
6. Preview URL is returned — The server calls sandbox.createPreviewURL({ port: 80 }) to get a public URL, which is sent to the frontend and displayed in an iframe.

Sandbox as Tool Calls

12345678910111213import { Sandbox } from "@opencomputer/sdk";

// Create an isolated environment
const sandbox = await Sandbox.create({ template: "node", timeout: 600 });

// Write files
await sandbox.files.write("/workspace/src/App.tsx", code);

// Run commands
await sandbox.exec.run("cd /workspace && npm install");

// Get a public URL
const preview = await sandbox.createPreviewURL({ port: 80 });

Limitations of This Approach

• No iterative editing — Claude generates the entire project in one shot. There's no back-and-forth where the LLM can see errors, fix them, and retry. A more robust version would use Claude's tool-use capability to let it write files, run commands, see output, and iterate.
• No persistent state — The development sandbox is ephemeral. If the server restarts, in-memory sandbox references are lost. There's no git history or checkpoint system to restore previous states.
• Single-turn only — Each prompt creates a fresh generation. Follow-up prompts create a new sandbox rather than iterating on the existing code.

Deployment Model

How Deployment Works

1. A new sandbox is created — Deployment does not reuse the development sandbox. A fresh sandbox is spun up specifically for the deployed version.
2. Files are copied over — All source files (excluding node_modules) are copied from the dev sandbox to the deploy sandbox using the SDK's file APIs.
3. Dependencies are installed and the server starts — The deploy sandbox runs npm install and starts the Vite dev server, just like the dev sandbox.
4. A fixed deploy URL is created — The server calls sandbox.createPreviewURL() with a custom domain configuration, producing a stable URL (e.g. https://<id>.openlovable.cc) that can be shared with others.

123456const domain = process.env.DEPLOY_DOMAIN || "openlovable.cc";
const url = await sandbox.createPreviewURL({
  port: 80,
  domain,
  authConfig: {},
});

Why a Separate Sandbox?

• The developer can keep iterating in the dev sandbox without affecting the deployed version.
• The deployed version has a fixed, shareable URL that doesn't change.
• Each deployment is a clean, reproducible build.

Hibernation and Wake-Up

• Deploy URLs are persistent — they continue to work even after the sandbox hibernates.
• Cold starts are fast — sandboxes resume from hibernation in seconds.
• No always-on cost — you're not paying for idle compute.

Limitations and What's Coming

Current Limitations

• No version control — There is no git server backing the sandbox, so there's no way to checkpoint, diff, or roll back changes. If you want to restore a previous version, you'd need to regenerate it.
• No secret management — API keys and environment variables are passed in plain text. There's no built-in mechanism for securely sealing secrets that the sandbox needs at runtime.
• Ephemeral dev state — The development sandbox lives only as long as the server process. A server restart or crash loses all active sandbox references.
• Single-turn generation — The current architecture doesn't support multi-turn conversations where Claude can iterate on its output based on build errors or user feedback.
• No private link sharing — Deploy URLs are either fully public or not accessible at all. There's no way to share a preview link with specific team members or collaborators behind authentication.

What's Changed Since This Guide Was Written

• In-sandbox agent loop — Agent sessions now run the Claude Agent SDK inside the sandbox. The agent reads files, runs commands, and iterates on errors locally without leaving the VM. This is the recommended approach for new projects.
• Preview URL authentication — authConfig on preview URLs supports restricting access. Not full private link sharing yet, but a step toward it.
• Checkpoints — Checkpoint and fork workflows are available for snapshotting sandbox state, restoring, and branching.
• Custom templates — Define custom environments with the Image builder and pre-built snapshots.

Still Planned

• Built-in git server — Git-based version control for sandbox state
• Secret sealing — Encrypted secrets decrypted only inside the sandbox at runtime