Documentation guide. Commands checked against Cloudflare’s official docs; no Worker preview or live deployment was run for this article.
Wrangler is Cloudflare's CLI for Workers and related services. A coding agent can use it to preview a Worker and build its code before a deployment.
This guide starts in an existing Worker project. It covers local development and a deployment build that doesn't upload the Worker.
Use the project's Wrangler installation
Open the Worker project and check its package file. Cloudflare recommends installing Wrangler in the project. Use the version recorded in its dependency and lock files.
npx wrangler --version
npx wrangler --help
Run these commands from the project directory. npx can download and execute a package if it isn't installed locally. If this is an existing project, install its recorded dependencies using the package manager it already uses.
For a new project, follow Cloudflare's getting started instructions. The commands here assume you already have Worker code and a Wrangler configuration.
Check the configuration before starting
Find wrangler.jsonc, wrangler.json or wrangler.toml in the project. Check which Worker it names and which entry point it uses. Also look at its bindings: these connect the Worker to services such as storage or databases.
Local development can still use remote bindings when the project configures them. Cloudflare explains this in its remote bindings guide. Check those before using a project with production resources.
Then start the development server:
npx wrangler dev
Open the address Wrangler prints. Try the route you changed and read the terminal output if it fails. Stop the server with Ctrl+C when you're done.
This is a development preview. It doesn't publish a new Worker deployment. The local development documentation explains where the code runs and how bindings behave.
Build without uploading the Worker
You can ask Wrangler to compile the project and write the build files into a directory:
npx wrangler deploy --dry-run --outdir dist
Run it in a working copy where dist is a suitable build output directory. The command writes files there. Review the output and any warnings before choosing a deployment command.
Cloudflare's Workers command reference documents both flags. --dry-run here belongs to deploy. It compiles the project without deploying it to Cloudflare's live servers. It is not a field-by-field plan of changes to remote resources.
A project can also define its own build steps. Read those scripts before running the build; the dry-run flag doesn't change what arbitrary project scripts do.
Give the agent a preview task
An agent with shell access can use the same commands you would run:
In this Worker project, inspect the Wrangler config
and package scripts. Tell me which bindings use
remote resources.
Use the project's installed Wrangler version.
Build with deploy --dry-run into a local output directory.
Report errors and the files it produced.
Ask before deploying or changing remote resources.
This is a prompt you can adapt, not a record of an agent execution. Name the working directory too if your agent works across several projects.
Deploy as a separate action
A real deployment uses:
npx wrangler deploy
That command changes Cloudflare. Confirm the Worker, account and intended environment before running it. Use Cloudflare's authentication instructions when login is needed; keep credentials out of prompts and copied terminal logs.
Wrangler is useful here because the preview and build commands can be repeated by you, a script or an agent. The CLI-first article explains that recommendation, and the tool guides show other examples.