Skip to main content
vibld
DocsSign in

← All guides

Running vibld yourself

What self-hosting involves

Checked against the product on

vibld’s source is public at github.com/vibld/vibld. This page is what you are taking on before you start: the moving parts, the state behind them, and the accounts you will need.

The terms that govern using and modifying that source are on the Open-Source Notices page. Read them there rather than trusting a paraphrase on this one.

Three Workers, not one

vibld is not a single deployable. It is three Cloudflare Workers with deliberately different blast radii:

  • The builder serves the interface and the API. It talks to the model, holds the spend ledger and owns the database.
  • The sandbox Worker installs dependencies and runs generated code. It is separate because it executes code a model wrote, and that does not belong in the same Worker as your provider keys.
  • The publish Worker serves published builds. Separate again, and with its own shared secret rather than the sandbox’s, so that leaking one does not compromise the other.

What holds the state

  • D1 for control-plane metadata: generations, billing mirrors, GitHub bindings, referrals. The schema is a set of numbered migrations in the repository.
  • R2 for the file content those rows point at.
  • A Durable Object for the per-user spend ledger. It is what makes a ceiling a ceiling rather than a suggestion, so a deployment without it cannot enforce spend at all.
  • A Workflow for generation, so a run survives the request that started it.

D1 and R2 have to be created and named. The Durable Object and the Workflow do not: they come into existence on first use.

Accounts you need

  • Cloudflare. The Workers free plan is enough to stand it up. The Durable Object is configured for SQLite storage specifically because that is the only backend available there.
  • A model provider: Anthropic or DeepSeek. One key. Without it, generation refuses rather than degrading.
  • Clerk, for sign-in. Without it every protected endpoint refuses. There is no “no auth” mode, on purpose: the endpoints spend money.

Accounts you probably do not need

  • Stripe, unless you intend to charge somebody. Without it, billing endpoints report themselves unconfigured and everyone is on the Free tier’s allowance, which you can set to whatever you like.
  • A GitHub App, unless you want the push-to-repository feature. Without it, those endpoints answer “not configured”.

Every optional piece fails the same way: unset means the feature reports itself unavailable, never that it quietly runs without a check.

Next