Self Hosted Lovable: How to Run Your Own AI App Builder in 5 Minutes

A self hosted Lovable setup is not something Lovable itself offers: the product is closed source and runs only on their servers. What you can self-host is an open source alternative that reproduces the same workflow. This walkthrough uses Creable, an MIT-licensed AI app builder, and takes you from git clone to a running builder on your own domain, then through the four changes that turn it from a personal tool into something you can charge for.

Quick Answer

• Lovable cannot be self-hosted. It is a closed-source hosted product, so a self hosted Lovable means self-hosting an open source equivalent instead.
• Creable is one such equivalent: clone the repository, set one environment variable, run npm run dev, and you have the builder on localhost in about five minutes.
• It needs Node 20 or newer and a single Totalum API key. There is no Supabase project, no Vercel account and no model provider key to configure.
• It deploys anywhere Next.js runs: Vercel, Docker, Railway, Render, Fly.io or a plain VM.
• It ships with no login on purpose, so there are two guard functions you must implement before exposing it to anyone but yourself.

What "self hosted" means here, precisely

It is worth being exact, because this is where most write-ups get vague.

When you self-host Creable, you host the builder. The home page, the chat, the live preview panel, the visual editor, the code editor, the database browser and the publish flow all run on your server, from source you can read and edit.

You do not host the engine. The AI coding agent, the sandboxes each generated app runs in, the hosting for published apps, the managed databases, the deploy pipeline, the custom-domain certificates and the GitHub sync are provided by the Totalum API behind your API key.

That split is the reason this takes five minutes rather than a weekend. It is also the honest limitation: this is self-hosting the product, not self-hosting the infrastructure. If you need everything on your own metal with your own model weights, this is the wrong tool and dyad is a better starting point. We covered that trade-off in more depth in our open source AI app builder roundup.

Step 1: Get it running locally

Requirements: Node.js 20 or newer. The repository pins a version in .nvmrc.

git clone https://github.com/totalumlabs/lovable-alternative.git
cd lovable-alternative
npm install
cp .env.example .env.local

Open .env.local and set the one required variable:

TOTALUM_VCAAS_API_KEY=tlm_sk_...

To get that key, create an account at totalum.app/api and choose Use the Totalum API during onboarding. The first 50 AI credits are free, which is enough for the first few apps. That one key covers the agent, hosting, databases, sandboxes, deploys, domains and GitHub sync for everything you build.

Then start it:

npm run dev

Visit http://localhost:3000, type what you want to build, and press Enter. Shift+Enter adds a line break. You will be asked to name the project, then the workspace opens: chat on the left, live preview on the right.

Where the key lives. It is read in exactly one file, src/lib/vcaas-server.ts, which is marked server-only. Browser code never sees it. The UI talks to same-origin routes under /api/vcaas/*, and the server adds the key before forwarding upstream. .env.local is gitignored, so the key does not end up in a commit.

Step 2: Understand the three files that matter

Before changing anything, it helps to know where the seams are. The repository is larger than this, but these three files explain most of its behaviour.

File	Role
src/lib/vcaas.ts	The typed API client, browser side. Every call the UI makes goes through here. Components never hardcode an /api/vcaas/... path.
src/lib/vcaas-server.ts	The server half that holds the key. The only module that reads the environment variable. Never imported from a client component.
src/app/api/vcaas/_shared.ts	The auth and ownership guards. They are deliberate no-ops today, because the app runs on one operator key. This is the file you change before real users log in.

The request path in one line: browser calls vcaas.ts, which fetches a same-origin route under /api/vcaas/*, which adds the api-key header via vcaas-server.ts and forwards to the Totalum API.

Two behaviours are worth knowing because they look like bugs otherwise. Agent runs and deploys are asynchronous: the UI polls status every 10 to 15 seconds and never assumes completion from the response that started the run. And the visual editor requires a same-origin preview, so while it is open the project is served through /api/preview/{projectId} rather than its direct URL.

Step 3: Put your own brand on it

Every user-facing mention of the product reads from one file, so this is genuinely a five-minute job rather than a search-and-replace hunt.

Edit src/lib/brand.ts:

export const BRAND = {
  name: "YourBuilder",
  tagline: "Build something you own",
  promptPlaceholder: "Ask YourBuilder to create a landing page for my…",
  metaTitle: "YourBuilder: AI App Builder",
  metaDescription: "Describe an app, watch it get built, publish it.",
  repoUrl: "https://github.com/yourorg/yourbuilder",
  docsUrl: "https://docs.yourbuilder.com",
  apiKeyUrl: "https://yourbuilder.com/signup",
  billingUrl: "https://yourbuilder.com/billing",
} as const;

Then three assets and one stylesheet:

• src/components/brand/Logo.tsx for the mark and the wordmark.
• src/app/icon.svg for the favicon.
• src/app/globals.css for the theme tokens: surfaces, ink ramp, accent color and the --radius value.

There is a rule in the codebase that makes this stick: no component contains a literal product name, and storage keys are namespaced from a STORAGE_PREFIX exported by the same file. So a rebrand does not leave stray mentions in dialogs, meta tags or localStorage keys.

One thing to change before you show it to a customer: InsufficientCreditsModal links to the operator's billing page. Point it at your own checkout, or remove it.

Step 4: Add authentication, because there is none

This is the step you cannot skip, and it is the reason the previous three were easy.

Creable has no login by design. Every route is public and the app acts on one API key, so anyone who can reach the URL can build apps and spend your credits. Locally or on a private network that is fine. On a public domain it is not.

There are two guards to implement, both in src/app/api/vcaas/_shared.ts:

1. resolveVcaasContext() should read the user from cookies and return 401 when there is no session.
2. enforceProjectScope(context, method, path) should return 403 when the path targets a project (path[0] === "projects" && path[1]) that does not belong to that user.

Then wire them in. Today only /api/preview/ and /api/visual-edit/ call the guards. The catch-all proxy route, upload, source-code and git-diff do not, so those need the same treatment.

Finally, protect the pages themselves in src/proxy.ts by redirecting / and /project/* to your login page when there is no session.

Any auth provider works. Supabase, Clerk and Better Auth are all one package plus a server client. The repository does not ship an opinion here on purpose, so you can use whatever your stack already uses.

Tie each project to a user

Multi-tenancy on the platform side is already done: every project is isolated. Your side is one table and one check.

Store a row when a project is created:

projects(project_id text primary key, user_id uuid, created_at timestamptz)

Insert the returned projectId after POST /projects or POST /projects/launch, check ownership on every proxied /projects// path, and intersect the home page listing with the caller's own rows so users only see their own work.

Step 5: Deploy it

Creable is a standard Next.js 16 application. There is nothing unusual in the build.

Vercel. Import the repository, add TOTALUM_VCAAS_API_KEY under Environment Variables, deploy.

Any Node host, including Docker, Railway, Render, Fly.io or a VM:

npm run build
npm start   # listens on $PORT, default 3000

If you are serving from a custom production domain, set NEXT_PUBLIC_APP_URL as well. It is optional, and it is used by src/proxy.ts to allow-list your origin for CSP and CORS.

Before the first public deploy, confirm three things: the guards from Step 4 are implemented and actually called, the pages in src/proxy.ts are protected, and the billing link in InsufficientCreditsModal points somewhere you control.

Step 6: Charge for it, if that is the goal

At this point you have a self hosted, branded, authenticated AI app builder. Turning it into a business is one more layer.

The mechanics are ordinary Stripe work:

1. Create a credit-pack product and set STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET and your price IDs.
2. POST /api/billing/checkout creates a Checkout Session with client_reference_id set to the user id.
3. POST /api/billing/webhook verifies the signature and increments the user's credit balance on checkout.session.completed and invoice.paid. Make it idempotent on the event id.
4. Gate the spend-shaped paths before forwarding: agent/start, projects/launch, deployments/deploy, rebuild, domain, files/ and versions//recover. Return 402 with an INSUFFICIENT_CREDITS code when the balance is empty, and the existing modal picks it up.

For pricing, the useful detail is that the agent status response reports the credits a run actually spent when it reports done. So you can meter per prompt against real cost rather than guessing, and set your margin deliberately. There is also a spending-analytics endpoint you can reconcile against per project.

If you would rather not run the builder UI at all and instead call the API from inside an existing product, the flow is small enough to port: a key-holding server proxy, POST /projects/launch, poll agent/status until done, show the URL from GET /projects/:id in an iframe, follow-ups via agent/start, then deployments/deploy. We walk through that path in how to embed an AI app builder in your SaaS via API.

What the generated apps actually are

Worth stating clearly, because it is the main reason to pick this stack over a local tool.

Each app the agent builds is a full-stack Next.js project with an integrated database, not a front-end mock and not a client-rendered single-page app. Server-rendered pages, API routes, per-page metadata, sitemaps, auth, file storage and secrets. Published apps get HTTPS and can take a custom domain.

That matters most when what you build has to be found. A client-rendered React bundle hands crawlers an empty HTML shell; a server-rendered Next.js page hands them the content. If your apps are directories, marketplaces, blogs or shops, the difference decides whether they can rank at all. Our comparison of Lovable alternatives goes through how the major builders differ on this point.

Troubleshooting

The app says the API key is not set. There is a /api/config route that reports whether the key was found. Check that the file is named .env.local, that the variable is TOTALUM_VCAAS_API_KEY, and that you restarted the dev server after editing it.

A preview shows a waiting strip instead of the app. Sandboxes are archived when idle. Touching the project wakes it, and the wake takes a moment. A refused action claims the wake rather than failing, so the prompt you typed goes back in the box rather than disappearing.

The visual editor refuses to open. It is desktop only and it requires the live development server to be ready. Wait for the preview to load first.

Typecheck or build fails after an edit. npm run typecheck runs tsc --noEmit and is the fast correctness gate. CI runs it on every push. There is no test suite, so typecheck plus build plus opening the changed screen is the verification loop.

FAQ

Can Lovable be self-hosted?

No. Lovable is a closed-source hosted product with no self-hosted or on-premise edition. Self-hosting means running an open source alternative that reproduces the workflow, such as Creable, dyad or bolt.diy.

How long does this actually take?

Getting the builder running locally is four commands and about five minutes, assuming Node 20 is installed and you already have an API key. Rebranding is roughly another five. Authentication, tenancy and billing are real engineering work and should be measured in days, not minutes.

What does it cost to run?

The builder code is free and MIT licensed. Usage is billed through the Totalum API key, starting with 50 free credits, and there are no per-seat fees for the builder itself. If you resell it, you meter per prompt from the credits each run reports and set your own price above that.

Do I need Docker?

No. It is a plain Next.js application, so npm run build && npm start on any Node 20 host is enough. Docker works if you prefer it, and so does Vercel, Railway, Render or Fly.io.

Is it safe to expose on the internet?

Not until you complete Step 4. With no login, every route is public and every action spends your API key's credits. Implement the two guards, wire them into all the API routes, and protect the pages in src/proxy.ts first.

Can I use my own AI models?

No. Prompts are routed by the Totalum API to the best available coding model, though you can pick the model, effort level and fast mode per prompt from the composer's run options. If bringing your own keys is a hard requirement, dyad or bolt.diy are the better fit.

Next steps

If you want to see the output before committing to a self-hosted setup, the quickest test is to start free at totalum.app, describe an app, and look at what comes out. The first 50 credits are free and you can export the code to GitHub at any point.

To self-host, the repository is at github.com/totalumlabs/lovable-alternative. The full product-building checklist, including the reseller path, is on the open source Lovable alternative page.

If you are doing this for an agency or to add a builder to a SaaS you already sell, book a 30 minute call and we will go through the white-label terms and what the integration looks like in your stack.

Creable is an independent open source project. It is not affiliated with, endorsed by or connected to Lovable Labs Incorporated. "Lovable" is a trademark of its owner, used here only to describe what this project is an alternative to.