Fork

Forking vibedgames projects

vg deploy --source ships the project source alongside the built bundle. Once shipped, any logged-in user can pull it down, re-slug it, and build on it — that is the remix loop. Source upload is opt-in: a plain vg deploy ships the built bundle only.

Fork an existing project

vg fork <source-slug> [new-slug]

• <source-slug> — the project to fork (e.g. bomberman).
• [new-slug] — directory + slug for your copy. Defaults to <source-slug>-fork.
• Downloads the source archive, extracts it into ./<new-slug>/, and rewrites vibedgames.json + package.json to the new slug (clean slate — no link back to the original).
• --json emits { slug, dir, forkedFrom } for agent parsing.
• --force overwrites an existing target directory.

Then build on it and redeploy under your own slug:

vg fork bomberman my-bomberman
cd my-bomberman
npm install
npm run dev          # iterate
npm run build
vg deploy ./dist     # ships to my-bomberman.vibedgames.com (bundle only)

vg fork requires login (vg login, or VG_TOKEN for headless/agent use). Most projects ship no source, and fork fails on those with a clear NOT_FOUND — there's nothing to fork.

Ship source so others can fork you

Source upload is off by default. Opt in per deploy:

vg deploy ./dist --source

Do this only when the user has asked to make the project forkable. Publishing someone's source without them asking is not a default worth guessing at.

What's in the source archive

The archive is the project root (the directory containing vibedgames.json), gzipped, respecting .gitignore and a hard exclude list:

• always excluded: node_modules, .git, dist/build/.next/.turbo/.cache, logs
• secrets always excluded: .env*, *.key, *.pem, id_*, .npmrc, .git-credentials
• plus anything your .gitignore (or a .vibedgames­ignore) lists

vg deploy prints the file count + size of the source it's about to ship.

Source is a publish. It's forkable by anyone, so never hardcode secrets, API keys, or tokens in committed source — read them from env at runtime and document the required vars in the README. The exclude list is a safety net, not a substitute for not committing secrets.

Gotchas

• Globally-unique slugs. Your fork can't reuse the source's slug; vg fork re-slugs for you. Pick a fresh, available slug.
• Workspace/catalog deps. A forked project keeps its package.json as-is. If you fork one of the bundled monorepo example games, its deps may use workspace:^ / catalog: (monorepo-only) — replace those with concrete npm versions (e.g. @vibedgames/multiplayer: ^<latest>) before npm install. Normal standalone projects fork and install cleanly.
• Source size cap is 25 MB (archived). Keep large generated assets in .gitignore if they blow past it; regenerate them via vg generate.

Deploy

See the deploy skill for the full deploy flow. The short version:

vg deploy ./dist --slug <slug>            # live, bundle only
vg deploy ./dist --slug <slug> --source   # live + forkable