Can cf replace Wrangler?

Keep Wrangler for now; test a smaller switch

The new tool is cf, also installed as cloudflare. Cloudflare announced its open beta on 28 September 2026. It reaches across the Cloudflare API and is intended to succeed Wrangler. The announced maintenance window for Wrangler is eighteen months after the beta ends, so the announcement does not establish a fixed retirement date. Launch announcement · Installation and command names.

Our recommendation: evaluate cf as a deployer of verified artifacts first. Keep the existing local authoring and database workflow until a trial proves equivalent behavior. Replacing the command at the end of a release is a smaller change than replacing the preview runtime, storage adapter, bundler, and deployment tool together.

Commands, configuration, and Build Output can change during beta. Pinning a tested version would be part of adopting it. Beta status.

Cloudflare documents cf deploy --prebuilt for deploying existing Build Output. That makes it a plausible fit for a reviewed release directory. It is not a drop-in reader of our existing release format; producing and verifying the new artifact would be part of the migration. Build once, then deploy.

Local D1 is the first thing to protect

Saved writing must remain in one authoritative local database. A new tool opening an empty database would look like lost work; two tools writing different databases would be worse, because both could appear to work.

cf resource commands generally target remote resources. Local D1 operations use explicit --local; the documented SQL command is cf d1 raw, not cf d1 query. Local migration list/apply commands are supported. By default, local resource commands share a machine-wide state directory, while the Vite development server uses separate project state. An explicit --persist-to overrides the CLI location. Local resource data.

Open question: can the chosen runtime, CLI operations, and preview adapter demonstrably address the same database? Similar directory names are not proof. A trial must write a synthetic record through the editor, read it through the CLI, restart both, and repeat the check in the other direction.

Backups and initialization need their own proof. Cloudflare's D1 guide documents SQL import through wrangler d1 execute --file and SQL export through wrangler d1 export. The inspected cf command registry does not register equivalent import/export commands. That does not rule out lower-level API access, but it leaves a workflow gap to resolve before removing Wrangler. D1 import/export · D1 command registry at 4639bc0.

Database commands use IDs. Review migration directory, pattern, and table options explicitly: cf migrate does not carry those D1 settings across. D1 configuration mapping.

Our preview's use of getPlatformProxy is another independent requirement. An open upstream issue asks about programmatic API support; it is a user's report, not a maintainer promise. Retaining the working library is simpler than adding subprocess adapters just to claim we removed a dependency. API support question, #109.

The release directory remains our boundary

These are application requirements, regardless of which Cloudflare tool uploads the result:

Working references, editor stash, credentials, and local backups are excluded from release artifacts regardless of the associated article's visibility.

1. Only me / draft: exclude the writing and its exclusive media from everything sent for hosting.
2. Invited members: keep shared writing in hosted D1, reached through authenticated Worker routes. Its protected media must pass the same access decision. It must not become a public static file.
3. Public: allow public writing and approved assets, while keeping credentials and membership records out of the public directory.
4. Existing hosted edits: a code update must preserve them. Database initialization and later content migrations remain separate, deliberate operations.

The proposed cf sequence would therefore be:

select approved writing and media
→ assemble release files
→ produce Cloudflare Build Output
→ inspect the final files, modules, routes, bindings, and database input
→ verify privacy and record hashes
→ validate the prebuilt output without credentials
→ after release approval, verify again and upload that same output

Cloudflare's prebuilt CI workflow is useful machinery for the last steps. Its artifact validation does not know which of our records are drafts or who may read them. Our privacy checker must inspect the final Build Output as well as the approved database input, including module contents and the complete public-file list. Prebuilt CI workflow.

Two defaults deserve explicit tests. cf does not run extra steps in a package's build script automatically, and deployment can create missing bound resources when identifiers are omitted. Our wrapper must call the privacy checks itself, require reviewed database identifiers, and reject unexpected resources or modes. Build and deployment behavior.

We must also verify the translated settings for Worker-first asset handling, protected binary modules, logging, rate limits, and preview exposure. TypeScript configuration is executable code, so it belongs in code review; it is not a replacement for checking the resulting release.

There are two different kinds of credentials

CLI credentials let a developer or release job operate a Cloudflare account. cf auth login uses its own login; it does not reuse Wrangler's. It supports a browser approval flow, including --no-browser for approval on another device. Automation can use CLOUDFLARE_API_TOKEN and an explicit account ID. Sign-in and credential selection.

Application secrets let the deployed Worker perform site login and sign sessions. They remain separate from CLI credentials, public configuration, and public assets. Changing the deployment CLI should not change who counts as the owner or an invited reader.

The beta's --secrets-file option accompanies a version upload; it is not a reason to place secrets in the release artifact. If adopted, the release job would supply a separate, short-lived file outside that artifact. We would test preservation and rotation of existing secrets independently. Secret-update options.

Pin the tool version, select the account explicitly, and give credentials only to the stage that needs remote access. The official CI guide supports this separation. A changed command's JSON response or exit status also needs a tested parser: the guide notes that an aborted destructive command can exit successfully. CI and non-interactive behavior.

A bounded trial, with a clear decision

The next experiment can answer the difficult questions without using real writing or deploying a site.

1. Isolate. Use a clean disposable checkout and synthetic public, members-only, and draft records. Pin cf and compatible build dependencies. Its documented Node requirement is 22.18 or later. Requirements.
2. Inspect migration. Preview the explicit configuration path, then review an actual migration in the disposable copy. Keep the existing bundler for this first experiment. Record every changed file, generated setting, and unresolved item.
3. Prove storage continuity. Exercise editor/CLI reads and writes against the same isolated D1, restart, export, restore, and compare. Check migration failure handling. Until this passes, retain the current preview and backup path.
4. Attack the release boundary. Put distinctive canary strings in draft bodies, filenames, references, stash entries, and private media. Require their absence from the whole upload set. Tamper with an approved file and require the verifier to stop.
5. Check the access matrix. Public visitors, invited readers, the owner, and revoked members must get the same results for pages, APIs, media, and editor actions. Check the compiled release locally, not just the source server.
6. Measure the maintenance cost. Compare commands, adapters, configuration files, and dependencies after the experiment. Adopt cf for deployment only if it simplifies the reviewed release path. Remove Wrangler entirely only when its remaining library and database uses have supported replacements.

A future remote trial would separately verify resource selection, secret delivery, real sign-in, and preservation of hosted edits. This note does not claim those checks have happened.

Sources and evidence limits

Official docs were checked on 5 October 2026; the CLI is still in beta. Product behavior above is documented behavior, not the result of executing a migration. The release requirements and adoption criteria are our engineering judgment.

• Cloudflare's launch announcement — 28 September 2026; direction and maintenance policy.
• For Wrangler users — migration boundary and automatic-configuration warning.
• Migration procedure and command/configuration mapping — bundlers, settings, and known gaps.
• Develop, build, and deploy — prebuilt output, modes, and local-state semantics.
• Install and authenticate and CI guidance — credential boundaries, pinning, and unattended behavior.
• D1 import/export, the D1 command registry at 4639bc0, and Wrangler's programmatic API — remaining workflow dependencies.
• Upstream issue #109 — a user-raised API-parity question, not a guaranteed roadmap.