Skip to content

Inferred targets

For every project with a Wrangler config, the plugin infers a set of Nx targets that shell out to the Wrangler CLI. Target names are configurable — see Plugin options.

Forward flags to the underlying Wrangler command after --:

bunx nx <target> <my-worker> -- --some-wrangler-flag

serve

Section titled “serve”

Runs wrangler dev from the project root, starting a continuous local development server for the Worker.

  • Command: wrangler dev
  • Continuous: yes
  • Ready signal: ready when Wrangler prints Ready on http://..., so dependent tasks wait for the server to be listening.

The dev server port is set via dev.port in the Wrangler config and defaults to 8787.

bunx nx serve <my-worker> -- --remote
bunx nx serve <my-worker> -- --ip 0.0.0.0

See the wrangler dev CLI docs.

deploy

Section titled “deploy”

Runs wrangler deploy from the project root, publishing the Worker to Cloudflare’s edge network.

  • Command: wrangler deploy
  • Continuous: no
bunx nx deploy <my-worker> -- --dry-run
bunx nx deploy <my-worker> -- --name my-custom-worker

See the wrangler deploy CLI docs.

typegen

Section titled “typegen”

Runs wrangler types from the project root, generating worker-configuration.d.ts — the typed Env interface and Workers runtime types derived from the Wrangler config.

  • Command: wrangler types
  • Continuous: no
  • Cached: yes
  • Inputs: project files, upstream project files, and the wrangler external dependency
  • Outputs: {projectRoot}/worker-configuration.d.ts

worker-configuration.d.ts is a generated artifact and is git-ignored. typegen is inferred only for Worker applications (projects with a Wrangler config); Worker libraries do not have one.

bunx nx typegen <my-worker> -- --name MyEnv

See the wrangler types CLI docs.

version-upload

Section titled “version-upload”

Runs wrangler versions upload from the project root, uploading a new version of the Worker to Cloudflare’s Versions API. This is the foundation for gradual deployments — rolling out new versions incrementally and rolling back instantly.

  • Command: wrangler versions upload
  • Continuous: no
bunx nx version-upload <my-worker> -- --message "fix: update handler"

See the Wrangler versions docs.

tail

Section titled “tail”

Runs wrangler tail from the project root, streaming live logs from a deployed Worker in real time. For local development, use serve instead and read the terminal output directly.

  • Command: wrangler tail
  • Continuous: yes
bunx nx tail <my-worker> -- --status error
bunx nx tail <my-worker> -- --format json

See the wrangler tail CLI docs.

D1 migration targets

Section titled “D1 migration targets”

D1 migration targets are inferred only for jsonc/json Wrangler configs (not TOML — there is no TOML parser in the plugin). One set of targets is emitted per d1_databases binding. With a single binding the targets use bare names (d1-apply, d1-create, d1-list); when a Worker has multiple D1 bindings the binding name is appended as a suffix (d1-apply-DB, d1-apply-ANALYTICS, etc.).

d1-apply

Section titled “d1-apply”

Runs wrangler d1 migrations apply <database>. Applies pending migrations to the local database by default; pass --remote for production. Accepts --env <environment>.

bunx nx d1-apply <my-worker>           # apply locally (default)
bunx nx d1-apply <my-worker> --remote  # apply to the remote database

See the wrangler d1 migrations apply CLI docs.

d1-create

Section titled “d1-create”

Runs wrangler d1 migrations create <database> <message>. Scaffolds a new migration file. Requires --message.

bunx nx d1-create <my-worker> --message=add_users

See the wrangler d1 migrations create CLI docs.

d1-list

Section titled “d1-list”

Runs wrangler d1 migrations list <database>. Lists applied and pending migrations. Uses the local database by default; pass --remote for production. Accepts --env <environment>.

bunx nx d1-list <my-worker>            # list local migrations
bunx nx d1-list <my-worker> --remote   # list remote migrations

See the wrangler d1 migrations list CLI docs.

Secret targets

Section titled “Secret targets”

Secret targets are emitted for every Worker — secrets are not declared in the Wrangler config so no config parsing is needed. Secret values are never passed as arguments. All targets accept --env <environment>.

secret-put

Section titled “secret-put”

Runs wrangler secret put <name>. Prompts interactively for the secret value; requires --name.

bunx nx secret-put <my-worker> --name=API_KEY

See the wrangler secret put CLI docs.

secret-bulk

Section titled “secret-bulk”

Runs wrangler secret bulk <file>. Uploads multiple secrets from a JSON file; requires --file=<path>. Do not commit that file to source control.

bunx nx secret-bulk <my-worker> --file=secrets.json

See the wrangler secret bulk CLI docs.

secret-list

Section titled “secret-list”

Runs wrangler secret list. Lists all secrets bound to the Worker.

bunx nx secret-list <my-worker>

See the wrangler secret list CLI docs.

secret-delete

Section titled “secret-delete”

Runs wrangler secret delete <name>. Deletes a secret; requires --name.

bunx nx secret-delete <my-worker> --name=API_KEY

See the wrangler secret delete CLI docs.

Section titled “Related”