Skip to content
MNPPI Architecture
MNPPI on GitHub

Adoption checklist

Status
Current
Reviewed
July 23, 2026
Cadence
Review after each platform change

Use this checklist before the first production deployment. Repeat the relevant steps when a project changes its risk or application profile.

  1. Select the application profile.

    Choose the smallest profile that supports the project. Record any high-risk data or action.

  2. Create the repository controls.

    Enable the organization standards that apply to the repository. Configure one stable required check for the default branch. Keep required pull request approvals at zero for a sole-owner repository.

  3. Create the continuous integration checks.

    Run format, lint, type, test, package, and policy checks as applicable. Route self-hosted jobs to the designated runner group.

  4. Configure the Cloudflare project.

    Connect Workers Builds to the repository. Use the default branch for production. Use preview builds for proposed changes.

  5. Apply the platform baseline.

    Use Static Assets for files that need no Worker code. Add Worker routes only for dynamic paths. Use bindings for Cloudflare services.

  6. Add data and security controls.

    Use Drizzle for D1 access. Enforce authentication and authorization at the server boundary. Keep secret values outside the repository.

  7. Set operating limits.

    Define the useful latency, error, CPU, bundle, and cost limits. Add alerts only when an owner can act on them.

  8. Test release and recovery.

    Verify the production build. Test rollback or roll-forward steps. Test database recovery separately from code recovery.

  9. Record the result.

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

Completion gate

Section titled “Completion gate”

A project can enter production when:

  • All required GitHub checks pass.
  • The owner can merge without an approval deadlock.
  • Cloudflare can build the default branch without a GitHub deployment token.
  • Production configuration uses bindings and protected secrets.
  • The owner can detect a failed release.
  • The owner can recover the application and its data.