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

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.

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.

C

Combo

One capsule with a browser experience and server endpoints together, so the frontend and backend ship as one intentional object.

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

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.

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.

Related documentation

  • /docs/how-to
  • /docs/vibe-runtime
  • /docs/vibes-pulses
  • /blueprints
  • /docs/bump-it