Self-Hosted AI App Builder: Run Your Own (2026)

A self-hosted AI app builder is a prompt-to-app tool you run on your own infrastructure instead of renting a closed SaaS like Lovable or v0. In 2026, the quickest way to get one is the open-source ai-app-builder-open repository: clone it, add a single API key, and run npm run dev. You get a full Next.js 16 builder with live preview, a managed database, auth, one-click hosting, and custom domains behind one environment variable, and the code is yours to read, edit, rebrand, and deploy anywhere.

This tutorial takes you from an empty folder to a running builder in about fifteen minutes, then explains exactly how the one-key architecture works so you can decide whether to build a product on top of it.

The repo we use is ai-app-builder-open on GitHub. It is MIT licensed and roughly 98% TypeScript. It is also young, one maintainer and a handful of stars as of July 2026, so treat it as a reference implementation you fork and own, not a managed service with an SLA. More on that trade-off below.

In plain English: what a self-hosted AI app builder is (and who it is for)

Skip this section if you already ship software for a living. If you do not, here is the whole idea in three sentences.

Tools like Lovable, v0, Bolt, and Replit let you type a sentence ("a CRM with a Kanban board and email login") and watch an AI write a working web app. That is a prompt-to-app builder. The catch is that you are a tenant: the builder, the code, the hosting, and the branding belong to the vendor, and you cannot move the builder itself into your own product.

Self-hosting flips that. You run the builder on a server you control, under your own brand, with the source code in your own Git repository. A self-hosted AI app builder is therefore useful to three kinds of people:

• Founders who want to launch their own "build an app with AI" product without writing the hard backend from scratch.
• Agencies that want a rebranded builder inside their client dashboard (this is the white-label case).
• Developers who simply want to own the tool they build with, instead of being locked into a vendor's UI.

If none of those is you, a hosted builder is genuinely the faster choice, and this tutorial will say so again at the end. If one of them is you, read on.

Why build your own instead of using Lovable, v0, or Bolt?

Let us be honest about the incumbents first, because a self-host decision that ignores their strengths is a bad decision.

• Lovable has the largest mindshare of the group and a clean Supabase integration. If you want a hosted Postgres database wired up for you with zero thought, it is hard to beat.
• Bolt.new (from StackBlitz) has arguably the cleanest in-browser build experience of any 2026 builder.
• v0 (from Vercel) is the natural pick if your team already lives inside the Vercel and Next.js ecosystem.
• Replit gives you a full IDE and agent in one place, which developers who want to poke at the code appreciate.

All four are closed and hosted. None of them can be self-hosted, rebranded, or embedded inside your own product. That is the entire reason the open-source path exists.

There are also genuine open-source competitors you should weigh, not just the repo in this tutorial:

• Dyad is a more mature, local-first open-source builder. It leans toward bring-your-own-model and running things on your own machine, so if your priority is zero external dependency, evaluate it seriously.
• Open Lovable (from the Firecrawl team) is an open-source app builder focused on generating React apps from a prompt.

So where does ai-app-builder-open fit? Its differentiator is not the AI, it is the managed infrastructure behind one key. Dyad asks you to bring your own model and often your own hosting. ai-app-builder-open ships a working builder whose generated apps come with hosting, a database, auth, file storage, GitHub sync, and custom domains already wired up, all reached through a single API. You trade some independence for a deployable product on day one. That is the honest shape of the choice.

What you will build

By the end you will have a running builder at http://localhost:3000 that can take a prompt, generate a full-stack Next.js app, preview it live, and deploy it. The same codebase can then be pushed to your own host and rebranded.

Prerequisites:

• Node.js 20 or newer and npm (the repo targets Next.js 16 and React 19).
• Git.
• A free Totalum account, which is where the single API key comes from. You do not need a credit card to create one.

Everything the builder generates is a real Next.js 16 / React 19 project, not a sandboxed SPA, which matters if you care about SEO for the apps you ship.

Clone and install

Open a terminal and run:

git clone https://github.com/totalumlabs/ai-app-builder-open.git
cd ai-app-builder-open
npm install

Expected output: npm installs the dependencies and exits without errors. If npm install fails on the Node version, check node -v and upgrade to 20 or newer.

Get your API key

The builder talks to one backend, the Totalum VCaaS (vibe-coding-as-a-service) API, and it needs one key to do so.

1. Create a free account at Totalum and choose the "Use the Totalum API" option during onboarding.
2. Copy the API key. It starts with the prefix tlm_sk_.

That single key is what unlocks hosting, the database, the AI agent, sandboxes, GitHub sync, and custom domains for every app the builder generates. If you want the official walkthrough and the API reference, Totalum publishes a guide to building your own AI app builder that documents the same repository from the platform side.

Heads up: keep this key server-side. As you will see in Step 3, the repo is deliberately built so the key never reaches the browser.

Set the environment variable (and the one gotcha nobody documents)

Create a file named .env or .env.local in the project root:

TOTALUM_VCAAS_API_KEY=tlm_sk_your_key_here

Here is a real gotcha that will save you a confused half hour. The README documents TOTALUM_VCAAS_API_KEY, but Totalum's own docs page refers to VCAAS_API_KEY. Both work. If you read the actual source in src/lib/vcaas.ts, the key is resolved like this:

return process.env.TOTALUM_VCAAS_API_KEY || process.env.VCAAS_API_KEY || "";

So TOTALUM_VCAAS_API_KEY is the primary name and VCAAS_API_KEY is an accepted fallback. Use the primary name to match the README, and do not set both to different values. Note that it is not a NEXT_PUBLIC_ variable on purpose: the key is read only on the server, so it is never bundled into client-side JavaScript.

Run it and send your first prompt

Start the dev server:

npm run dev

Open http://localhost:3000. You should see the builder dashboard. Create a project, type a plain-English prompt such as:

A task tracker with email login, a projects list, and a Kanban board for tasks.

Watch the live preview update as the agent works. You also get a Monaco (VS Code) code editor, a database panel you can browse and query, a secrets manager, live server logs, a Git-style diff viewer for every AI change, and version history with rollback. This is the point where a non-technical reader realizes the builder is not a toy: it is generating a real, inspectable codebase.

Expected output: a generated project with a working preview URL. If the preview never appears, open the logs panel; a missing or malformed key surfaces there first.

Deploy and (optionally) go multitenant

The project is deployment-agnostic. It runs anywhere Node.js runs. To build and start it in production:

npm run build
npm start

npm start serves on $PORT (default 3000). From there you can host it on Vercel, a Docker container, a plain VM, Railway, or Render. Because it is your codebase, white-labeling is just editing the UI: the README puts it plainly, "It's your codebase and your UI. Rebrand it, restyle it, and embed it inside your existing dashboard."

The multitenant story is the interesting part for anyone building a product. Every app the builder generates is an isolated project, so you can create one per user, per team, or per customer. That is the mechanism that turns "a builder I run" into "a builder I sell," and it is the same pattern you would reach for if you were going to embed a builder inside an existing SaaS.

How the one-key architecture works under the hood

If you have built agents before, you will want to know what is actually happening when you type a prompt. The design is small and worth understanding.

The browser never talks to the backend directly. Instead, the repo exposes a proxy route at /api/vcaas/[...path], and a single server-only module, src/lib/vcaas.ts, attaches your key and forwards the request. The base URL it calls is:

https://api-accounts.totalum.app/api/v1/vcaas

The key travels as an api-key request header, added on the server, so it is never exposed to the client. The endpoints map cleanly to the builder lifecycle: POST /projects to create, POST /projects/:id/agent/start and GET /projects/:id/agent/status to run and poll the AI agent, POST /projects/:id/deployments/deploy to ship, plus routes for the database, secrets, domains, GitHub sync, versions, and logs.

That is the whole trick: the open-source repo is the frontend and the orchestration, and the managed API is the backend that actually builds, hosts, and deploys. It is the same architecture you would design if you were assembling an agent product yourself, which is why it is a useful thing to read even if you never ship it. If you want the from-scratch version of that mental model, our walkthrough on building your first AI agent from scratch covers the loop without any platform.

Verify your install

Before you build anything real on it, confirm the plumbing end to end. From the project root:

# 1. The key is present and server-only (should print a value, and NOT start with NEXT_PUBLIC)
grep VCAAS_API_KEY .env .env.local 2>/dev/null

# 2. The dev server is up
curl -sS -o /dev/null -w '%{http_code}\n' http://localhost:3000

You want a 200 from the second command and a key on the first. Then, in the UI, generate one throwaway app and click deploy. If you get a live production URL back, every layer (frontend, proxy, key, agent, hosting) is working, and you own all of it.

Honest limitations before you build on it

A tutorial that only lists upsides is marketing. Here is what to weigh before you bet a product on this repo, in 2026:

• It depends entirely on one commercial API. This is an open-source frontend over a managed backend. If you stop paying for or lose access to the API, the builder stops building. A local-first tool like Dyad does not have that dependency, which is the honest reason to prefer it if independence is your top priority.
• The project is young. One maintainer and a small star count as of July 2026 means you are adopting a reference implementation, not a battle-tested framework. Read the code before you rely on it.
• The generated apps use the platform's own database layer, not raw PostgreSQL. Your frontend code is portable; migrating the data layer to a standalone Postgres later is real work. Builders like Lovable, Bolt, and v0 ship Postgres, so if SQL portability is non-negotiable, factor that in.
• Pricing on the backend is per project. If you run many small experiments or resell heavily, model the cost before you commit.

None of these is a dealbreaker for the three audiences at the top of this post. All of them are things you would rather know now than discover in month three.

The bottom line

If you want a throwaway prototype this afternoon, use a hosted builder; it is faster. If you want a prompt-to-app builder that is yours, one you can read, fork, rebrand, embed, and deploy on your own terms, the ai-app-builder-open repo gets you there in five steps and one API key. Clone it, star it if it saves you time, and go build the thing you actually wanted to own.