Platform adoption

Status

Current

Reviewed

July 24, 2026

Cadence

Review each quarter

Adopt a Cloudflare feature when it reduces work or risk. Do not adopt it because it is new.

For a Worker app, that means you may pilot a beta in one reference workload. You do not make every production app depend on it until it proves out.

Adoption test

A feature can become a default when:

• Cloudflare supports it for the intended production use.
• It removes code or operating work.
• You can measure value in CPU, latency, errors, cost, or effort.
• Failure and recovery are clear.
• It does not weaken the data or security contract.
• The reference application proves the integration.

Adoption stages

1. Watch.

   Record the feature and the problem it might solve. Keep it out of the default stack.

2. Pilot.

   Run one reference workload, not every production app. Define success, cost, and recovery checks before the pilot starts.

3. Adopt.

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

4. Retire.

   Remove the service from the default when support or value declines. Keep recovery notes for projects that still run it.

Current position

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

Cloudflare Containers and the Sandbox SDK can isolate workloads. They do not replace the designated GitHub runner policy.