Backend guide

The power of Pulses. Trusted backend capability for vibes.

A Pulse is the backend side you add when a vibe needs more help than the browser should give it. Use one for secrets, storage writes, OAuth-connected actions, automations, and other work that should stay private or keep running after someone closes the tab.

Server-side by design

Pulses are where trusted backend work belongs.

They are there for secrets, setup-reviewed connections, policy outbound fetch, structured logs, idempotency, and automations that would feel wrong or risky inside the client-side Vibe runtime.

One folder

Backend power starts with src/server/ or server/.

That folder gives the server-side part of the project a clear home instead of nudging you into a second repo or a second platform just to add one protected route.

Clear config boundary

Public config is env.pulse, not flat env variables.

That keeps user-tunable defaults explicit while source, route setup, grants, logs, state, private runtime wiring, and operational metadata stay out of public project copy.

Safe credentials

Secrets and OAuth connections stay on the server side.

That gives the project more range without asking the browser to hold tokens or other sensitive access it was never meant to carry.

A Pulse is the backend side you add when the vibe needs more than the browser can safely do.

Pulses keep the model concrete. They are the server-side pieces you add when a vibe needs owner-scoped platform resources, idempotency coordination, or integration work that should not happen in public client code.

Definition

A Pulse is the backend helper you add to a vibe.

It does not replace the client-side experience. It is the trusted backend help you add when the project needs private setup, provider calls, webhook verification, idempotency, policy fetch, or structured runtime logs.

Publishing model

Pulse files become same-origin /api/* routes when you ship.

The project keeps one public home while the backend pieces live in the server folder and publish right alongside the app's immutable artifact and live Drop.

Capability model

Pulses expose a clear backend surface instead of a grab-bag of server access.

env.pulse, env.secrets, env.connections, env.fetch, env.webhooks, env.log, env.request, and env.state show up as named capabilities, so you can tell what is available without digging through mystery behavior.

Combo path

When a vibe needs backend help, it grows into a Combo.

That keeps the story easy to follow: vibe for the client experience, Pulse for backend work, Combo when both are present, and BUMP IT when the same app ships its next version.

Put the backend code in one folder, publish it with the rest of the app, and keep the public side simple.

Put backend code in src/server/ or server/. Supported files publish as same-origin /api/* routes, so the project keeps one public endpoint surface while source, secrets, and operational details stay behind the server-side line.

Route model

Pulse files publish into same-origin API routes.

That keeps the client-side experience and backend endpoints under one project instead of splitting the app into separate worlds just to explain where the private code lives.

Trust boundary

Credentials and privileged resources stay behind the server-side line.

The Vibe stays isolated in the browser while the Pulse becomes the place for policy fetches, setup capabilities writes, and automation work that should not depend on a user session staying open.

The backend surface stays intentionally clear: env.pulse, credentials, policy fetch, logs, and sanitized request access.

Pulses expose named capabilities with a clear plan model, so you can see what coordination, credentials, connections, fetch access, and advanced database features are available before you build around them.

Public .pulse config

env.pulse

Free, Creator, Pro

Read non-secret user-configurable defaults without teaching flat public config like env.MODEL.

Usage: Put public values in .pulse and read them as env.pulse.NAME inside server-side Pulses.

const units = env.pulse.DEFAULT_UNITS || "metric";
const queue = env.pulse.SUPPORT_QUEUE_NAME || "support";
return { units, queue };

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.fetch with env.secrets.bearer/header/query so secret values stay policy-bound.

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

const response = await env.fetch("https://api.example.com/v1/messages", {
  method: "POST",
  auth: env.secrets.bearer("PROVIDER_API_KEY"),
});
return await response.json();

Provider-scoped account capability via dispatch

env.connections

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

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

Usage: Use setup-reviewed connected accounts for provider calls.

const github = env.connections.use("github");
const me = await github.fetch("/user", {
  headers: { "User-Agent": "vibecodr-pulse" },
});
return await me.json();

Policy outbound fetch

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 public outbound calls that should follow platform egress policy.

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();

Pulse State operation coordination

env.state

Free, Creator, Pro

Coordinate backend work across Pulse calls with stable operation keys.

Usage: Declare named state resources in the descriptor, then use runOnce(), claim(), keyFromRequest(), and guarded effects for stable operation keys. retentionTtlSeconds controls duplicate-memory retention for the resource and is capped by plan. Vibecodr persists the coordination record in platform-owned durable storage, so cold starts do not erase it and idle retention mostly costs tiny stored metadata.

const key = await env.state.httpMutations.keyFromRequest(env.request);

return env.state.httpMutations.runOnce(key, async () => {
  await chargeCustomer();
  return { accepted: true };
});

Structured logs + sanitized request access

env.log + env.request

Free, Creator, Pro

Write request-scoped logs and inspect sanitized request metadata without platform credential headers.

Usage: Use env.log directly for structured runtime logging. env.waitUntil is only best-effort after-response work, not durable processing.

const requestUrl = new URL(env.request.url);
env.log.info("pulse.request", { path: requestUrl.pathname });
return { received: true, path: requestUrl.pathname };

Plans change how much backend help a project can lean on.

Pulse slots, monthly runs, runtime budget, secrets, connections, and advanced SQL eligibility all shape what feels comfortable here. Use this to decide how much room your project really needs.

Plan Price Pulse slots Runs / month Pulse State operations / month Runtime / run Subrequests / run Secrets Connections Advanced SQL
Free $0 3 1,500 1,500 5s 5 0 1 Advanced path
Creator $9/mo 15 150,000 150,000 15s 25 25 3 Advanced path
Pro $39/mo 50 1,000,000 1,000,000 30s 50 200 Unlimited Advanced compatibility

Snapshot source: packages/shared/src/plans.ts. Advanced SQL remains a compatibility path, not the starter model, and Pulse State operations are the public meter for descriptor-backed Pulse State coordination, tracked separately from general Pulse runs.

Here is the provider currently surfaced through env.connections.

The connection story is intentionally narrow for now. That keeps the credential model understandable and avoids pretending every provider is already equally first-class.

OAuth-backed provider

Providers currently surfaced in the Pulse runtime.

github

Pulse power only works if the line between public code and private work stays obvious.

Pulses keep privileged work on the server-side path, so the browser-side vibe stays focused on interaction while credentials, durable writes, and automation stay protected.

Not the browser runtime

Pulses are server-side, not a second app shell.

They exist so the browser-side vibe can stay focused and isolated while private work moves to the backend layer on purpose.

No plaintext secret free-for-all

Credential access is intentionally mediated.

Secrets and OAuth grants are routed through server-side injection patterns and dispatch-backed enforcement, not handed to user code like loose strings.

Pulse State coordination

Pulse State gives repeated Pulse calls a shared operation memory.

A Pulse runs creator-authored backend code. Pulse State lets those calls meet around named resources and stable keys, so retries, duplicate deliveries, manual claims, and guarded side effects can coordinate before the protected work happens.

Plan-aware backend

Not every backend capability is available on every plan.

Secrets, connected accounts, Pulse slots, and the monthly run budget shape how much backend help a project can lean on. Advanced compatibility SQL stays outside the beginner path.

If you want the fuller picture, these pages explain the parts around Pulses.

These pages help if you want the fuller picture: what a vibe does on its own, what changes when a Pulse joins in, and how the pieces fit together.

Keep the vibe interactive. Add a Pulse when the project needs private or long-running help.

Let the vibe stay focused on what people can see and use. Bring in a Pulse when the project needs private data, outside APIs, idempotency coordination, or work that should keep going after the tab closes.

Questions? Here are the straight answers.

What is a Pulse, simply put?

A Pulse is trusted backend work for a Vibecodr project. Build the playable thing as a Vibe, then add a Pulse when it needs secrets, connected accounts, policy outbound fetch, webhook verification, structured logs, idempotency, or automations.

Where do I put Pulse code?

For a project-backed Pulse, put code in src/server/ or server/. That folder says "this part is backend," and supported files publish as same-origin /api/* routes for that project. Use /pulses/new when you want a standalone reusable backend helper.

Can Pulse code read plaintext secret values directly?

No. The runtime is designed around server-side injection and opaque handles so user-authored code does not become a plain secret dump.

Is env.db the default Pulse backend model?

No. env.db is advanced compatibility SQL, not the beginner backend story, and there is no automatic migration promise from env.db into future Pulse State.

How do Pulses relate to vibes and combos?

A vibe is the part people open and play with. A Pulse is the server-side helper. When a project uses both, that is a Combo.