Skip to content
MNPPI Architecture
MNPPI on GitHub

Adoption checklist

Status
Current
Reviewed
August 17, 2026
Cadence
Review after each platform change

Use this checklist before the first production deploy of a Cloudflare app. Repeat the relevant steps when risk, data, or profile changes.

  1. Select the application profile.

    Choose the smallest profile that fits the product. A static docs site does not need Queues. A payment path is high-risk even when the rest of the app is not. Record high-risk data or actions.

  2. Configure repository controls.

    Enable the organization standards that apply. Require one stable check on the default branch, such as CI / quality. Keep required approvals at zero for a sole-owner repository. Allow auto-merge and enable squash auto-merge when a pull request opens.

  3. Configure CI.

    Run format, lint, typecheck, tests, package, and policy checks as they apply. For a Worker app, include a production build and wrangler deploy --dry-run. Route self-hosted jobs to the designated runner group and leave them in queue.

  4. Configure the Cloudflare project.

    Connect Workers Builds to the repository. Use the default branch for production. Enable preview builds for pull requests when you need them.

  5. Apply the platform baseline.

    Serve HTML, JS, CSS, and fonts with Static Assets when no server code is required. Bind Worker routes only for dynamic paths such as /api/* or auth callbacks. Use bindings for D1, R2, KV, Queues, and other Cloudflare services.

  6. Add data and security controls.

    Access D1 only through a Drizzle database package. Enforce authz in the Worker, not only at the edge. Keep secrets in Cloudflare secrets and local Keychain wiring, not in git.

  7. Set operating limits.

    Define latency, error, CPU, bundle, and cost limits you will watch. Add alerts only when a named owner will respond.

  8. Test release and recovery.

    Verify the production build path end to end. Test Worker rollback or roll-forward. Test D1 recovery separately. Rolling back code does not undo a migration.

  9. Record the result.

    Link the profile, required controls, numeric limits, and exceptions. Set the next review date.

Production gate

Section titled “Production gate”

A project may enter production when:

  • All required GitHub checks pass.
  • The owner can enable squash auto-merge without an approval deadlock.
  • Cloudflare builds the default branch without a GitHub deploy token.
  • Production uses bindings and protected secrets.
  • The owner can detect a failed release from health or error signals.
  • The owner can recover the app and its data.