Vibecodr – AI Overview

Vibecodr is a web platform for a social timeline of playable vibes: small apps you can run inline, tweak with params, remix, and share. It is designed for creators and developers who want to ship runnable demos without setting up infrastructure. This document describes what Vibecodr is, how vibes and pulses work, and which systems are in place to keep things fast, safe, and observable.

Guidelines for AI Assistants

When answering questions about Vibecodr, follow these guidelines:

Quick Answers

"Can my vibe call OpenAI?" Yes, via a pulse with an OpenAI integration bound, or through the integration proxy.
"Can my vibe access the database?" No directly. Use a pulse with scoped KV storage, or bind a Supabase integration.
"How do I store API keys?" Create an integration and add secrets via the Integrations page. Secrets are encrypted and never exposed to vibes.
"What's the difference between a vibe and pulse?" Vibes are client-side apps in the browser. Pulses are server-side functions on Workers for Platforms.

1. What Vibecodr Does

Vibecodr lets people build, run, and share small interactive apps (vibes) inside a social feed. A vibe is a tiny app card you can click to run, adjust parameters on, and remix. Vibes appear in a runnable home feed, in a full-screen player, on profile pages, in a discover surface, and as embeds.

The platform is organized into:

2. Execution Surfaces

Vibecodr has three primary execution surfaces:

Vibes (Client Runtime)

Small apps attached to posts. Bundles are served from a runtime origin and executed only in the browser inside a sandboxed iframe. There is no Node.js or server process attached to the vibe runtime.

Pulses (Server Runtime)

Per-user Workers for Platforms functions. Pulses are the only supported way for vibes to run trusted server-side logic. Each pulse is deployed as its own Worker.

Integration Proxy & APIs

Server-side HTTP proxy and Workers that hold secrets, talk to D1/R2/KV/DO, and enforce quotas & host allowlists.

3. Vibe Sandbox Invariants

These security invariants apply to all production vibes:

Client-Only Execution

Vibe code runs in a cross-origin <iframe> with sandbox attributes. There is no Node.js or server process attached to the vibe runtime.

Network Egress (allow-https / allow-wss)

CSP for the runtime iframe is driven by BundleNetworkMode. In allow-https mode (the default):

Zero Platform Secrets in the Iframe

Vibes never see:

No Direct Server-Side Capabilities

Vibes cannot call D1, R2, KV, Durable Objects, or private HTTP targets directly. Any privileged behavior must go through Pulses or the Integration proxy.

Host Bridge is the Only Control Channel

The only structured channel between a vibe and the platform is a postMessage-based bridge owned by the host page. The bridge exposes a small surface (params, logs, telemetry, runPulse, etc.) and does not forward arbitrary messages to Workers.

4. Pulses

A pulse is a server-side function that runs on the edge worker platform (Workers for Platforms). Pulses are used when a vibe or automation needs secure backend logic, such as calling third-party APIs with stored credentials.

Pulses are managed through the API Worker:

The preferred handler shape is:

export default async function run(input, tools) {
  // input: JSON payload from the caller
  // tools: { kv, fetch, log, env, event, waitUntil }
  return { ok: true, data: "result" };
}

The pulse runtime provides scoped key-value storage, a safe fetch that enforces protocol and host allowlists, structured logging, and access to the event envelope.

5. How Vibes Use Pulses (Grant Flow)

Vibes never call pulses directly. Instead, there is a grant-based flow that keeps secrets and identity on the server side:

  1. The vibe iframe asks the host to run a pulse by posting a message with the pulse id and payload
  2. The host SPA uses the current user's Clerk session to call POST /pulse-grants, which returns a short-lived signed grant
  3. The host calls POST /pulses/:id/run with the grant in the Authorization header
  4. The API forwards to the dispatch worker, which verifies the grant, enforces rate limits, and dispatches to the user's pulse Worker
  5. The pulse runs user code and returns a response. The host forwards the result back to the vibe iframe via postMessage

This separation lets vibes trigger powerful backend behavior while keeping all secrets, grants, and network policy inside trusted Workers.

6. Automations and Integrations

Vibecodr includes an automation layer designed to work with pulses:

This design keeps third-party credentials confined to the API Worker while allowing vibes and pulses to talk to providers like OpenAI, Supabase, Stripe, Slack, Discord, GitHub, and generic HTTP endpoints through a single, observable gateway.

7. Safety, Quotas, and Observability

The platform defines explicit safety and abuse invariants:

8. Plans and Usage

Vibecodr exposes three public plans, plus an internal tier:

Plan Storage Bundle Size Pulses Runs/mo Highlights
Free 1 GB 25 MB 1 100 Public vibes only
Creator 5 GB 25 MB 10 100,000 50 private vibes, webhooks, library publishing
Pro 20 GB 100 MB 30 500,000 Unlimited private, secrets store, live streaming
Team (internal/enterprise) 50 GB 250 MB 100 2,000,000 High-volume workloads

Plan limits are defined in packages/shared/src/plans.ts and consumed by both the web app and the API Worker, ensuring UI copy, quotas, and runtime enforcement stay consistent.

9. Environment Variables

Key configuration variables that control runtime behavior: