Cloudflare Docs
Workers
Cloudflare Docs
Workers
GitHub icon
Visit Workers on GitHub
Set theme to dark (⇧+D)
  1. Products
  2. Workers
  3. Wrangler
  4. Commands

Wrangler commands

Wrangler offers a number of commands to manage your Cloudflare Workers.

  • docs - Open this page in your default browser.
  • init - Create a skeleton Wrangler project, including the wrangler.toml file.
  • generate - Create a Wrangler project using an existing Workers template.
  • d1 - Interact with D1.
  • dev - Start a local server for developing your Worker.
  • publish - Publish your Worker to Cloudflare.
  • delete - Delete your Worker from Cloudflare.
  • kv:namespace - Manage Workers KV namespaces.
  • kv:key - Manage key-value pairs within a Workers KV namespace.
  • kv:bulk - Manage multiple key-value pairs within a Workers KV namespace in batches.
  • r2 bucket - Manage Workers R2 buckets.
  • r2 object - Manage Workers R2 objects.
  • secret - Manage the secret variables for a Worker.
  • secret:bulk - Manage multiple secret variables for a Worker.
  • tail - Start a session to livestream logs from a deployed Worker.
  • pages - Configure Cloudflare Pages.
  • login - Authorize Wrangler with your Cloudflare account using OAuth.
  • logout - Remove Wrangler’s authorization for accessing your account.
  • whoami - Retrieve your user information and test your authentication configuration.
  • deployments - Retrieve details for recent deployments.
  • rollback - Rollback to a recent deployment.
  • dispatch-namespace - Interact with a dispatch namespace.
  • mtls-certificate - Manage certificates used for mTLS connections.
  • types - Generate types from bindings and module rules in configuration.

​​ docs

Open the Cloudflare developer documentation in your default browser.

$ wrangler docs [COMMAND]
  • COMMAND string optional
    • The Wrangler command you want to learn more about. This opens your default browser to the section of the documentation that describes the command.

​​ init

Create a skeleton Wrangler project, including the wrangler.toml file.

$ wrangler init [NAME] [-y / --yes] [--from-dash]
  • NAME string optional (default: name of working directory)
    • The name of the Workers project. This is both the directory name and name property in the generated wrangler.toml configuration file.
  • --yes boolean optional
    • Answer yes to any prompts for new projects.
  • --from-dash string optional
    • Fetch a Worker initialized from the dashboard. This is done by passing the flag and the Worker name. wrangler init --from-dash <WORKER_NAME>
    • The --from-dash command will not automatically sync changes made to the dashboard after the command is used. Therefore, it is recommended that you continue using the CLI.

​​ generate

Create a Wrangler project using an existing Workers template.

$ wrangler generate [name] [template]

​​ d1

Interact with Cloudflare’s D1 service.

​​ create

Creates a new D1 database, and provides the binding and UUID that you will put in your wrangler.toml file.

$ wrangler d1 create <DATABASE_NAME>
  • DATABASE_NAME string required
    • The name of the new D1 database.

​​ list

List all D1 databases in your account.

$ wrangler d1 list

​​ delete

Delete a D1 database.

$ wrangler d1 delete <DATABASE_NAME>
  • DATABASE_NAME string required
    • The name of the D1 database to delete.

​​ execute

Execute a query on a D1 database.

$ wrangler d1 execute <DATABASE_NAME> [OPTIONS]
  • DATABASE_NAME string required
    • The name of the D1 database to execute a query on.
  • --command string
    • The SQL query you wish to execute.
  • --file string
    • Path to the SQL file you wish to execute.
  • Note that you must provide either --command or --file for this command to run successfully.

​​ backup create

Initiate a D1 backup.

$ wrangler d1 backup create <DATABASE_NAME>
  • DATABASE_NAME string required
    • The name of the D1 database to backup.

​​ backup list

List all available backups.

$ wrangler d1 backup list <DATABASE_NAME>
  • DATABASE_NAME string required
    • The name of the D1 database to list the backups of.

​​ backup restore

Restore a backup into a D1 database.

$ wrangler d1 backup restore <DATABASE_NAME> <BACKUP_ID>
  • DATABASE_NAME string required
    • The name of the D1 database to restore the backup into.
  • BACKUP_ID string required
    • The ID of the backup you wish to restore.

​​ backup download

Download existing data to your local machine.

$ wrangler d1 backup download <DATABASE_NAME> <BACKUP_ID>
  • DATABASE_NAME string required
    • The name of the D1 database you wish to download the backup of.
  • BACKUP_ID string required
    • The ID of the backup you wish to download.

​​ migrations create

Create a new migration.

This will generate a new versioned file inside the migrations folder. Name your migration file as a description of your change. This will make it easier for you to find your migration in the migrations folder. An example filename looks like:

0000_create_user_table.sql

The filename will include a version number and the migration name you specify below.

$ wrangler d1 migrations create <DATABASE_NAME> "<MIGRATION_NAME>"
  • DATABASE_NAME string required
    • The name of the D1 database you wish to create a migration for.
  • MIGRATION_NAME string required
    • A descriptive name for the migration you wish to create.

​​ migrations list

View a list of unapplied migration files.

$ wrangler d1 migrations list <DATABASE_NAME> [OPTIONS]
  • DATABASE_NAME string required
    • The name of the D1 database you wish to list unapplied migrations for.
  • --local boolean
    • Show the list of unapplied migration files on your locally persisted D1 database.

​​ migrations apply

Apply any unapplied migrations.

This command will prompt you to confirm the migrations you are about to apply. Confirm that you would like to proceed. After, a backup will be captured.

The progress of each migration will be printed in the console.

When running the apply command in a CI/CD environment or another non-interactive command line, the confirmation step will be skipped, but the backup will still be captured.

If applying a migration results in an error, this migration will be rolled back, and the previous successful migration will remain applied.

$ wrangler d1 migrations apply <DATABASE_NAME> [OPTIONS]
  • DATABASE_NAME string required
    • The name of the D1 database you wish to apply your migrations on.
  • --local boolean
    • Execute any unapplied migrations on your locally persisted D1 database.

​​ dev

Start a local server for developing your Worker.

$ wrangler dev [SCRIPT] [OPTIONS]

  • SCRIPT string

    • The path to an entry point for your Worker.

  • --name string

    • Name of the Worker.

  • --no-bundle boolean (default: false)

    • Skip Wrangler’s build steps and show a preview of the script without modification. Particularly useful when using custom builds.

  • --env string

    • Perform on a specific environment.

  • --compatibility-date string

    • A date in the form yyyy-mm-dd, which will be used to determine which version of the Workers runtime is used.

  • --compatibility-flags, --compatibility-flag boolean[]

    • Flags to use for compatibility checks.

  • --latest boolean (default: true)

    • Use the latest version of the Workers runtime.

  • --ip string

    • IP address to listen on, defaults to localhost.

  • --port number

    • Port to listen on.

  • --inspector-port number

    • Port for devtools to connect to.

  • --routes, --route string[]

    • Routes to upload.
    • For example: --route example.com/*.

  • --host string

    • Host to forward requests to, defaults to the zone of project.

  • --local-protocol “http”|“https” (default: http)

    • Protocol to listen to requests on.

  • --local-upstream string

    • Host to act as origin in local mode, defaults to dev.host or route.

  • --assets string

    • Root folder of static assets to be served. Unlike --site, --assets does not require a Worker script to serve your assets.
    • Use in combination with --name and --latest for basic static file hosting. For example: wrangler dev --name personal_blog --assets dist/ --latest.

  • --site string

    • Root folder of static assets for Workers Sites.

  • --site-include string[]

    • Array of .gitignore-style patterns that match file or directory names from the sites directory. Only matched items will be uploaded.

  • --site-exclude string[]

    • Array of .gitignore-style patterns that match file or directory names from the sites directory. Matched items will not be uploaded.

  • --upstream-protocol “http”|“https” (default: https)

    • Protocol to forward requests to host on.

  • --var key:value[]

    • Array of key:value pairs to inject as variables into your code. The value will always be passed as a string to your Worker.
    • For example, --var git_hash:$(git rev-parse HEAD) test:123 makes the git_hash and test variables available in your Worker’s env.
    • This flag is an alternative to defining vars in your wrangler.toml. If defined in both places, this flag’s values will be used.

  • --define key:value[]

    • Array of key:value pairs to replace global identifiers in your code.
    • For example, --define GIT_HASH:$(git rev-parse HEAD) will replace all uses of GIT_HASH with the actual value at build time.
    • This flag is an alternative to defining define in your wrangler.toml. If defined in both places, this flag’s values will be used.

  • --tsconfig string

    • Path to a custom tsconfig.json file.

  • --local boolean (default: false)

    • Run the preview of the Worker directly on your local machine.
  • --experimental-local-remote-kv boolean (default: false)
    • This will write/read to/from your remote KV namespaces, as specified in wrangler.toml. Note this flag requires --experimental-local to be enabled.
  • --minify boolean
    • Minify the script.
  • --node-compat boolean
    • Enable node.js compatibility.
  • --persist boolean
    • Enable persistence for local mode, using default path: .wrangler/state.
  • --persist-to string
    • Specify directory to use for local persistence. Setting this flag implicitly enables --persist.
  • --test-scheduled boolean (default: false)
    • Exposes a /__scheduled fetch route which will trigger a scheduled event (cron trigger) for testing during development. To simulate different cron patterns, a cron query parameter can be passed in: /__scheduled?cron=*+*+*+*+*.
  • --log-level “debug”|“info”|“log”|“warn”|“error”|“none” (default: log)
    • Specify Wrangler’s logging level.

The wrangler dev command that establishes a connection between localhost and a Cloudflare server that hosts your Worker in development. This allows full access to Workers KV and Durable Objects. wrangler dev is a way to easily test your Worker while developing.



~/my-worker $ wrangler dev
⬣ Listening at http://localhost:8787
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ [b] open a browser, [d] open Devtools, [l] turn on local mode, [c] clear console, [x] to exit                        │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

With wrangler dev running, you can send HTTP requests to localhost:8787 and your Worker should execute as expected. You will also see console.log messages and exceptions appearing in your terminal.

​​ publish

Publish your Worker to Cloudflare.

$ wrangler publish [SCRIPT] [OPTIONS]
  • SCRIPT string
    • The path to an entry point for your Worker.
  • --name string
    • Name of the Worker.
  • --no-bundle boolean (default: false)
    • Skip Wrangler’s build steps and directly publish script without modification. Particularly useful when using custom builds.
  • --env string
    • Perform on a specific environment.
  • --outdir string
    • Path to directory where Wrangler will write the bundled Worker files.
  • --compatibility-date string
    • A date in the form yyyy-mm-dd, which will be used to determine which version of the Workers runtime is used.
  • --compatibility-flags, --compatibility-flag boolean[]
    • Flags to use for compatibility checks.
  • --latest boolean (default: true)
    • Use the latest version of the Workers runtime.
  • --assets string
    • Root folder of static assets to be served. Unlike --site, --assets does not require a Worker script to serve your assets.
    • Use in combination with --name and --latest for basic static file hosting. For example: wrangler publish --name personal_blog --assets dist/ --latest.
  • --site string
    • Root folder of static assets for Workers Sites.
  • --site-include string[]
    • Array of .gitignore-style patterns that match file or directory names from the sites directory. Only matched items will be uploaded.
  • --site-exclude string[]
    • Array of .gitignore-style patterns that match file or directory names from the sites directory. Matched items will not be uploaded.
  • --var key:value[]
    • Array of key:value pairs to inject as variables into your code. The value will always be passed as a string to your Worker.
    • For example, --var git_hash:$(git rev-parse HEAD) test:123 makes the git_hash and test variables available in your Worker’s env.
    • This flag is an alternative to defining vars in your wrangler.toml. If defined in both places, this flag’s values will be used.
  • --define key:value[]
    • Array of key:value pairs to replace global identifiers in your code.
    • For example, --define GIT_HASH:$(git rev-parse HEAD) will replace all uses of GIT_HASH with the actual value at build time.
    • This flag is an alternative to defining define in your wrangler.toml. If defined in both places, this flag’s values will be used.
  • --triggers, --schedule, --schedules string[]
  • --routes, --route string[]
    • Routes where this Worker will be published.
    • For example: --route example.com/*.
  • --tsconfig string
    • Path to a custom tsconfig.json file.
  • --minify boolean
    • Minify the bundled script before publishing.
  • --node-compat boolean
    • Enable node.js compatibility.
  • --dry-run boolean (default: false)
    • Compile a project without actually publishing to live servers. Combined with --outdir, this is also useful for testing the output of wrangler publish. It also gives developers a chance to upload our generated sourcemap to a service like Sentry, so that errors from the Worker can be mapped against source code, but before the service goes live.
  • --keep-vars boolean (default: false)
    • It is recommended best practice to treat your Wrangler developer environment as a source of truth for your Worker configuration, and avoid making changes via the Cloudflare dashboard.
    • If you change your environment variables or bindings in the Cloudflare dashboard, Wrangler will override them the next time you deploy. If you want to disable this behaviour set keep-vars to true.

​​ delete

Delete your Worker and all associated Cloudflare developer platform resources.

$ wrangler delete [SCRIPT] [OPTIONS]
  • SCRIPT string
    • The path to an entry point for your Worker.
  • --name string
    • Name of the Worker.
  • --env string
    • Perform on a specific environment.
  • --dry-run boolean (default: false)
    • Do not actually delete the Worker. This is useful for testing the output of wrangler delete.

​​ kv:namespace

Manage Workers KV namespaces.

​​ create

Create a new namespace.

$ wrangler kv:namespace create <NAMESPACE> [OPTIONS]
  • NAMESPACE string required
    • The name of the new namespace.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace (the preview_id value).

​​ list

List all KV namespaces associated with the current account ID.

$ wrangler kv:namespace list

​​ delete

Delete a given namespace.

$ wrangler kv:namespace delete [OPTIONS]
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.

​​ kv:key

Manage key-value pairs within a Workers KV namespace.

​​ put

Write a single key-value pair to a particular namespace.

$ wrangler kv:key put <KEY> [VALUE] [OPTIONS]
  • KEY string required
    • The key to write to.
  • VALUE string optional
    • The value to write.
  • --path optional
    • When defined, the value is loaded from the file at --path rather than reading it from the VALUE argument. This is ideal for security-sensitive operations because it avoids saving keys and values into your terminal history.
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.
  • --ttl number optional
    • The lifetime (in number of seconds) that the key-value pair should exist before expiring. Must be at least 60 seconds. This option takes precedence over the expiration option.
  • --expiration number optional
    • The timestamp, in UNIX seconds, indicating when the key-value pair should expire.
  • --metadata string optional
    • Any (escaped) JSON serialized arbitrary object to a maximum of 1024 bytes.

​​ list

Output a list of all keys in a given namespace.

$ wrangler kv:key list [OPTIONS]
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.
  • --prefix string optional
    • Only list keys that begin with the given prefix.

​​ get

Read a single value by key from the given namespace.

$ wrangler kv:key get <KEY> [OPTIONS]
  • KEY string required
    • The key value to get.
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.

​​ delete

Remove a single key value pair from the given namespace.

$ wrangler kv:key delete <KEY> [OPTIONS]
  • KEY string required
    • The key value to get.
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.

​​ kv:bulk

Manage multiple key-value pairs within a Workers KV namespace in batches.

​​ put

Write a JSON file containing an array of key-value pairs to the given namespace.

$ wrangler kv:bulk put <FILENAME> [OPTIONS]
  • FILENAME string required
    • The JSON file containing an array of key-value pairs to write to the namespace.
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.

This command takes a JSON file as an argument with a list of key-value pairs to upload. An example of JSON input:

[
  {
    "key": "test_key",
    "value": "test_value",
    "expiration_ttl": 3600
  }

]

KV namespace values can only store strings. In order to save complex a value, stringify it to JSON:

[
  {
    "key": "test_key",
    "value": "{\"name\": \"test_value\"}",
    "expiration_ttl": 3600
  }

]

Here is the full schema for key-value entries uploaded via the bulk API:

  • key string required
    • The key’s name. The name may be 512 bytes maximum. All printable, non-whitespace characters are valid.
  • value string required
    • The UTF-8 encoded string to be stored, up to 25 MB in length.
  • metadata object optional
    • Any arbitrary object (must serialize to JSON) to a maximum of 1024 bytes.
  • expiration number optional
    • The time, measured in number of seconds since the UNIX epoch, at which the key should expire.
  • expiration_ttl number optional
    • The number of seconds the document should exist before expiring. Must be at least 60 seconds.
  • base64 boolean optional
    • When true, the server will decode the value as base64 before storing it. This is useful for writing values that would otherwise be invalid JSON strings, such as images. Defaults to false.

​​ delete

Delete all keys read from a JSON file within a given namespace.

$ wrangler kv:bulk delete <FILENAME> [OPTIONS]
  • FILENAME string required
    • The JSON file containing an array of keys to delete from the namespace.
  • --binding string
    • The binding name of the namespace, as stored in the wrangler.toml file, to delete.
  • --namespace-id string
    • The ID of the namespace to delete.
  • --env string optional
    • Perform on a specific environment.
  • --preview boolean optional
    • Interact with a preview namespace instead of production.

This command takes a JSON file as an argument containing an array of keys to delete. Here is an example of the JSON input:

["test_key_1", "test_key_2"]

​​ r2 bucket

Interact with buckets in an R2 store.

​​ create

Create a new R2 bucket.

$ wrangler r2 bucket create <NAME>
  • NAME string required
    • The name of the new R2 bucket.

​​ delete

Delete an R2 bucket.

$ wrangler r2 bucket delete <NAME>
  • NAME string required
    • The name of the R2 bucket to delete.

​​ list

List R2 bucket in the current account.

$ wrangler r2 bucket list

​​ r2 object

Interact with R2 objects.

​​ get

Fetch an object from an R2 bucket.

$ wrangler r2 object get <OBJECTPATH>
  • OBJECTPATH string required
    • The source object path in the form of {bucket}/{key}.

​​ put

Create an object in an R2 bucket.

$ wrangler r2 object put <OBJECTPATH> [OPTIONS]
  • OBJECTPATH string required
    • The destination object path in the form of {bucket}/{key}.
  • --file string optional
    • The path of the file to upload. Note you must provide either --file or --pipe.
  • --pipe boolean optional
    • Enables the file to be piped in, rather than specified with the –file option. Note you must provide either --file or --pipe.
  • --content-type string optional
    • A standard MIME type describing the format of the object data.
  • --content-disposition string optional
    • Specifies presentational information for the object.
  • --content-encoding string optional
    • Specifies what content encodings have been applied to the object and thus what decoding mechanisms must be applied to obtain the media-type referenced by the Content-Type header field.
  • --content-language string optional
    • The language the content is in.
  • --cache-control string optional
    • Specifies caching behavior along the request/reply chain.
  • --expires string optional
    • The date and time at which the object is no longer cacheable.

​​ delete

Delete an object in an R2 bucket

$ wrangler r2 object delete <OBJECTPATH>
  • OBJECTPATH string required
    • The destination object path in the form of {bucket}/{key}.

​​ secret

Manage the secret variables for a Worker.

​​ put

Create or replace a secret for a Worker.

$ wrangler secret put <KEY> [OPTIONS]

  • KEY string required

    • The variable name for this secret to be accessed in the Worker.

  • --name string optional

    • Perform on a specific Worker script rather than inheriting from wrangler.toml.

  • --env string optional

    • Perform on a specific environment.

​​ delete

Delete a secret for a Worker.

$ wrangler secret delete <KEY> [OPTIONS]

  • KEY string required

    • The variable name for this secret to be accessed in the Worker.

  • --name string optional

    • Perform on a specific Worker script rather than inheriting from wrangler.toml.

  • --env string optional

    • Perform on a specific environment.

​​ list

List the names of all the secrets for a Worker.

$ wrangler secret list [OPTIONS]

  • --name string optional

    • Perform on a specific Worker script rather than inheriting from wrangler.toml.

  • --env string optional

    • Perform on a specific environment

​​ secret:bulk

Manage multiple secrets for a Worker.

​​ json

The path to a JSON file containing secrets in key-value pairs to upload.

$ wrangler secret:bulk <JSON> [OPTIONS]

  • JSON string required

    • The JSON file of key-value pairs to upload, in form {“key”: value, …}

  • --name string optional

    • Perform on a specific Worker script rather than inheriting from wrangler.toml.

  • --env string optional

    • Perform on a specific environment

​​ tail

Start a session to livestream logs from a deployed Worker.

$ wrangler tail <NAME> [OPTIONS]
  • NAME string required
  • --format “json”|“pretty” optional
    • The format of the log entries.
  • --status “ok”|“error”|“canceled” optional
    • Filter by invocation status.
  • --header string optional
    • Filter by HTTP header.
  • --method string optional
    • Filter by HTTP method.
  • --sampling-rate number optional
    • Add a fraction of requests to log sampling rate (between 0 and 1).
  • --search string optional
    • Filter by a text match in console.log messages.
  • --ip (string|“self”)[] optional
    • Filter by the IP address the request originates from. Use "self" to show only messages from your own IP.

After starting wrangler tail, you will receive a live feed of console and exception logs for each request your Worker receives.

If your Worker has a high volume of traffic, the tail might enter sampling mode. This will cause some of your messages to be dropped and a warning to appear in your tail logs. To prevent messages from being dropped, add the options listed above to filter the volume of tail messages.

If sampling persists after using options to filter messages, consider using instant logs.

​​ pages

Configure Cloudflare Pages.

​​ dev

Develop your full stack Pages application locally.

$ wrangler pages dev [<DIRECTORY>] [OPTIONS] [-- <COMMAND..>]
  • DIRECTORY string
    • The directory of static assets to serve.
  • COMMAND.. string
    • The proxy command(s) to run.
  • --local boolean (default: true)
    • Run on your local machine.
  • --port number (default: 8788)
    • The port to listen on (serve from).
  • --proxy number
    • The port to proxy (where the static assets are served).
  • --script-path string (default: “_worker.js”)
    • The location of the single Worker script if not using functions.
  • --binding string[]
    • Bind variable/secret (KEY=VALUE).
  • --kv string[]
    • KV namespace to bind.
  • --r2 string[]
  • --d1 string[]
  • --do string[]
    • Durable Object to bind (NAME=CLASS).
  • --live-reload boolean (default: false)
    • Auto reload HTML pages when change is detected.
  • --compatibility-flag string[]
    • Runtime compatibility flags to apply.
  • --compatibility-date string
    • Runtime compatibility date to apply.

​​ project list

List your Pages projects.

$ wrangler pages project list

​​ project create

Create a new Cloudflare Pages project.

$ wrangler pages project create [PROJECT-NAME] [OPTIONS]
  • PROJECT-NAME string
    • The name of your Pages project.
  • --production-branch string
    • The name of the production branch of your project.

​​ deployment list

List deployments in your Cloudflare Pages project.

$ wrangler pages deployment list [OPTIONS]
  • --project-name string
    • The name of the project you would like to list deployments for.

​​ deployment tail

Start a session to livestream logs from your deployed Pages Functions.

$ wrangler pages deployment tail [DEPLOYMENT] [OPTIONS]
  • DEPLOYMENT string optional
    • ID or URL of the deployment to tail. Specify by environment if deployment ID is unknown.
  • --project-name string optional
    • The name of the project you would like to tail.
  • --environment “production”|“preview” optional
    • When not providing a specific deployment ID, specifying environment will grab the latest production or preview deployment.
  • --format “json”|“pretty” optional
    • The format of the log entries.
  • --status “ok”|“error”|“canceled” optional
    • Filter by invocation status.
  • --header string optional
    • Filter by HTTP header.
  • --method string optional
    • Filter by HTTP method.
  • --sampling-rate number optional
    • Add a percentage of requests to log sampling rate.
  • --search string optional
    • Filter by a text match in console.log messages.
  • --ip (string|“self”)[] optional
    • Filter by the IP address the request originates from. Use "self" to show only messages from your own IP.

After starting wrangler pages deployment tail, you will receive a live stream of console and exception logs for each request your Functions receive.

​​ publish

Deploy a directory of static assets as a Pages deployment.

$ wrangler pages publish [DIRECTORY] [OPTIONS]
  • DIRECTORY string
    • The directory of static files to upload.
  • --project-name string
    • The name of the project you want to deploy to.
  • --branch string
    • The name of the branch you want to deploy to.
  • --commit-hash string
    • The SHA to attach to this deployment.
  • --commit-message string
    • The commit message to attach to this deployment.
  • --commit-dirty boolean
    • Whether or not the workspace should be considered dirty for this deployment.

​​ login

Authorize Wrangler with your Cloudflare account using OAuth. Wrangler will attempt to automatically open your web browser to login with your Cloudflare account.

If you prefer to use API tokens for authentication, such as in headless or continuous integration environments, refer to Running Wrangler in CI/CD.

$ wrangler login [OPTIONS]
  • --scopes-list string optional
    • List all the available OAuth scopes with descriptions.
  • --scopes $SCOPES string optional
    • Allows to choose your set of OAuth scopes. The set of scopes must be entered in a whitespace-separated list, for example, $ wrangler login --scopes account:read user:read.

If Wrangler fails to open a browser, you can copy and paste the URL generated by wrangler login in your terminal into a browser and log in.

​​ logout

Remove Wrangler’s authorization for accessing your account. This command will invalidate your current OAuth token.

$ wrangler logout

If you are using CLOUDFLARE_API_TOKEN instead of OAuth, and you can logout by deleting your API token in the Cloudflare dashboard:

  1. Log in to the Cloudflare dashboard.
  2. Go to Overview > Get your API token in the right-side menu.
  3. Select the three-dot menu on your Wrangler token.
  4. Select Delete.

​​ whoami

Retrieve your user information and test your authentication configuration.

$ wrangler whoami

​​ deployments

For more information about deployments and how they work, refer to Deployments.

​​ list

Retrieve details for the 10 most recent deployments. Details include Deployment ID, Created on, Author, Source, and an indication of which deployment is Active. Where applicable, details also include rollback information and a Message if one was provided on rollback.

$ wrangler deployments list
  • --name string optional
    • Perform on a specific Worker script rather than inheriting from wrangler.toml.

Example output:

Deployment ID:  y565f193-a6b9-4c7f-91ae-4b4e6d98ftbf
Created on:     2022-11-11T15:49:08.117218Z
Author:         example@cloudflare.com
Source:         Dashboard


Deployment ID:  91943f34-4802-4af7-a350-b5894c73ff34
Created on:     2022-11-11T15:50:08.117218Z
Author:         example@cloudflare.com
Source:         Dashboard


Deployment ID:  31d8f2f0-fba3-4ce9-8427-933f42541b56
Created on:     2022-11-11T15:51:08.117218Z
Author:         example@cloudflare.com
Source:         Rollback from Wrangler 🤠
Rollback from:  y565f193-a6b9-4c7f-91ae-4b4e6d98ftbf
Message:        This is a message submitted on rollback


Deployment ID:  7c2761da-5a45-4cb2-9448-a662978e3a59
Created on:     2022-11-11T15:52:08.117218Z
Author:         example@cloudflare.com
Source:         Rollback from Dashboard 🖥️
Rollback from:  31d8f2f0-fba3-4ce9-8427-933f42541b56


Deployment ID:  e81fe980-7622-6e1d-740b-1457de3e07e2
Created on:     2022-11-11T15:53:20.79936Z
Author:         example@cloudflare.com
Source:         Wrangler
🟩 Active

​​ view

Retrieve details for the specified deployment, or the latest if no ID is provided. Details include Deployment ID, Author, Source, Created on, and bindings. Where applicable, details also include rollback information and a Message if one was provided on rollback.

$ wrangler deployments view [DEPLOYMENT_ID]
  • DEPLOYMENT_ID string optional
    • The ID of the deployment you wish to view.
  • --name string optional
    • Perform on a specific Worker script rather than inheriting from wrangler.toml.

Example output:

Deployment ID:      07d7143d-0284-427e-ba22-2d5e6e91b479
Created on:         2023-03-02T21:05:15.622446Z
Author:             example@cloudflare.com
Source:             Upload from Wrangler 🤠
------------------------------------------------------------
Author ID:          e5a3ca86e08fb0940d3a05691310bb42
Usage Model:        bundled
Handlers:           fetch
Compatibility Date: 2022-10-03
--------------------------bindings--------------------------
[[r2_buckets]]
binding = "MY_BUCKET"
bucket_name = "testr2"


[[kv_namespaces]]
id = "79300c6d17eb4180a07270f450efe53f"
binding = "MY_KV"

​​ rollback

Rollback to a specified deployment by ID, or to the previous deployment if no ID is provided. The command will prompt you for confirmation of the rollback. On confirmation, you will be prompted to provide an optional message.

There are limitations on what deployments you can rollback to. Refer to Rollbacks in the Deployments documentation for more information.

$ wrangler rollback [DEPLOYMENT_ID]
  • DEPLOYMENT_ID string optional
    • The ID of the deployment you wish to view.
  • --message string optional
    • Add message for rollback. Accepts empty string. When specified, interactive prompts for rollback confirmation and message are skipped.

Example output:

🚧 `wrangler rollback` is a beta command. Please report any issues to https://github.com/cloudflare/workers-sdk/issues/new/choose
Successfully rolled back to deployment ID: e81fe980-7622-6e1d-740b-1457de3e07e2
Current Deployment ID: 04d22369-6e55-49ff-944a-d21e216d9f3e

​​ dispatch namespace

​​ list

List all dispatch namespaces.

$ wrangler dispatch-namespace list

​​ get

Get information about a dispatch namespace.

$ wrangler dispatch-namespace get <NAME>

  • NAME string required

    • The name of the dispatch namespace to get details about.

​​ create

Create a dispatch namespace.

$ wrangler dispatch-namespace create <NAME>

  • NAME string required

    • The name of the dispatch namespace to create.

​​ delete

Delete a dispatch namespace.

$ wrangler dispatch-namespace get <NAME>

  • NAME string required

    • The name of the dispatch namespace to delete.

​​ rename

Rename a dispatch namespace.

$ wrangler dispatch-namespace get <OLD-NAME> <NEW-NAME>

  • OLD NAME string required

    • The previous name of the dispatch namespace.

  • NEW NAME string required

    • The new name of the dispatch namespace.

​​ mtls-certificate

Manage client certificates used for mTLS connections in subrequests.

These certificates can be used in mtls_certificate bindings, which allow a Worker to present the certificate when establishing a connection with an origin that requires client authentication (mTLS).

​​ upload

Upload a client certificate.

$ wrangler mtls-certificate upload [OPTIONS]
  • --cert string required
    • A path to the TLS certificate to upload. Certificate chains are supported
  • --key string required
    • A path to the private key to upload.
  • --name string optional

​​ list

List mTLS certificates associated with the current account ID.

$ wrangler mtls-certificate list

​​ delete

$ wrangler mtls-certificate delete [OPTIONS]
  • --id string
    • The ID of the mTLS certificate.
  • --name string
    • The name assigned to the mTLS certificate at upload.
  • Note that you must provide either --id or --name for this command to run successfully.

​​ types

Generate types from bindings and module rules in configuration.

$ wrangler types