Skip to content
MNPPI on GitHub

Application profiles

Status
Current
Reviewed
July 24, 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 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.

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

  • Start with Static Assets.
  • 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.