--- title: Source and Versions | Vibecodr Docs description: Understand capsule lineage, editable source, immutable release history, live Drop updates, and how to track changes across drafts and published releases. canonical: https://vibecodr.space/docs/source --- # Source and Versions This section explains how editable source, immutable release cuts, live Drop updates, and publish state work together so teams can evolve an app without fragmenting discoverability. Marker: Canonical guidance for source lineage, cuts, and publish history. ## Implementation focus Use this model whenever you need rollback confidence, reproducible outputs, or clear version ownership. ## Expected outcomes - Track source and publish changes without losing canonical app continuity. - Understand cut behavior for rollback, pinned embeds, and live Drop movement. - Preserve reproducibility when shipping frequent updates. ## GitHub source (optional) Vibecodr works fully without GitHub. If you do connect GitHub, Vibecodr uses a GitHub App so private repos work safely. ### No token exposure GitHub tokens are never injected into your code or shared with viewers. ### No auto-publish GitHub source stays draft-scoped. You choose when to pull updates into Studio, and sync never publishes or creates feed posts for you. ## Connect & link a repo 1. In Studio (right sidebar) or Settings > Source, open Source (GitHub) and click Connect GitHub. 2. Install the Vibecodr GitHub App and return to Vibecodr. 3. Choose an installation, select a repository, pick a branch, and (optional) set a root directory for monorepos. Org installations are supported. You need permission to install apps for that organization, usually as an owner or app manager. If you installed the GitHub App directly on GitHub, go to Pulses → Integrations and click Sync to claim the installation in Vibecodr. ## Syncing to your workspace Sync pulls your repo into your Studio draft. It only updates the workspace - it does not change what viewers see until you publish. ### Sync now Click Sync now whenever you want the linked repo pulled into your workspace. ### No background automation Vibecodr does not auto-watch pushes for linked repos. Refresh stays explicit so your draft only changes when you ask it to. ## Cuts (version history) Every publish creates a new immutable drop (cut). Your post's live embed follows the current drop, while older drops remain available for exact references when they are retained and allowed by policy. For an existing live app, that publish flow is called BUMP IT. It creates a new cut on the same app post instead of creating a duplicate listing. ### Revert is append-only Reverting doesn’t replace history. It creates a new cut that matches an older one, then sets it live (git-revert semantics). ### Where to manage versions - Settings > Versions: manage cuts across all your vibes in one place (and jump into Studio for any vibe). - Player > Versions tab (author-only): copy pinned embed codes and revert from the vibe page. - Player > Manage > Open in Studio (author-only): edit the draft for an existing vibe, then publish an update (creates a new cut, no new post). ## Embeds: live vs pinned Vibecodr has two embed modes: - Live embed: follows the latest published drop for a post. - Pinned embed: points to a specific immutable artifact (cut). Pinned embed example ```html ``` ## Structured route body ### Source, releases, and lineage Editable source lives in the capsule. Published releases become immutable artifacts. The public post and live Drop connect those releases to the social and discovery surface. This separation lets a creator keep iterating without erasing what viewers already opened, embedded, remixed, or referenced. - Capsules hold editable project source. - Artifacts hold runnable release output. - Drops select which artifact is live for the canonical app. - Remixes and version history depend on preserving lineage instead of overwriting history. ### Reproducibility expectations A published artifact should be reproducible enough for the platform to serve it consistently and for users to understand what changed between cuts. Build output, dependency resolution, and runtime entry selection are part of that contract. Do not treat generated runtime output as the same thing as editable authored source. They are related, but they serve different trust and delivery roles. - Keep source edits in the source plane. - Keep runtime bundles and manifests in the artifact plane. - Use release history when explaining why a public app changed. ### Example and read next Example: a teammate asks why the live app changed while an old tutorial embed still behaves the same. Explain that the Drop points at the current artifact while exact-cut references keep their recorded release output. Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system. - Read next: [BUMP IT](/docs/bump-it) - Read next: [Vibe Runtime](/docs/vibe-runtime) - Read next: [Studio](/docs/studio) - Read next: [Runtime Presentation](/docs/runtime-presentation) - Read next: [Embeds](/docs/embeds) ## Related documentation - [/docs/bump-it](https://vibecodr.space/docs/bump-it/index.md) - [/docs/vibe-runtime](https://vibecodr.space/docs/vibe-runtime/index.md) - [/docs/studio](https://vibecodr.space/docs/studio/index.md) - [/docs/runtime-presentation](https://vibecodr.space/docs/runtime-presentation/index.md) - [/docs/embeds](https://vibecodr.space/docs/embeds/index.md)