PrimeLabs · application architecture

Modern applications without a server fleet to keep alive.

PrimeLabs builds the product. Cloudflare is the platform underneath it: a global network, a Worker for the application, and only the data and workflow services that product needs. This is not a consultancy for Cloudflare itself.

The studio is in Perth. The applications are reached wherever their users are, because the request terminates on Cloudflare’s network rather than on a machine in one rack.

One possible shape

  1. UsersBrowser, portal, API
  2. Cloudflare networkTLS, cache, the edge in front of the app
  3. WorkersRoutes, checks, the application
  4. Selected servicesOnly the ones this product binds

A member portal might use D1 and R2. It might not use a vector index. The diagram is a menu, not a shopping list.

Choose the primitives the application actually needs

Select a service in this member-portal example. The panel says what that service does in the product, the path a request takes, and an illustrative operating state. Nothing here calls Cloudflare.

Example interface. Not a client project.

Example application · Member Portal

Services this portal actually binds

Workers

Where it sits in the portal

Used for
Session check, member routes, and the decision about which record a request may see.
Path
Browser → Cloudflare network → Worker → D1 for the member → response.
Illustrative
2,140 requests this week · p95 41 ms on the member home.
State
Production · v2.6.1 · reviewed 28 Sep 2026.

What each service is for

The homepage stack is the short version. This is the working rule PrimeLabs uses when drawing the diagram.

Workers

What it does. The application runtime. HTTP routes, session checks, validation, webhooks and calls to other services run as Worker code on Cloudflare’s network, without a virtual machine allocated to the app.

When we use it. For the request path, and for short jobs that are still just code: an API, a signed download, a webhook from a finance system.

When we do not. A process that must wait hours or days for a person does not stay open inside the request. Files do not live in the script. Those belong to Workflows and R2.

D1

What it does. A managed relational database built on SQLite. The Worker queries it over the network. Schema migrations, import and query visibility are part of the product, which is why it is the usual system of record.

When we use it. Accounts, invoices, bookings, memberships, and the state of a workflow, when those rows are queried together.

When we do not. Not for the PDF itself, and not for a single hot key that many users must update at the same instant. Large analytical scans of years of logs are a different kind of store. If the query must sit in the same thread as strongly consistent coordination, that is a Durable Object, not a reason to abandon D1 for ordinary tables.

R2

What it does. Object storage for unstructured data: uploads, originals, exports. Public internet egress is not priced like typical cloud object storage, which matters when people download documents. That property does not make R2 a database.

When we use it. Invoice PDFs, a member handbook, a generated CSV. The fields extracted from a file are rows in D1 that point at the object.

When we do not. Not for relational queries, and not as a permission system. Knowing the object key is not the same as being allowed to read it. The Worker decides.

KV

What it does. A globally distributed key-value store for small values read from many places. A read can be slightly stale. It is the wrong tool when two writes must succeed or fail together.

When we use it. A feature flag, a cached lookup, a short-lived token check.

When we do not. Not for invoices, balances, or anything a report must total exactly. That data stays in D1.

Durable Objects

What it does. A single, consistent place for coordination. Each object runs the logic for one identity — a room, a tenant, a live document — and can keep SQLite beside that logic. Access is through Workers, not a general database login.

When we use it. Presence, a live session, a counter or a lock that cannot be “almost right”.

When we do not. Not as the default database. Lists, filters and reports stay in D1, which is the managed database with migrations and external tooling. Durable Objects are a building block, and they cost more engineering than a table.

Queues

What it does. A buffer between the request and work that can finish later. Delivery is not exactly once, so the consumer has to tolerate a repeat.

When we use it. Sending mail, calling a slow partner API, smoothing a burst of uploads.

When we do not. Not for a process that waits on a person for days and must remember the step it was on. That is a Workflow.

Workflows

What it does. Durable execution. A workflow is steps with retries, sleeps of seconds or days, and waits for an external event such as a person pressing approve. The instance survives the Worker that started it.

When we use it. Approvals, document pipelines, and any multi-stage business process that must resume after a failure.

When we do not. Not for a single read while a page loads. Wrapping a simple query in a workflow adds a concept and no resilience.

Workers AI

What it does. Model inference on Cloudflare’s network, called from a Worker or over the API. The catalogue of hosted models changes. A feature should depend on the task, not on a brand name in the interface.

When we use it. Classification, extraction, a short summary, an embedding, when the input and the allowed output are defined.

When we do not. Not on every request. Not when a SQL predicate already answers the question. Another provider remains an option. See AI application development for how that choice is governed.

Vectorize

What it does. A vector database for embeddings. Queries return nearby items, which is what semantic search and retrieval need.

When we use it. “Find the handbook passage this question is about”, over a corpus the organisation owns.

When we do not. Not as the source of truth for money, membership or permissions. Those stay in D1, and the Worker checks them before it trusts a nearest-neighbour result.

AI Gateway

What it does. A control point in front of model calls: logging, caching, rate limits, retries and fallback. Workers AI and supported external providers can be called through the same account path, so the application is not welded to one vendor’s SDK.

When we use it. When model calls are frequent enough that failures, latency and spend need to be seen, or when more than one provider is in play.

When we do not. An application with no model call does not gain anything from a gateway. A single, rare, pinned call may not need one either.

What this architecture changes for the business

Deployment is a Worker release and a migration, reviewed like any other change. There is no machine image to bake before a small fix can ship. New capacity is a property of the platform rather than a rack that has to be ordered first. Incremental work fits, because the next feature is another route and, only if needed, another binding.

Operational load shifts from patching servers to watching the application: errors, slow queries, queue depth, workflow instances, and model calls. Security at the edge — TLS, and the platform’s abuse controls — sits in front of the code. Application authorisation still has to be written. Infrastructure is declared with the project, so an environment can be read and reproduced.

None of that is a promise about a percentage of cost or a latency number. Those depend on the workload. A design that sprinkles every service into a small tool will be harder to operate, not easier.

When this platform is the wrong centre

A workload that is mostly large analytical queries, a product that must run inside a customer’s private network beside a specific appliance, or a system whose vendor only supports a traditional server will not be improved by forcing it into Workers. PrimeLabs will say so. The web application still has to fit the constraint. The platform does not outrank the job.

Deeper notes, not yet separate pages

Workers, D1, R2, Durable Objects, Workflows, Workers AI and Vectorize will each get a page when there is enough to say beyond the rules above. Those URLs are reserved and are not linked, because the pages do not exist. The homepage stack remains the short map.

Questions about the platform

Do you resell Cloudflare, or manage an existing account as the whole engagement?

No. The engagement is the application. Cloudflare is the platform it runs on. Account administration that is not part of building the product is out of scope.

Will every project include AI services?

No. Workers AI, Vectorize and AI Gateway appear when the feature needs them. A straightforward portal does not gain a vector index for decoration.

Can environments be separated?

Yes. Staging and production are different deployments. A change is reviewed before it is promoted. The example states on this page are labelled so they are not mistaken for a live tenant.

Discuss an application