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 thewrangler.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
- 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
- The name of the Workers project. This is both the directory name and
name
property in the generatedwrangler.toml
configuration file.
- The name of the Workers project. This is both the directory name and
--yes
boolean
- Answer yes to any prompts for new projects.
--from-dash
string
- 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.
- Fetch a Worker initialized from the dashboard. This is done by passing the flag and the Worker name.
generate
Create a Wrangler project using an existing Workers template.
$ wrangler generate [name] [template]
name
string
- The name of the Workers project. This is both the directory name and
name
property in the generatedwrangler.toml
configuration file.
- The name of the Workers project. This is both the directory name and
template
string
- The URL of a GitHub template, with a default worker-template. Browse a list of available templates on the cloudflare/workers-sdk repository.
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
- 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
- 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
- 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
- The name of the D1 database to backup.
backup list
List all available backups.
$ wrangler d1 backup list <DATABASE_NAME>
DATABASE_NAME
string
- 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
- The name of the D1 database to restore the backup into.
BACKUP_ID
string
- 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
- The name of the D1 database you wish to download the backup of.
BACKUP_ID
string
- 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
- The name of the D1 database you wish to create a migration for.
MIGRATION_NAME
string
- 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
- 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
- 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
- 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
- Use the latest version of the Workers runtime.
--ip
string
- IP address to listen on, defaults to
localhost
.
- IP address to listen on, defaults to
--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”
- Protocol to listen to requests on.
--local-upstream
string
- Host to act as origin in local mode, defaults to
dev.host
or route.
- Host to act as origin in local mode, defaults to
--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
.
- Root folder of static assets to be served. Unlike
--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.
- Array of
--site-exclude
string[]
- Array of
.gitignore
-style patterns that match file or directory names from the sites directory. Matched items will not be uploaded.
- Array of
--upstream-protocol
“http”|“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 thegit_hash
andtest
variables available in your Worker’senv
. - This flag is an alternative to defining
vars
in yourwrangler.toml
. If defined in both places, this flag’s values will be used.
- Array of
--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 ofGIT_HASH
with the actual value at build time. - This flag is an alternative to defining
define
in yourwrangler.toml
. If defined in both places, this flag’s values will be used.
- Array of
--tsconfig
string
- Path to a custom
tsconfig.json
file.
- Path to a custom
--local
boolean
- Run the preview of the Worker directly on your local machine.
--experimental-local
boolean
- Run the preview of the Worker directly on your local machine using the open source Cloudflare Workers runtime.
--experimental-local-remote-kv
boolean
- This will write/read to/from your remote KV namespaces, as specified in
wrangler.toml
. Note this flag requires--experimental-local
to be enabled.
- This will write/read to/from your remote KV namespaces, as specified in
--minify
boolean
- Minify the script.
--node-compat
boolean
- Enable node.js compatibility.
--persist
boolean
- Enable persistence for local mode, using default path:
.wrangler/state
.
- Enable persistence for local mode, using default path:
--persist-to
string
- Specify directory to use for local persistence. Setting this flag implicitly enables
--persist
.
- Specify directory to use for local persistence. Setting this flag implicitly enables
--test-scheduled
boolean
- Exposes a
/__scheduled
fetch route which will trigger a scheduled event (cron trigger) for testing during development. To simulate different cron patterns, acron
query parameter can be passed in:/__scheduled?cron=*+*+*+*+*
.
- Exposes a
--log-level
“debug”|“info”|“log”|“warn”|“error”|“none”
- 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
- 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
- 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
.
- Root folder of static assets to be served. Unlike
--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.
- Array of
--site-exclude
string[]
- Array of
.gitignore
-style patterns that match file or directory names from the sites directory. Matched items will not be uploaded.
- Array of
--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 thegit_hash
andtest
variables available in your Worker’senv
. - This flag is an alternative to defining
vars
in yourwrangler.toml
. If defined in both places, this flag’s values will be used.
- Array of
--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 ofGIT_HASH
with the actual value at build time. - This flag is an alternative to defining
define
in yourwrangler.toml
. If defined in both places, this flag’s values will be used.
- Array of
--triggers
,--schedule
,--schedules
string[]
- Cron schedules to attach to the published Worker. Refer to Cron Trigger Examples.
--routes
,--route
string[]
- Routes where this Worker will be published.
- For example:
--route example.com/*
.
--tsconfig
string
- Path to a custom
tsconfig.json
file.
- Path to a custom
--minify
boolean
- Minify the bundled script before publishing.
--node-compat
boolean
- Enable node.js compatibility.
--dry-run
boolean
- Compile a project without actually publishing to live servers. Combined with
--outdir
, this is also useful for testing the output ofwrangler 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.
- Compile a project without actually publishing to live servers. Combined with
--keep-vars
boolean
- 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
totrue
.
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
- Do not actually delete the Worker. This is useful for testing the output of
wrangler delete
.
- Do not actually delete the Worker. This is useful for testing the output of
kv:namespace
Manage Workers KV namespaces.
create
Create a new namespace.
$ wrangler kv:namespace create <NAMESPACE> [OPTIONS]
NAMESPACE
string
- The name of the new namespace.
--env
string
- Perform on a specific environment.
--preview
boolean
- Interact with a preview namespace (the
preview_id
value).
- Interact with a preview namespace (the
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.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- 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
- The key to write to.
VALUE
string
- The value to write.
--path
- When defined, the value is loaded from the file at
--path
rather than reading it from theVALUE
argument. This is ideal for security-sensitive operations because it avoids saving keys and values into your terminal history.
- When defined, the value is loaded from the file at
--binding
string
- The binding name of the namespace, as stored in the
wrangler.toml
file, to delete.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- Interact with a preview namespace instead of production.
--ttl
number
- 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 theexpiration
option.
- The lifetime (in number of seconds) that the key-value pair should exist before expiring. Must be at least
--expiration
number
- The timestamp, in UNIX seconds, indicating when the key-value pair should expire.
--metadata
string
- 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.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- Interact with a preview namespace instead of production.
--prefix
string
- 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
- The key value to get.
--binding
string
- The binding name of the namespace, as stored in the
wrangler.toml
file, to delete.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- 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
- The key value to get.
--binding
string
- The binding name of the namespace, as stored in the
wrangler.toml
file, to delete.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- 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
- 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.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- 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
- The key’s name. The name may be 512 bytes maximum. All printable, non-whitespace characters are valid.
value
string
- The UTF-8 encoded string to be stored, up to 25 MB in length.
metadata
object
- Any arbitrary object (must serialize to JSON) to a maximum of 1024 bytes.
expiration
number
- The time, measured in number of seconds since the UNIX epoch, at which the key should expire.
expiration_ttl
number
- The number of seconds the document should exist before expiring. Must be at least
60
seconds.
- The number of seconds the document should exist before expiring. Must be at least
base64
boolean
- 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
.
- 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
delete
Delete all keys read from a JSON file within a given namespace.
$ wrangler kv:bulk delete <FILENAME> [OPTIONS]
FILENAME
string
- 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.
- The binding name of the namespace, as stored in the
--namespace-id
string
- The ID of the namespace to delete.
--env
string
- Perform on a specific environment.
--preview
boolean
- 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
- The name of the new R2 bucket.
delete
Delete an R2 bucket.
$ wrangler r2 bucket delete <NAME>
NAME
string
- 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
- The source object path in the form of
{bucket}/{key}
.
- The source object path in the form of
put
Create an object in an R2 bucket.
$ wrangler r2 object put <OBJECTPATH> [OPTIONS]
OBJECTPATH
string
- The destination object path in the form of
{bucket}/{key}
.
- The destination object path in the form of
--file
string
- The path of the file to upload. Note you must provide either
--file
or--pipe
.
- The path of the file to upload. Note you must provide either
--pipe
boolean
- Enables the file to be piped in, rather than specified with the –file option. Note you must provide either
--file
or--pipe
.
- Enables the file to be piped in, rather than specified with the –file option. Note you must provide either
--content-type
string
- A standard MIME type describing the format of the object data.
--content-disposition
string
- Specifies presentational information for the object.
--content-encoding
string
- 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
- The language the content is in.
--cache-control
string
- Specifies caching behavior along the request/reply chain.
--expires
string
- 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
- The destination object path in the form of
{bucket}/{key}
.
- The destination object path in the form of
secret
Manage the secret variables for a Worker.
put
Create or replace a secret for a Worker.
$ wrangler secret put <KEY> [OPTIONS]
KEY
string
- The variable name for this secret to be accessed in the Worker.
--name
string
- Perform on a specific Worker script rather than inheriting from
wrangler.toml
.
- Perform on a specific Worker script rather than inheriting from
--env
string
- Perform on a specific environment.
delete
Delete a secret for a Worker.
$ wrangler secret delete <KEY> [OPTIONS]
KEY
string
- The variable name for this secret to be accessed in the Worker.
--name
string
- Perform on a specific Worker script rather than inheriting from
wrangler.toml
.
- Perform on a specific Worker script rather than inheriting from
--env
string
- Perform on a specific environment.
list
List the names of all the secrets for a Worker.
$ wrangler secret list [OPTIONS]
--name
string
- Perform on a specific Worker script rather than inheriting from
wrangler.toml
.
- Perform on a specific Worker script rather than inheriting from
--env
string
- 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
- The JSON file of key-value pairs to upload, in form {“key”: value, …}
--name
string
- Perform on a specific Worker script rather than inheriting from
wrangler.toml
.
- Perform on a specific Worker script rather than inheriting from
--env
string
- Perform on a specific environment
tail
Start a session to livestream logs from a deployed Worker.
$ wrangler tail <NAME> [OPTIONS]
NAME
string
--format
“json”|“pretty”
- The format of the log entries.
--status
“ok”|“error”|“canceled”
- Filter by invocation status.
--header
string
- Filter by HTTP header.
--method
string
- Filter by HTTP method.
--sampling-rate
number
- Add a fraction of requests to log sampling rate (between
0
and1
).
- Add a fraction of requests to log sampling rate (between
--search
string
- Filter by a text match in
console.log
messages.
- Filter by a text match in
--ip
(string|“self”)[]
- Filter by the IP address the request originates from. Use
"self"
to show only messages from your own IP.
- Filter by the IP address the request originates from. Use
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
- Run on your local machine.
--port
number
- The port to listen on (serve from).
--proxy
number
- The port to proxy (where the static assets are served).
--script-path
string
- 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[]
- R2 bucket to bind.
--d1
string[]
- D1 database to bind.
--do
string[]
- Durable Object to bind (NAME=CLASS).
--live-reload
boolean
- 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
- ID or URL of the deployment to tail. Specify by environment if deployment ID is unknown.
--project-name
string
- The name of the project you would like to tail.
--environment
“production”|“preview”
- When not providing a specific deployment ID, specifying environment will grab the latest production or preview deployment.
--format
“json”|“pretty”
- The format of the log entries.
--status
“ok”|“error”|“canceled”
- Filter by invocation status.
--header
string
- Filter by HTTP header.
--method
string
- Filter by HTTP method.
--sampling-rate
number
- Add a percentage of requests to log sampling rate.
--search
string
- Filter by a text match in
console.log
messages.
- Filter by a text match in
--ip
(string|“self”)[]
- Filter by the IP address the request originates from. Use
"self"
to show only messages from your own IP.
- Filter by the IP address the request originates from. Use
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
- List all the available OAuth scopes with descriptions.
--scopes $SCOPES
string
- 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
.
- Allows to choose your set of OAuth scopes. The set of scopes must be entered in a whitespace-separated list,
for example,
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:
- Log in to the Cloudflare dashboard.
- Go to Overview > Get your API token in the right-side menu.
- Select the three-dot menu on your Wrangler token.
- 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
- Perform on a specific Worker script rather than inheriting from
wrangler.toml
.
- Perform on a specific Worker script rather than inheriting from
Example output:
Deployment ID: y565f193-a6b9-4c7f-91ae-4b4e6d98ftbfCreated on: 2022-11-11T15:49:08.117218ZAuthor: example@cloudflare.comSource: Dashboard
Deployment ID: 91943f34-4802-4af7-a350-b5894c73ff34Created on: 2022-11-11T15:50:08.117218ZAuthor: example@cloudflare.comSource: Dashboard
Deployment ID: 31d8f2f0-fba3-4ce9-8427-933f42541b56Created on: 2022-11-11T15:51:08.117218ZAuthor: example@cloudflare.comSource: Rollback from Wrangler 🤠Rollback from: y565f193-a6b9-4c7f-91ae-4b4e6d98ftbfMessage: This is a message submitted on rollback
Deployment ID: 7c2761da-5a45-4cb2-9448-a662978e3a59Created on: 2022-11-11T15:52:08.117218ZAuthor: example@cloudflare.comSource: Rollback from Dashboard 🖥️Rollback from: 31d8f2f0-fba3-4ce9-8427-933f42541b56
Deployment ID: e81fe980-7622-6e1d-740b-1457de3e07e2Created on: 2022-11-11T15:53:20.79936ZAuthor: example@cloudflare.comSource: 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
- The ID of the deployment you wish to view.
--name
string
- Perform on a specific Worker script rather than inheriting from
wrangler.toml
.
- Perform on a specific Worker script rather than inheriting from
Example output:
Deployment ID: 07d7143d-0284-427e-ba22-2d5e6e91b479Created on: 2023-03-02T21:05:15.622446ZAuthor: example@cloudflare.comSource: Upload from Wrangler 🤠------------------------------------------------------------Author ID: e5a3ca86e08fb0940d3a05691310bb42Usage Model: bundledHandlers: fetchCompatibility 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
- The ID of the deployment you wish to view.
--message
string
- 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/chooseSuccessfully rolled back to deployment ID: e81fe980-7622-6e1d-740b-1457de3e07e2Current 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
- The name of the dispatch namespace to get details about.
create
Create a dispatch namespace.
$ wrangler dispatch-namespace create <NAME>
NAME
string
- The name of the dispatch namespace to create.
delete
Delete a dispatch namespace.
$ wrangler dispatch-namespace get <NAME>
NAME
string
- The name of the dispatch namespace to delete.
rename
Rename a dispatch namespace.
$ wrangler dispatch-namespace get <OLD-NAME> <NEW-NAME>
OLD NAME
string
- The previous name of the dispatch namespace.
NEW NAME
string
- 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
- A path to the TLS certificate to upload. Certificate chains are supported
--key
string
- A path to the private key to upload.
--name
string
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