---
title: "Application profiles"
description: "Select the smallest Cloudflare application profile that supports the product and its operating risk."
url: "https://architecture.mnppi.org/architecture/application-profiles/"
status: "Current"
last_updated: "2026-07-23"
---

# Application profiles

**Standard details**

- Status: Current
- Reviewed: July 23, 2026
- Cadence: Review with each new workload

Each project must select one primary profile.
The profile controls which services and checks become necessary.

## Profile map

| Profile                  | Normal composition                             | Use it when                                                       |
| ------------------------ | ---------------------------------------------- | ----------------------------------------------------------------- |
| Static site              | Astro and Static Assets                        | The site has no dynamic server route.                             |
| Static site with APIs    | Static Assets, Worker, and Hono                | A small set of server routes supports the site.                   |
| Interactive application  | Vite or Astro, React, Worker, and APIs         | The browser has substantial client state.                         |
| Multi-Worker application | Multiple Workers and service bindings          | Workloads need separate scale or trust boundaries.                |
| Background processing    | Worker, Queues, and Workflows where applicable | Work continues outside an HTTP request.                           |
| Stateful application     | Worker and Durable Objects                     | A named entity needs coordinated state.                           |
| High-risk application    | A suitable profile with stricter controls      | The system handles money, regulated data, or destructive actions. |

## Common selections

### Documentation

Use Astro with Static Assets.
Add no Worker route unless a feature requires server code.

### Product application

Use Astro or Vite for the interface.
Use Hono for Worker application programming interfaces.
Add D1 with Drizzle only when durable relational data is necessary.

### Background system

Use Queues for buffered work.
Use Workflows for durable multi-step work when retry state matters.
Keep request handlers short.

### Coordinated state

Use Durable Objects when one object must serialize access to its state.
Do not use them as a default database replacement.

## Selection rules

- Start with Static Assets.
- Add a Worker only for dynamic work.
- Add one managed service for one clear need.
- Separate Workers only when scale, ownership, or trust requires it.
- Treat high-risk status as an added control layer.
- Review the profile when the data model or trust boundary changes.
