---
title: "Platform adoption"
description: "Adopt current Cloudflare services through measured pilots before they become part of the default MNPPI stack."
url: "https://architecture.mnppi.org/architecture/platform-adoption/"
status: "Current"
last_updated: "2026-07-23"
---

# Platform adoption

**Standard details**

- Status: Current
- Reviewed: July 23, 2026
- Cadence: Review each quarter

The standard should follow useful Cloudflare improvements.
It should not require a new service only because the service exists.

## Adoption test

A platform feature can become a default when:

- Cloudflare supports it for the intended production use.
- The feature removes code or operating work.
- The project can measure its value.
- The failure and recovery model is clear.
- The feature does not weaken the data or security contract.
- The reference application proves the integration.

## Adoption stages

1. **Watch.**

   Record the feature and its expected value.
   Do not put it in the default stack.

2. **Pilot.**

   Use one bounded reference workload.
   Define success, cost, and recovery checks before the pilot.

3. **Adopt.**

   Update the standard after the pilot passes.
   Add migration guidance only for projects that benefit.

4. **Retire.**

   Remove the service from the default when support or value declines.
   Keep recovery guidance for existing users.

## Current position

Static Assets and Workers Builds are part of the normal delivery model.
D1 read replication remains a measured pilot.
It needs a proven consistency model before it changes the Drizzle baseline.

Cloudflare Containers and the Sandbox Software Development Kit can support isolated workloads.
They are not a replacement for the designated GitHub runner policy.