Cloudflare Workers
Workers are the execution layer PrimeLabs uses for many Cloudflare-native applications. A Worker is the place the request is authenticated, authorised, validated and answered. It is not a pile of one-off functions beside a server that still has to be kept alive.
The same project can hold an API, a session check, a webhook, a full-stack route and the binding that reaches D1 or R2. The architectural overview stays on Cloudflare application development.
Cloudflare Workers is a serverless runtime for application code on Cloudflare’s global network. The runtime is web-interoperable and uses V8. Each Worker runs in its own isolate: a lightweight sandbox, not a virtual machine started for that request. Isolates start quickly because the runtime is already there. That is a different model from a container per function.
A request that reaches the Worker’s hostname invokes the fetch handler with the request. The handler returns a response. Scheduled jobs, queues and other triggers exist, and they are still application code with a limit, not a second operating system.
JavaScript and TypeScript are the usual path. Python, Rust and several full-stack frameworks are supported. The framework does not remove the need to decide what the request is allowed to do.
PrimeLabs Runtime Trace is an example of a request moving through checks. The timings are illustrative. Selecting a stage shows the input, the binding, and whether anything was written. Nothing on this page calls Cloudflare.
Example interface. Not a client project.
PrimeLabs runtime trace · example · timings are illustrative
POST /api/onboarding/ON-2084/approve
Example only. No request was sent, and no record was changed.
A binding is a named handle, on the environment object, for a service the Worker is allowed to use: a D1 database, an R2 bucket, a queue, a workflow, a secret. The browser does not hold that handle. Code creates a client for a secret inside the request, so a rotated secret is the one the next request sees.
A typical path is short. The request arrives. The session is checked. The organisation is checked. The input is checked. A record is read. A precondition is compared with that record. Only then does a write, a workflow signal or a call to another system happen. If the precondition fails, the response says so and the write does not.
That path is the backend of a SaaS product, a portal, or an internal tool. It is also the place a webhook is verified before a partner’s payload is trusted. A process that must wait hours for a person leaves the request and continues as workflow automation.
Workers can host JSON APIs, a backend-for-frontend that shapes data for one screen, session routing, payment and integration calls, and full-stack routes with static assets. Smart Placement can run a Worker closer to the data it talks to, including D1, when latency to that data matters more than running in the visitor’s nearest city.
Global execution does not repair a design that does too much in one request. Waiting on the network does not count as CPU time. The CPU time spent in the isolate is still limited, and each isolate has a memory ceiling of 128 MB. A large file is streamed to object storage. It is not buffered into the handler. A request has no fixed wall-clock cap while the client stays connected, and that is not a reason to hold a business approval open inside it.
Sensitive values are Worker secrets, or a secrets store binding. Plaintext environment variables are for configuration that can be read. A secret is available to the Worker and is not written into the source or the logs. Changing a secret creates a new version of the Worker.
The platform terminates TLS and applies its own abuse controls. Application authorisation is still code: who the person is, which organisation they act for, and which row they may change. A binding is not a public API.
Workers include observability: logs in the dashboard, near-real-time logs while a change is shipping, and traces that follow a request through fetch calls and binding operations without a separate agent to install. Logpush can send trace events elsewhere when the team already has a place for them. CPU time and wall time are part of that record.
Observability is how a blocked write is explained later. It does not replace the precondition. A log line that says the handler returned 409 is useful because the code decided not to write.
Wrangler, or a build pipeline that calls it, uploads a version and deploys it. Gradual deployments exist when a change should move across traffic in steps rather than all at once. Bindings travel with the version. Staging and production are different deployments. A small fix does not wait on a new server.
That speed is the point, and it is also the reason a migration and a permission change are reviewed before the version that depends on them is the one users hit.
A useful note names that route, who may call it, what it is allowed to write, and which binding it needs. There is no Worker running this example.
It can be a small handler. In an application it is the request path: routes, checks, bindings and the response. Calling it a function undersells the job and oversells how little design it needs.
No. A request that does too much is still slow, wherever it runs. Placement can move the Worker closer to its data. It does not remove a missing index or an unnecessary model call.
No. Some workloads belong on a server the vendor already requires, or inside a network Workers are not in. PrimeLabs will say so.