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.
Backend guide
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
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
env.kv gives you clean key access while Vibecodr keeps projects and Pulses from stepping on each other behind the scenes.
Optional Pro D1
Relational state is available when the plan and code shape justify it, instead of being treated as a universal default.
R2 stays platform-managed
That keeps bundle, asset, and capsule storage aligned with the product's publishing and access model.
What this feels like
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
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
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
KV, protected fetch, secrets, connections, and optional Pro D1 are the practical surface. R2 remains managed through product workflows.
Access map
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.
How you use it
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
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
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.
What you can reach
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.kvScoped 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.secretsCall 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.connectionsUse 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_BindingRun 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.fetchPerform 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.waitUntilAccess 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 };
Access map
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. |
Connections today
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
Where Vibecodr steps in
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
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
The KV wrapper keeps projects and Pulses isolated while still making storage feel straightforward in code.
Pro gates are explicit
That keeps the Worker story honest: direct D1 exists for eligible Pro projects, while other plans stay on the narrower capability surface.
Keep exploring
Start with backend capability, client-side runtime, or the broader publish-and-share loop, depending on which part still feels fuzzy.
Bottom line
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.
FAQ
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.
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.
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.
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.
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.