Cloudflare Workers, without the setup drag

Vibecodr Pulses give you a practical Cloudflare Workers for Platforms runtime with app-focused defaults: scoped KV, optional Pro D1 SQL, and R2-backed file workflows. You write business logic; the platform wires the tenancy boundaries.

Workers for Platforms Scoped KV API Pro D1 binding R2-backed file workflow Tokenized secrets

Open Pulses Read how-to docs Check plan limits

Snapshot date: February 16, 2026.

Programmatic access, by capability

The runtime surface intentionally separates what is direct in user code from what stays platform-managed for isolation and safety.

Capability	How you access it	Availability	Truth status
`KV`	`env.kv.get/put/list/delete`	All pulse plans	Scoped wrapper auto-prefixes keys per pulse.
`D1`	`env.db` (or `env.Pro_User_Binding`)	Pro	Native D1 binding injected for eligible deployments.
`R2`	Studio/API file workflows	Platform-managed	No direct `env.r2` binding in PulseEnv today.

R2 is used for capsule files and runtime bundles; file editing flows go through API routes such as /capsules/:id/files/:path.

What developers actually write

Enhanced pulse handlers expose a single env object so you can ship storage and logic quickly without managing Cloudflare worker metadata directly.

export default async function run(input, env) {
  const key = "counter";
  const current = Number((await env.kv.get(key)) ?? "0");
  const next = current + 1;
  await env.kv.put(key, String(next), { expirationTtl: 3600 });

  if (env.db) {
    await env.db.query(
      "CREATE TABLE IF NOT EXISTS Pulse_metrics (k TEXT PRIMARY KEY, v INTEGER)"
    );
    await env.db.query(
      "INSERT OR REPLACE INTO Pulse_metrics (k, v) VALUES (?, ?)",
      [key, next]
    );
  }

  return { ok: true, count: next };
}

Security onion, not a single guardrail

Tenant-scoped KV surface

Runtime storage calls are implemented with an internal prefix model: vibe:{env.VIBE_ID}:, so key operations are pulse-scoped by default.

Secret and token boundaries

Secrets and OAuth connections are represented as opaque references in user code, then resolved server-side at dispatch boundaries.

Managed deploy plumbing

Pulse deployments bind VIBE_KV and optional Pro D1 in WfP metadata, so tenant storage wiring stays platform-enforced instead of ad-hoc.

Power of Pulses Capability matrix for env.kv, secrets, connections, and Pro D1. Pulses Operating Center Create, run, and manage pulse workflows. How-To Docs Practical implementation steps and examples. Social Runtime overview How runtime execution and remix distribution work together. Glitch migration path Translate hosted-project workflows to vibes and Pulses. Plan limits Storage, run quotas, and Pro D1 eligibility details.

FAQ

Do I need to manually provision a KV namespace for every pulse?

No. Vibecodr binds a platform KV namespace and exposes env.kv with automatic pulse-scoped prefixing, so your code works with clean keys.

Can pulse code access D1 directly?

Yes on Pro when env.db (or env.Pro_User_Binding) is present. D1 is attached as a native binding during deployment for eligible pulses.

Is R2 exposed as env.r2 inside pulse code?

Not currently. R2 is platform-managed for capsule files, bundles, and assets through Studio and API workflows.

Can a user read another user's KV data?

Pulse code receives env.kv, not raw VIBE_KV. Runtime calls are prefixed per pulse and list operations are prefix-scoped, preventing cross-pulse key access through the provided API.