Skip to content
MNPPI Architecture
MNPPI on GitHub

Adoption checklist

Status
Current
Reviewed
October 22, 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. Assign organization repository properties, including security_baseline. For a private shared-private or custom-equivalent repo, Grok or Standards grants Read under @mnppi/quality → Manage Actions access → Add repository in the signed-in box browser before the first required private quality run. GitHub has no public API for that list. Do not add a PACKAGES_TOKEN secret. Add AGENTS.md and .cursor/environment.json per the coding agents standard. That site is the operating source of truth. Default to it before inventing. If the repository sends transactional, ops, or notify HTML email, depend on @mnppi/email-layout and BRAND_PRESETS, and name that package in AGENTS.md. Use BRAND_PRESETS.mnppi for notify.mnppi.org and other MNPPI ops alerts. CID-embed logos by default (getCloudflareLogoAttachment / LOGO_CID); remote logoUrl is fallback only when no embedded PNG. Cloudflare Email Sending only. No Resend. No one-off HTML email shells.

  3. Configure CI.

    Run format, lint, typecheck, tests, package, and policy checks as they apply. For a Worker app, include a production build and cf:check. Point cf:check at cf deploy --dry-run only when BOS exists; otherwise wrangler deploy --dry-run. Pin Node.js ≥ 22 wherever cf runs. 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. When that Worker installs @mnppi/*, preview Builds env must match prod Packages auth. See docs/private-package-distribution.md. Vite-ready Workers with a Worker entry use cf CLI, Vite, @cloudflare/vite-plugin, and typed cloudflare.config.ts when the build produces BOS. Assets-only Astro keeps labeled transitional wrangler.jsonc. See cf CLI and cloudflare.config.ts. Pin Vite, Astro, React, Vitest, TypeScript, Node.js, pnpm, and Wrangler to the supported major. New repositories and templates must start on Standard. Do not start a new repository on an older major without a recorded exception in supported-majors.json. Do not delete wrangler.jsonc or flip Workers Builds to wrangler --experimental-new-config.

  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. Send transactional, ops, and notify HTML email through Cloudflare Email Sending and @mnppi/email-layout. CID-embed logos by default. Do not add Resend.

  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.