Backend guide

Cloudflare Workers, without the setup drag.

If you like Cloudflare Workers but do not want to spend your energy rebuilding the same backend setup every time, this is the shape Vibecodr gives you: scoped KV, protected fetch, optional Pro D1, and managed file workflows wrapped around a publishable product.

Workers for Platforms

The backend path is Cloudflare Workers-backed from the start.

You are not inventing a separate backend setup from scratch. Vibecodr already gives the server-side part of the project a Workers-powered home.

Scoped KV

KV shows up as a Pulse-safe API, not a pile of shared-account details.

env.kv gives you clean key access while Vibecodr keeps projects and Pulses from stepping on each other behind the scenes.

Optional Pro D1

D1 appears as a native binding when the project is eligible.

Relational state is available when the plan and code shape justify it, instead of being treated as a universal default.

R2 stays platform-managed

File workflows are handled through Studio and the API layer, not a casual env.r2 binding.

That keeps bundle, asset, and capsule storage aligned with the product's publishing and access model.

Cloudflare Workers show up here as a ready-to-use backend path, not an empty box.

The important question is not whether Workers are involved. It is how that infrastructure turns into something practical for API routes, automations, integrations, and durable state without draining the fun out of building.

Write the fun part

You focus on what the Pulse should do, not the shared-platform wiring around it.

The useful Cloudflare pieces show up where you need them, while the account-separation and storage plumbing stay out of your way.

Same-origin API routes

Pulse files publish into the project's own /api/* surface.

That keeps the public app and the backend routes under one project shape instead of splitting the mental model across multiple deployment surfaces, and BUMP IT keeps future releases on that same app identity.

App-focused bindings

The useful Cloudflare pieces are exposed where they matter.

KV, protected fetch, secrets, connections, and optional Pro D1 are the practical surface. R2 remains managed through product workflows.

Access map

Direct today: env.kv, env.fetch, env.secrets, env.connections. Optional: Pro D1. Managed: R2 and shared-platform wiring.

Use the direct bindings for runtime work, treat env.db as an explicit Pro upgrade, and let Vibecodr keep hold of file workflows, deployment setup, and account separation.

You write backend logic in one folder and it shows up inside the same project.

Put backend code in src/server/ or server/. Supported files publish as same-origin /api/* routes, so the public project keeps one surface while the Worker-backed backend lives behind it.

Route model

Pulse files publish into same-origin /api routes.

That keeps the client-side experience and backend endpoints under one project instead of making you explain a second deployment surface to everyone who touches the app.

Managed infrastructure

Some capabilities are direct in code, while storage and deployment plumbing stay managed for you.

Reach for direct bindings like KV, protected fetch, credentials, and optional Pro D1 in Pulse code, then let Vibecodr handle asset storage, publish wiring, and the shared-platform safety work around them.

The direct Worker surface stays intentionally small: KV, protected fetch, credentials, and optional Pro D1.

Use this section to see what can live directly in Pulse code today, what needs a Pro upgrade, and what still stays managed instead of turning into another thing you have to wire yourself.

Cloudflare KV

env.kv

Free, Creator, Pro

Scoped key-value storage for counters, caches, idempotency keys, and lightweight state between runs.

Usage: Each key is prefixed per Pulse at runtime, so the code stays clean while storage stays isolated.

const count = Number((await env.kv.get("visits")) ?? "0");
await env.kv.put("visits", String(count + 1), { expirationTtl: 300 });
return { visits: count + 1 };

Dispatch proxy + encrypted secret storage

env.secrets

Creator, Pro

Call external APIs without turning your Pulse code into a plain secret viewer.

Usage: Use env.secrets.get() with env.fetch(), or env.secrets.fetch() when you want explicit server-side injection rules.

if (!env.secrets.has("OPENAI_API_KEY")) {
  return { error: "Configure OPENAI_API_KEY first" };
}

const token = env.secrets.get("OPENAI_API_KEY");
const response = await env.fetch("https://api.openai.com/v1/models", {
  headers: { Authorization: "Bearer " + token },
});
return await response.json();

OAuth connection tokens via dispatch

env.connections

Free (1), Creator (3), Pro (unlimited)

Use connected provider accounts without manually storing provider access tokens inside user code.

Usage: Get an opaque provider token handle and pass it through env.fetch().

const githubToken = env.connections.get("github");
const me = await env.fetch("https://api.github.com/user", {
  headers: {
    Authorization: "Bearer " + githubToken,
    "User-Agent": "vibecodr-pulse",
  },
});
return await me.json();

Native Cloudflare D1 binding

env.db / env.Pro_User_Binding

Pro only

Run SQL queries against the per-user D1 database for relational and transactional workflows.

Usage: The binding is added at deploy time when the project uses env.db and the owner is eligible for Pro D1.

if (!env.db) {
  return { error: "This Pulse needs Pro for env.db" };
}

await env.db.query(
  "CREATE TABLE IF NOT EXISTS Pulse_orders (id TEXT PRIMARY KEY, total_cents INTEGER)"
);
await env.db.query(
  "INSERT INTO Pulse_orders (id, total_cents) VALUES (?, ?)",
  [crypto.randomUUID(), 1999]
);
const { results } = await env.db.query("SELECT COUNT(*) AS total FROM Pulse_orders");
return results[0];

Protected fetch wrapper + outbound policy checks

env.fetch

Free, Creator, Pro

Perform outbound HTTP requests through the server-side trust boundary instead of from the client-side vibe.

Usage: Use env.fetch for normal outbound calls. It is also token-aware for env.secrets and env.connections patterns.

const res = await env.fetch("https://api.weather.com/v1/forecast?city=SF");
if (!res.ok) {
  return { error: "Upstream error: " + res.status };
}
return await res.json();

Runtime metadata + execution context

env.env + env.log + env.waitUntil

Free, Creator, Pro

Access Pulse identifiers and version metadata, write request-scoped logs, and schedule non-blocking follow-up work.

Usage: Use env.env for metadata, env.log for traceability, and env.waitUntil() for async work that can continue after the response.

env.log.info("pulse metadata", env.env);
env.waitUntil(env.kv.put("last-run-at", new Date().toISOString()));
return { pulseId: env.env.pulseId, version: env.env.version };

What you get directly, what is optional, and what Vibecodr still owns.

This is the clearest honest map of the current Cloudflare story on Vibecodr, without pretending every feature is already exposed the same way.

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 is injected for eligible deployments.
R2 Studio and API file workflows Platform-managed No direct env.r2 binding in PulseEnv today.
Secrets and connections env.secrets and env.connections via env.fetch Plan-aware Credential access is server-mediated rather than direct raw token access.

Here is the provider currently exposed through env.connections.

The connection story is intentionally narrow for now. That is more honest than pretending every provider is already surfaced equally inside the runtime.

OAuth-backed provider

Provider currently surfaced in the Pulse runtime.

github

Use direct bindings for app logic, and let the platform keep hold of the risky plumbing.

The important boundary is straightforward: use direct bindings for backend logic, reach for Pro D1 when you genuinely need relational state, and let Vibecodr keep file storage, deployment wiring, and project separation under platform control.

No direct env.r2 today

R2 is part of the platform workflow, not the Pulse runtime surface.

That distinction matters because bundle and asset storage are tied to publishing, Studio, and API pathways rather than arbitrary Worker-side file access.

Scoped KV, not raw namespace access

Pulse code gets the safe API instead of raw shared-storage handles.

The KV wrapper keeps projects and Pulses isolated while still making storage feel straightforward in code.

Pro gates are explicit

D1 is not implied unless the project and plan qualify for it.

That keeps the Worker story honest: direct D1 exists for eligible Pro projects, while other plans stay on the narrower capability surface.

Follow the guide that matches the question you actually have right now.

Start with backend capability, client-side runtime, or the broader publish-and-share loop, depending on which part still feels fuzzy.

Use the Workers-backed path for real backend logic, then let Vibecodr carry the setup burden around it.

The result is a cleaner backend workflow: direct access where you need it, less setup noise where you do not, and a much clearer picture of how KV, D1, and R2 fit into a real project.

Questions? Here are the straight answers.

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

No. Vibecodr binds the platform KV namespace and exposes env.kv with automatic Pulse-scoped prefixing, so your code works with clean keys instead of account-separation plumbing.

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 projects.

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 instead of being exposed as a direct Pulse binding.

Can one Pulse read another Pulse's KV data?

Not through the provided runtime API. Pulse code gets env.kv rather than raw VIBE_KV, and runtime calls are scoped per Pulse so list and key operations stay inside the intended boundary.

What is the practical Cloudflare story here?

You get a Workers-backed backend path that already feels shaped for apps: scoped KV, protected fetch, optional Pro D1, and managed file storage, without having to rebuild the same app plumbing from scratch.