Skip to main content
vibld
Sign up for the beta
Menu

← All guides

Running vibld yourself

What self-hosting involves

Checked against the product on

vibld’s source is public at github.com/vibld/vibld.

Checked by the project, not yet by anyone else. A workflow deploys a separately named copy from these docs, confirms it comes up and refuses a signed-out caller, then signs in with the owner’s password and builds one site on it with a real model. It does the same under Docker. Nobody outside the project has deployed their own yet. Expect to be among the first, and to find gaps.

For a real build with your own model key, you need none of this. pnpm generate in a clone runs the same bounded build with one provider key and no Cloudflare, Clerk or database; the repository’s Quick start has the command. pnpm --filter @vibld/web dev runs the builder’s interface locally, but against a deterministic fake provider: no model is called.

The terms that govern using and modifying that source are on the Open-Source Notices page.

Three Workers, not one

vibld 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 in a container, for live previews and for the build behind a publish. It is separate because it executes code a model wrote, and that does not belong in the same Worker as your provider keys. It also signs share links, with a secret of its own.
  • The publish Worker stores and 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: projects, generations, billing mirrors, GitHub bindings, invites, 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, which enforces the ceilings. A deployment without it cannot generate at all.
  • A Workflow for generation, so a run survives the request that started it.

D1 and R2 have to be created and named, and all three Workers bind the same database and bucket. The Durable Object and the Workflow do not: they come into existence on first use.

Accounts you need

  • Cloudflare, on Workers Paid for previews and publishing. Both run generated code in Containers, which the Workers free plan does not include, and the container image is built at deploy time, so the machine you deploy from needs Docker. Without Containers, the Preview pane bundles the project in the viewer’s browser instead, with packages from esm.sh. Whether the builder alone runs on the free plan has not been tried: that plan allows 10 ms of CPU per request and per Workflow step, and the builder’s configuration asks for five minutes, which is a Paid setting.
  • Two domains on that account. One for the builder, and a second registrable domain for previews, share links and published sites, each on its own subdomain under a wildcard route. Generated code never shares cookie scope with the builder that way.
  • A model provider: Anthropic, DeepSeek or OpenAI. One key is enough. Without any, generation refuses rather than degrading.
  • A way to sign in, one of three. There is no “no auth” mode, on purpose: the endpoints spend money.
    • An owner password: one person, nothing to sign up for. Set VIBLD_AUTH to owner and the VIBLD_OWNER_PASSWORD secret to 12 characters or more. The owner is the admin.
    • Cloudflare Access in front of the builder, for a few people, on the same Cloudflare account (Zero Trust is free for up to 50 users). Set VIBLD_AUTH to access, VIBLD_ACCESS_TEAM_DOMAIN and VIBLD_ACCESS_AUD, and put your own Access email in VIBLD_PLATFORM_ADMINS. Admins find people by the invite they took.
    • Clerk, for sign-ups from the public, as app.vibld.com uses. Its session token has to carry the user’s email and a boolean email_verified claim, which Clerk does not add by default. Without them nobody’s email counts as verified, so no admin and no invite matches anybody.

The door starts closed

A new deployment is closed. Unless VIBLD_ACCESS_MODE is exactly open, the only accounts that can generate are the verified emails in VIBLD_PLATFORM_ADMINS and the addresses those admins invite. Everyone else, you included if you left yourself off the list, is refused and told to ask for access. Put your own address in VIBLD_PLATFORM_ADMINS before you try anything.

Admins get an admin panel in the builder: invites, credit grants, bans, account deletions, publish takedowns and an audit log. Invites need only the admin list and the database. Looking an account up by email, banning, and deleting the sign-in account also need CLERK_SECRET_KEY, on a copy that uses Clerk. On an owner copy the owner is the only account and already an admin.

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, every month, with no trial and no card asked for.
  • A GitHub App of your own, unless you want each project in a GitHub repository. It takes five values and works on Cloudflare, under Docker and on Render alike: Pushing to GitHub has the steps. Without it, those endpoints answer “not configured”.
  • Resend, only for the nightly email that warns when the DeepSeek balance runs low. The builder uses it for nothing else.

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

Next