--- title: Vibecodr Docs Overview | Vibecodr description: Start with the core model for capsules, artifacts, Drops, publishing, remixing, and backend boundaries before you go deeper. canonical: https://player.vxbe.space/docs --- # Vibecodr Documentation Use this as the front door for editable source in capsules, published releases, live Drops, VXBE runtime delivery, Pulses, embeds, and trust boundaries. Every section below is optimized for first implementation, not abstract theory. Marker: Platform documentation hub for runnable software workflows. ## Implementation focus Start with authoring and runtime sections, then move into backend handlers and safety controls once your capsule is publishing immutable artifacts on public routes. ## Expected outcomes - Choose the right creation path: Composer for quick cuts, Studio for multi-file production work. - Understand when a feature belongs in a vibe versus in a Pulse. - Carry a stable mental model of publication, cuts, and embed delivery. ## Welcome to Vibecodr Vibecodr is where code ships as something you can run. Create interactive web experiences (called Vibes), publish with a link, and remix what others share without managing servers or infrastructure. ### Create Make games, tools, demos, and experiments without starting from an empty deployment stack. ### Share Publish to a stable public link so other people can visit what you made immediately. ### Remix Fork public work, keep the original intact, and turn someone else’s starting point into your own. ### Power Up Add server-side behavior with Pulses when the project needs secrets, storage, or live endpoints. ## Vibes, Pulses, and Combos Vibecodr looks at your files and works out what kind of project you are building. That decision tells the platform what should run in the browser, what should deploy as backend code, and whether the project needs a server slot at all. V ### Vibe A browser-only experience for games, toys, interactive demos, visual tools, and anything that should run immediately in the player. - Runs in the user's browser. - No server deployment slot required. - Great when the project is interactive but not backend-heavy. P ### Pulse Server-side code that publishes as managed backend endpoints. Vibecodr handles normal deployment wiring, while your handler owns validation, auth, and response shape. - Runs worldwide on the edge. - Uses `env.pulse` for public config and private setup capabilities for secrets or connections. - Uses one deployment slot. C ### Combo One capsule with a browser experience and server endpoints together, so the frontend and backend ship as one intentional object. - Frontend and backend stay in one project. - End-to-end wiring is already implied. - Uses one deployment slot. ## Core Objects & Lifecycle Vibecodr uses a small set of building blocks. Once you know how they fit together, publishing, updating, and sharing start to feel very straightforward. ### Capsule Your editable source home: file tree plus manifest.json . A capsule can power a vibe, a pulse, or both. ### Draft Your working version. Studio keeps saving into this editable copy while you build, test, and change things. ### Artifact A finished published release. Once you publish, Vibecodr freezes the runnable output into an immutable artifact so it can be loaded again exactly the same way later while your draft stays editable. ### Drop The live pointer for an app post. When you publish again, the Drop moves forward to the new artifact while older cuts stay available as exact historical versions. ### Post The public surface people can visit, share, follow, and talk around. For apps, the post points at your capsule and its current live Drop. Lifecycle at a glance ```typescript Capsule (editable source) -> Artifact (immutable release) -> Drop (live version) -> Post (shareable public page) ``` Publishing creates a new artifact without replacing the editable source capsule you keep working in. If a post already exists, its Drop updates to point at the latest artifact. Vibecodr calls that update flow BUMP IT: publish a new version on the same app, keep the same public post, and preserve the full cut history in case you want to pin or roll back to an older version later. Public playback prefers the fast public delivery path automatically. If an older app still lives on an older layout, Vibecodr quietly moves it forward in the background so it can benefit from the newer delivery path too. ## Visibility & Access Visibility answers a clear question: who should be able to find this, open it, and build from it? Vibecodr uses that choice everywhere the post can travel. Visibility ### Public Feed & Search Appears in feed and search. Share & Embed Anyone with the link can view. Embeds and vanity URLs work when policy and allowlists allow them. Remix Remixable by anyone. Visibility ### Unlisted Feed & Search Hidden from feeds and search. Share & Embed Viewable by direct link. Embeds and vanity URLs still work when policy and allowlists allow them. Remix Source is viewable by link. Creating a remix still requires signing in. Visibility ### Private Feed & Search Visible only to the owner. Share & Embed Embeds and vanity URLs are disabled. Remix Owner-only remix or clone. Embeds require a published capsule and still respect safety policy. Moderation or account enforcement can override visibility. ## Two Ways to Create Choose the tool that matches the speed and shape of the thing you want to ship. Fast lane ### VibeComposer For quick posts, single-file capsules, images, links, and longform. Use it when the goal is to get something live fast. Open VibeComposer Full IDE ### Studio For complex multi-file projects with full editing, debugging, automations, secrets, and the deeper shipping workflow. Open Studio ## Safety Boundaries Vibecodr gives creators safer default boundaries for public runtime code, private setup, published releases, and owner-visible diagnostics: #### Encrypted secrets API keys stay server-side and are attached through policy-bound requests #### Project storage Files, metadata, and usage tracking stay on platform-managed storage lanes #### Global edge Public experiences load close to your users around the world #### Sandboxed execution Each vibe runs in its own isolated browser space #### Immutable artifacts Every publish becomes a stable version you can point at again later #### Telemetry + audits Important runtime activity and policy changes are recorded for review ## Quick Start Start with the creation path that matches the size of the idea. 1 #### Try a Quick Post Open VibeComposer and share a thought, image, or your first single-file app. Create a Post 2 #### Explore the Feed See what others are building. Open a vibe, try it, then remix it when you want your own branch. Browse Feed 3 #### Build Something Bigger When you're ready for multi-file projects, open the Studio. Open Studio A creative playground where code becomes social: create, share, and automate, all in one place. ## Structured route body ### The platform model Vibecodr is built around a clear split: creators keep editable source in capsules, publish runnable artifacts that viewers can open immediately, and move the live Drop forward when they BUMP IT. That means the public route can stay stable while the underlying release changes. A vibe is the browser-side experience. A Pulse is the trusted backend plane for work that should not run in the browser: secrets, webhooks, scheduled jobs, storage writes, third-party API calls, and other server-side behavior. - Composer is the fast lane for quick single-file publishing. - Studio is the full workspace for multi-file projects, imports, preview, and release control. - Published artifacts are immutable runtime releases; Drops point the canonical public app at the current release. - Pulses are public HTTP endpoints by default, but their source, secrets, logs, platform capabilities, and operational metadata stay owner-only. ### Where to start Start with the docs page that matches the thing you are building right now. If you are publishing something small, use Composer. If you are deciding whether an imported project can run in the browser, start with the Vibe Runtime guide. If you are adding backend behavior, use Studio and the Vibes and Pulses architecture guide. When in doubt, keep public UI behavior in the vibe and move trusted work into Pulses. This preserves remixability and keeps credentials out of client-visible runtime code. - Read /docs/how-to for execution order and operational checklists. - Read /docs/vibe-runtime when deciding what can run as a vibe. - Read /docs/vibes-pulses before moving trusted work into backend routes. - Read /docs/source before changing release or rollback behavior. - Read /docs/automation-safety before adding triggers, schedules, or webhooks. ### Example and read next Example: you are deciding whether a Stripe-backed launch widget belongs in browser code or a Pulse. Start at /docs/vibes-pulses, keep the visual UI in the vibe, and put webhook or secret-backed work in a Pulse. 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: [How-To Guides](/docs/how-to) - Read next: [Vibe Runtime](/docs/vibe-runtime) - Read next: [Vibes & Pulses](/docs/vibes-pulses) - Read next: [/blueprints](/blueprints) - Read next: [BUMP IT](/docs/bump-it) ## Related documentation - [/docs/how-to](https://player.vxbe.space/docs/how-to) - [/docs/vibe-runtime](https://player.vxbe.space/docs/vibe-runtime) - [/docs/vibes-pulses](https://player.vxbe.space/docs/vibes-pulses) - [/blueprints](https://player.vxbe.space/blueprints) - [/docs/bump-it](https://player.vxbe.space/docs/bump-it)