Application profiles

Status

Current

Reviewed

October 22, 2026

Cadence

Review with each new workload

Each project selects one primary profile. The profile decides which services and checks you need before production.

This is the choice you make when you scaffold a repo: static only, site plus a few Worker routes, full SPA, multi-Worker, background work, or higher risk.

Profile map

Profile	Typical composition	Use when
Static site	Astro and Static Assets	No dynamic server routes.
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 holds substantial client state.
Multi-Worker application	Multiple Workers and service bindings	Workloads need separate scale or trust boundaries.
Background processing	Worker, Queues, and Workflows as needed	Work continues outside an HTTP request.
Stateful application	Worker and Durable Objects	A named entity needs coordinated state.
High-risk application	A base profile with stricter controls	Money, regulated data, or destructive actions are in scope.

Common selections

Documentation

Use Astro with Static Assets. Add a Worker only when a feature needs server code, such as search or a form handler.

Product application

Use Astro or Vite for the UI. Use Hono for same-origin Worker APIs. Add D1 with Drizzle only when you need durable relational data.

Background system

Use Queues for buffered work such as email or webhook fan-out. When that email is transactional, ops, or notify HTML, render it with @mnppi/email-layout and BRAND_PRESETS. Use BRAND_PRESETS.mnppi for notify.mnppi.org and other MNPPI ops alerts. CID-embed logos by default; remote logoUrl is fallback only. Cloudflare Email Sending only. See Coding agents and Cloud Agent bootstrap. Use Workflows for multi-step jobs when durable retry state matters. Keep request handlers short. Move long work off the request path.

Coordinated state

Use Durable Objects when one object must serialize access, such as a room, lease, or counter. Do not use them as a default database for ordinary CRUD.

Selection rules

• Start with Static Assets.
• Use cf CLI, Vite, and cloudflare.config.ts for new Vite-ready Workers that have a Worker entry and produce BOS. Assets-only Astro stays on labeled transitional Wrangler. See cf CLI and cloudflare.config.ts.
• Start Vite, Astro, React, and the rest of the named toolchain on the supported major. New repositories and templates must start on Standard. An older major needs a recorded exception in supported-majors.json.
• Add a Worker only for dynamic work.
• Add one managed service for one clear need.
• Split Workers only when scale, ownership, or trust requires it.
• Treat high-risk status as an extra control layer on the base profile.
• Revisit the profile when the data model or trust boundary changes.