Browser runtime contract

What Can Be a Vibe?

A vibe is browser-executable software packaged as a Vibecodr runtime artifact. This page explains what can run inside that artifact, what WebAssembly makes possible, and when a project needs Pulse-backed server authority instead.

Technical contract for what can run inside the Vibecodr browser runtime.

Implementation focus

Use this page before importing, adapting, or debugging a project so you can tell whether the work belongs in the browser runtime, in a Pulse, or in a combo project.

Expected outcomes

A vibe is a browser runtime artifact

A vibe is not just front-end source. A vibe is browser-executable software that Vibecodr can import, analyze, build or normalize, package into a published artifact, and run inside the Vibecodr player boundary.

The important split is source versus runtime. Source is what you edit in Composer, Studio, ZIP import, GitHub import, or remix. The runtime artifact is the browser-ready output viewers open after publish.

  • A pure vibe runs on the viewer's device inside the browser runtime.
  • A published vibe has an entry point, assets, dependency facts, runtime metadata, and sandbox policy around it.
  • A vibe can be small HTML or a larger compiled browser app; size and complexity are not the boundary.
  • The boundary is whether the work can run safely as browser software without trusted server authority.

What can run inside a pure vibe

The vibe runtime is for browser-shaped software. That includes ordinary pages, framework builds, media-heavy projects, canvas tools, WebGL scenes, browser workers, and local or mirrored WebAssembly modules.

A project still needs a browser entry point or a supported build recipe. Uploading a real repository is not enough if the repository only contains backend, CLI, extension, or local-machine assumptions.

  • HTML, CSS, JavaScript, and browser-ready TypeScript or TSX output.
  • React, Vite-style, Astro static, Next static export, SvelteKit static, and plain static output when the build result is browser-ready.
  • Images, fonts, audio, video, JSON, and other runtime assets that the browser can load.
  • Canvas, p5-style sketches, WebGL, Three.js, charts, editors, games, simulations, and document-like tools.
  • Local `.wasm` files and deterministic mirrored `.wasm` assets loaded from the artifact.
  • Dedicated or shared workers when their scripts resolve to the runtime origin, bundle origin, or `blob:`. Service workers are blocked inside sandboxed runtime surfaces.
  • Public HTTPS fetches that fit browser and Vibecodr runtime policy. Private credentials and protected provider calls belong in Pulses.

WASM makes vibes deeper without making them servers

WebAssembly lets a vibe run compiled software inside the viewer's browser. That can make a vibe much more than UI glue: emulators, physics engines, parsers, compilers, image processors, audio engines, simulations, and other browser-compatible engines can live in the artifact.

WASM does not change the trust boundary. It still runs as browser compute on the viewer's device. It does not create server secrets, durable backend state, Node compatibility, arbitrary filesystem access, or a long-running process after the page closes.

  • Good fit: a browser compiler playground with the compiler shipped as `.wasm`.
  • Good fit: a physics or simulation engine that reads local assets and renders to canvas or WebGL.
  • Good fit: an image or audio processor where files are chosen by the viewer and processed locally.
  • Needs Pulse: the same tool calling a private provider API, storing user results, or coordinating work across users.
Load a local WASM module from the artifact javascript
const imports = {};
const response = await fetch("./engine.wasm");

const { instance } = await WebAssembly.instantiateStreaming(response, imports);

const result = instance.exports.run?.();
console.log(result);

When the work belongs in a Pulse

Use a Pulse when the code needs trusted backend authority. The browser vibe can still own the interface, but the secret, provider call, webhook, database write, or protected operation should happen behind a same-origin Pulse route.

This is not about whether the project is serious. It is about whether the behavior can be safely shipped to every viewer as client-visible code.

  • Use Pulse for API keys, tokens, secrets, connected accounts, and provider credentials.
  • Use Pulse for webhook verification, email sending, payment callbacks, and protected provider calls.
  • Use Pulse for durable state, database access, idempotency, cross-user coordination, and backend authorization.
  • Use Pulse for scheduled or event-driven work that must happen without a viewer keeping a tab open.
  • Use a combo project when the same capsule has both the browser UI and server files under the supported server source lane.

Real code is not always a runnable vibe as-is

Some projects are real developer projects but are not vibes without adaptation. If a project expects a local terminal, a Node CLI, a long-lived server, Docker, Postgres, native binaries, a VS Code extension host, or a language server process, Vibecodr should not pretend the browser player can run it unchanged.

The migration path is usually to expose the browser-ready part as the vibe, then move trusted server behavior into Pulses or rewrite local-machine assumptions into browser-compatible code.

  • Node CLI project: turn it into a browser playground or use Pulse for trusted server execution.
  • Express or framework server: keep the client UI as a vibe and move supported endpoints into Pulses.
  • Database-backed app: keep rendering in the vibe, then use Pulse or an external service for records.
  • VS Code extension or LSP: publish a browser demo, not the editor extension host itself.
  • Docker Compose or native binaries: they need a different execution environment, not the public vibe runtime.

How source becomes a runtime

Imports and publishes do more than copy files. Vibecodr checks the uploaded shape, looks for the browser entry point and server files, applies a supported build or static recipe when needed, and records the publishable output as a runtime artifact.

After publish, player, focus, embed, and vanity surfaces should read the same release facts instead of rediscovering the project from source. That is why a published vibe can be stable even when the original source keeps changing.

  • Import analysis checks archive size, file count, entry candidates, server files, package manager, and recipe fit.
  • Build or normalization produces browser-ready output when a project is not already static.
  • The runtime artifact records bundle files, content types, dependency facts, presentation hints, and runtime policy.
  • The player hosts the artifact in a sandboxed iframe with controlled script, worker, asset, and network behavior.
  • BUMP IT creates a new runtime cut for the same public app identity instead of mutating the old release.

Cost, quotas, and performance

Pure vibe execution happens in the viewer's browser, so opening a client-only vibe does not consume Pulse runs or deployment slots. That is why complex client compute can be practical when it is packaged as browser software.

It is still not unlimited magic. Vibes still have storage, file-count, bundle-size, import-build, bandwidth, safety, browser-memory, and device-performance limits. Pulses have their own run, compute, subrequest, secret, connection, and state limits because they use trusted backend capacity.

  • Browser rendering, WebGL, and WASM compute are paid by the viewer's device performance.
  • Import and build work is paid by Vibecodr build capacity and can be queued or rejected by plan limits.
  • Static artifact serving still depends on safe delivery lanes and published artifact availability.
  • Pulse execution is server-side and uses deployment slots plus plan-shaped runtime limits.
  • When a project is slow, first ask whether the cost belongs to browser compute, build work, artifact delivery, or Pulse execution.

Quick classification guide

Use this guide before importing or debugging a project. It is intentionally about execution shape, not quality. A rough sketch can be a valid vibe, and a serious repository can still be source-only until it has a browser runtime path.

When classification is unclear, start by finding the first thing a viewer should open. If that thing can run in the browser from published assets, it can be a vibe. If it needs server authority, split the interface and trusted work.

  • Pure vibe: Three.js game, canvas sketch, static dashboard, browser editor, local WASM demo, markdown tool, emulator demo.
  • Combo: UI plus `/api` routes for generation, provider calls, save actions, leaderboards, webhooks, or account-aware behavior.
  • Pulse only: webhook receiver, scheduled job, provider relay, backend automation, idempotent operation worker.
  • Not runnable as-is: server-only repo, Node CLI without browser UI, Docker app, database service, VS Code extension, native desktop app.

Example and read next

Example: you imported a project with WebAssembly, canvas, and a small UI. Keep the browser engine in the vibe, then add a Pulse only if it needs secrets, durable state, provider calls, or work after the page closes.

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/vibes-pulses
  • /docs/import-project
  • /docs/supported-build-recipes
  • /docs/pulse-runtime-api