Cloudflare App Bootstrap

Take the project from its current state to a working local request that exercises the requested application behavior. Preserve the user's framework, package manager, CLI, and existing services. Read the relevant current documentation before choosing configuration or commands, and check support against installed versions with local CLI help and schemas.

Start from the project

Inspect the app directory, lockfile, scripts, framework and adapter versions, Cloudflare configuration (cloudflare.config.ts, or a Wrangler configuration file), and existing setup instructions. In a monorepo, identify the application root before installing or generating files. Install from the existing lockfile and reuse the project's dependency and configuration conventions.

If the project has no Cloudflare configuration yet, set it up first with the frameworks-on-cloudflare skill for a framework app, or the cf-cli skill otherwise. Identify the source of any framework-generated configuration and edit that source. Do not replace a working app with a starter to resolve a configuration problem.

Connect only the resources the app needs

Identify each binding used by application code and map it to an existing resource or a new local resource. Keep names consistent across code and configuration. Keep existing resource identifiers: a binding without one is treated as a new resource to provision on the next deploy.

Read automatic provisioning before manually creating supported resources, and check which resource types it covers. Provisioning differs by CLI:

• Wrangler: wrangler dev creates local resources that persist between runs, and wrangler deploy creates remote resources and writes their identifiers back to the configuration file.
• cf: cf deploy provisions missing resources but does not write identifiers back to cloudflare.config.ts (Develop, build, and deploy). Record the identifiers it reports in the configuration.