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

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

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

npm 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

import { 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.commands.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.

const 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.

​

Coming Soon to OpenComputer

• Built-in git server — Each sandbox will have a native git server, enabling checkpoint/restore workflows and git-based deployments. You’ll be able to commit the sandbox state at any point, roll back to a previous commit, and deploy from a specific git ref.
• Secret sealing — A secure mechanism for injecting secrets into sandboxes without exposing them in plain text. Sealed secrets will be encrypted at rest and only decrypted inside the sandbox at runtime, making it safe to pass API keys, database credentials, and other sensitive configuration.
• In-sandbox agent loop — Instead of orchestrating the LLM from an external server (where every file write and command execution is a round-trip over the network), the agent loop will run inside the sandbox itself. This dramatically reduces latency — the agent can read files, run commands, and iterate on errors locally without leaving the sandbox. It’s also a simpler deployment model: you ship a single sandbox image with the agent baked in, rather than coordinating between an external server and a remote sandbox.
• Private link sharing — The ability to share deploy preview URLs with specific people. You’ll be able to grant access to individual team members or collaborators, so preview links aren’t fully public but still don’t require the recipient to have an OpenComputer account.