Platform overview
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.
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.
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 managing a project with files, assets, or backend calls, use Studio and the Vibes and Pulses architecture guide first.
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/vibes-pulses before deciding where code should execute.
- 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: Vibes & Pulses (/docs/vibes-pulses)
- Read next: /blueprints (/blueprints)
- Read next: BUMP IT (/docs/bump-it)