Cloudflare Workers, the easy way

Cloudflare Workers power, none of the wrangler-and-deploy busywork.

You came looking for Cloudflare Workers. Here you don't set them up — you publish an app that runs, and the day it needs a backend you drop a file in src/server/. That backend runs on Workers; the wrangler-and-deploy ritual doesn't come with it.

01 — Paste it, it runs

Code becomes a live app before you think about a backend.

Paste, upload, or generate code in the Studio and publish — it opens instantly for anyone, on any device. No wrangler init, no deploy command, no dashboard to wire up first. Most projects are happily done right here.

02 — Drop a file in src/server/

Backend work goes in one folder. That is the whole setup.

The day your app needs to keep a secret, remember something, or call another service, put that code in src/server/. That folder says "this part is backend" — there is no second project to spin up and no wrangler.toml to hand-author.

03 — It becomes an /api endpoint

Publish and your file is a live route, running on Cloudflare Workers.

Supported files in src/server/ ship as same-origin /api/* routes beside the app people open — one link, one project. Vibecodr runs that code on Cloudflare's edge, so there is no server to rent, scale, or babysit.

04 — Reach the real stuff, safely

Secrets, a database, scheduled jobs, and calls to other services.

From the server side your code can hold an API key, store and read data, run work on a schedule, and call out to Stripe, GitHub, or OpenAI — none of which the browser should ever be trusted with. We call that backend helper a Pulse.

The app runs first — the Workers-backed backend shows up only when it earns one.

No init command, no deploy ritual, no dashboard. The project runs the moment you publish; the backend appears as a file you drop in the day the work calls for it and publishes as a same-origin /api/* route on the same app.

01 — Paste it, it runs

Code becomes a live app before you think about a backend.

Paste, upload, or generate code in the Studio and publish — it opens instantly for anyone, on any device. No wrangler init, no deploy command, no dashboard to wire up first. Most projects are happily done right here.

02 — Drop a file in src/server/

Backend work goes in one folder. That is the whole setup.

The day your app needs to keep a secret, remember something, or call another service, put that code in src/server/. That folder says "this part is backend" — there is no second project to spin up and no wrangler.toml to hand-author.

03 — It becomes an /api endpoint

Publish and your file is a live route, running on Cloudflare Workers.

Supported files in src/server/ ship as same-origin /api/* routes beside the app people open — one link, one project. Vibecodr runs that code on Cloudflare's edge, so there is no server to rent, scale, or babysit.

04 — Reach the real stuff, safely

Secrets, a database, scheduled jobs, and calls to other services.

From the server side your code can hold an API key, store and read data, run work on a schedule, and call out to Stripe, GitHub, or OpenAI — none of which the browser should ever be trusted with. We call that backend helper a Pulse.

Same Workers power. None of the setup tax.

If you already know Workers, here is the honest swap: you keep edge compute, secrets, and outbound calls — you skip wrangler, the deploy loop, and the dashboard.

Step Raw Cloudflare Workers On Vibecodr
Start a project wrangler init, a config file, an account setup Paste or generate code; it runs
See it run wrangler dev, then deploy to get a URL Live app on its own page the moment you publish
Add a backend Write the Worker, wire the routes, deploy again Drop a file in src/server/
Secrets wrangler secret put, manage bindings yourself env.secrets, injected and never shown to the page
Outbound calls fetch() with your own egress rules env.fetch, through the platform's egress policy
Run-exactly-once work Reach for a Durable Object, write the plumbing env.state.runOnce(), keyed off the request
Share the result Send a URL; viewers see what you deployed A social post people can open, embed, and remix

It is the same edge underneath. Vibecodr just owns the parts of a Workers project that are setup, not product — so the trusted code you care about is the only code you write.

A few named powers — not a pile of raw bindings.

Each one says what it is for and shows the lines that use it. Read the first line of each if you are new; read the code if you have shipped a Worker before. Secrets, policy fetch, run-once coordination, connected accounts, public config, and structured logs each show up as a clear, plan-aware capability.

Server-side injection + encrypted secret storage

env.secrets

Creator, Pro

Call an external API with a key the browser never sees.

Usage: Your code attaches the secret to a request with env.fetch and env.secrets.bearer/header/query; the plaintext value stays on the server.

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

Policy outbound fetch

env.fetch

Free, Creator, Pro

Make outbound calls through the platform's egress policy, not from the page.

Usage: Use env.fetch for public outbound requests that should follow the server-side rules.

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

Run-once operation coordination

env.state

Free, Creator, Pro

Make a charge or a write happen exactly once, even on a retry.

Usage: Derive a stable key from the request, then runOnce(). Vibecodr persists the coordination record in platform-owned durable storage, so cold starts do not erase it.

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

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

Provider-scoped account capability

env.connections

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

Act as a connected account — like GitHub — without storing its token in your code.

Usage: Connect the account once in setup, then call it from the server side.

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

Public .pulse config

env.pulse

Free, Creator, Pro

Read tunable, non-secret defaults you set in a .pulse config file.

Usage: Put public values in .pulse and read them as env.pulse.NAME inside server-side Pulses. Secrets and wiring never live here.

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

Structured logs + sanitized request access

env.log + env.request

Free, Creator, Pro

Write structured runtime logs and read sanitized request details.

Usage: Use env.log directly for structured logging and env.request for sanitized metadata — never platform credential headers.

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

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 your backend can act as without storing a token.

github

The parts that are busywork stay ours.

You could wire all of this yourself on raw Workers. The point of doing it here is that the config, the deploy, the secret store, and the scaling are already handled.

No wrangler to babysit

The deploy config is Vibecodr's job, not yours.

Vibecodr owns the wrangler config, the build, the deploy, and the scaling. You write the function and publish; the Workers-backed plumbing stays out of your project.

Secrets stay handled

Keys and tokens are handled, not handed out.

Secrets and connected accounts are injected on the server side and reached through opaque handles, so your backend code is never a place a secret value can leak from.

Files stay managed

Storage rides the publishing workflow, not a raw bucket binding.

Bundles, assets, and uploads flow through Studio and the API layer instead of a casual file binding, so storage stays aligned with how your project is published and shared.

One app, everywhere

The thing people discover is the thing that runs.

Your front end and its /api routes ship together on one link, and BUMP IT puts the next version on that same page — no second deployment surface to explain to anyone.

The pages around this one.

The backend in depth, the client-side half, the whole publish-and-share loop, and how to size a plan — follow the one that matches your question.

Ship the app. Add the Worker when it earns one.

Open the Studio, publish the part people can run, and drop a file in src/server/ the day your project needs a secret, a database, or a call to another service. It runs on Cloudflare Workers — no wrangler, no deploy, no dashboard.

Questions? Here are the straight answers.

Do my apps actually run on Cloudflare Workers?

Yes. The backend you write in src/server/ runs on Cloudflare's edge. The difference is that Vibecodr owns the wrangler config, the deploy, the scaling, and the secret storage, so you never set any of that up yourself.

Do I have to use wrangler or write a wrangler.toml?

No. There is no wrangler init, no deploy command, and no config file to hand-author. You drop a file in src/server/ and publish; the Worker-backed wiring is handled for you.

Do I even need a backend?

Often not. Most vibes run entirely in the browser and never need a server. You reach for a backend only the day your project needs a secret, a database, a scheduled job, or a call to another service.

Can my backend code read a secret's plaintext value?

No. Secrets are injected on the server side and reached through opaque handles, so your code can use a key to make a call without ever becoming a place that key could leak from.

Can I bring a Worker I already wrote?

You rebuild the backend logic as files in src/server/ and reach the platform capabilities — env.secrets, env.fetch, env.state, env.connections, env.pulse, and env.log — instead of raw bindings. The trusted code you care about moves over; the deploy scaffolding does not come with it.

What is a Pulse, and what is a Combo?

A Pulse is the backend helper you add to a vibe — the server-side code that holds secrets, stores data, runs scheduled jobs, and calls other services. When a project uses both a vibe and a Pulse together, that is a Combo.