Running vibld yourself
What differs from the hosted service
Checked against the product on
The difference is mostly operations rather than features. There is no reduced build of the builder: the source that runs app.vibld.com is the source in the repository.
The project checks that a copy deploys from the docs, that its owner can sign in, and that it builds one site with a real model, on Cloudflare and under Docker. Nobody outside the project has deployed their own copy yet.
The same either way
- Generation, iteration, standing instructions and style direction.
- Running a project in a sandbox, sharing it, and revoking the share.
- Exporting the project, and pushing it to a repository as a branch and a pull request.
- Saving your work, connecting Git, and exporting. None of these is behind a paid plan, by policy.
Things only your own copy has
- Your own model keys. The hosted service holds no user’s provider key; it sells model spend instead. Bringing your own key is for a self-hosted copy or the command line.
Running it on your own machine
pnpm --filter @vibld/web dev runs the builder’s interface locally with no sign-in and a deterministic fake provider, so you can go through the whole flow at no cost, but no model is called. Its real model path needs sign-in, D1, R2 and a Workflow, which a Cloudflare deployment has and so does Docker.
docker compose up runs the whole builder on one machine with no Cloudflare account: sign in with an owner password, build with your own key or a local model, and preview each project in a container on your Docker. The repository’s Docker section has the steps.
Without the builder, the command line builds too: pnpm generate "your prompt" --out ./site --build with one provider key set. It runs the same bounded build as the hosted builder, writes the project, and with --build installs and builds it with npm, asking the model for one repair if that fails. A weekly workflow proves it from a clean clone. The repository’s Quick start has the details.
What you take on by running your own
- The provider bill. You pay the model provider directly, at their rates, with no plan in between. For one person this is usually cheaper. It is also uncapped unless you set the ceilings yourself.
- Setting those ceilings. The deployment-wide daily ceiling ships with a default that is a starting point, not a measured figure. Nobody else is going to notice a runaway loop on your account.
- Migrations. Every schema change has to be applied before the Worker that expects it is deployed. Getting this backwards takes the deployment down.
- Secret rotation, for the provider key, the Clerk keys, the two internal shared secrets and the share-link secret.
- Who gets in. A copy starts closed to everyone but the admins you list, until you invite people or open it.
- Sandbox capacity. Queueing, expiry and cleanup are yours to watch.
What the hosted service is actually selling
Not the code. It is the operating: a provider key that is topped up, a sandbox fleet somebody is watching, migrations applied in the right order, a spend ceiling tuned against real usage rather than a guess, and somebody to ask when it breaks.
Things only the hosted service has
- Billing and plans. Stripe integration exists in the source, but a self-hosted copy with no Stripe configuration simply has no billing: everyone gets whatever Free-tier allowance you set every month, with no trial and no card asked for.
- Publishing to a vibld URL. Self-hosted, the same button publishes to your own domain.
- Referral credit. It pays out of the hosted service’s own ledger, so it is meaningless without one.
What the terms say
The license covering the core, the templates and what you generate is set out on the Open-Source Notices page. This page describes how the two deployments differ, not what you are permitted to do.