Wrangler commands

• The Wrangler command you want to learn more about. This opens your default browser to the section of the documentation that describes the command.

• The name of the Workers project. This is both the directory name and name property in the generated wrangler.toml configuration file.

• Answer yes to any prompts for new projects.

• 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.

• The name of the Workers project. This is both the directory name and name property in the generated wrangler.toml configuration file.

• The URL of a GitHub template, with a default worker-template Open external link . Browse a list of available templates on the cloudflare/workers-sdk Open external link repository.

• The name of the new D1 database.

• Provide an optional location hint for your database leader.
• Available options include weur (Western Europe), eeur (Eastern Europe), apac (Asia Pacific), oc (Oceania), wnam (Western North America), and enam (Eastern North America).

• The name of the D1 database to get information about.

• Return output as JSON rather than a table.

• Return output as JSON rather than a table.

• The name of the D1 database to delete.

• Skip deletion confirmation prompt.

• The name of the D1 database to execute a query on.

• The SQL query you wish to execute.

• Path to the SQL file you wish to execute.

• Answer yes to any prompts.

• Execute commands/files against a local database for use with wrangler dev.

• Execute commands/files against a remote D1 database for use with wrangler dev –remote.

• Specify directory to use for local persistence (for use in combination with --local).

• Return output as JSON rather than a table.

• Execute commands/files against a preview D1 database (as defined by preview_database_id in Wrangler.toml).

• Number of queries to send in a single batch.

• The name of the D1 database to export.

• Execute commands/files against a remote D1 database for use with wrangler dev –remote.

• Path to the SQL file for your export.

• The name of the table within a D1 database to export.

• Controls whether export SQL file contains database data.

• Controls whether export SQL file contains database schema.

• The name of the D1 database to execute a query on.

• A D1 bookmark representing the state of a database at a specific point in time.

• A UNIX timestamp or JavaScript date-time string within the last 30 days.

• Return output as JSON rather than a table.

• The name of the D1 database to execute a query on.

• A UNIX timestamp or JavaScript date-time string within the last 30 days.

• Return output as JSON rather than a table.

• The name of the D1 database to backup.

• The name of the D1 database to list the backups of.

• The name of the D1 database to restore the backup into.

• The ID of the backup you wish to restore.

• The name of the D1 database you wish to download the backup of.

• The ID of the backup you wish to download.

• The .sqlite3 file to write to (defaults to '<DB_NAME>.<SHORT_BACKUP_ID>.sqlite3').

• The name of the D1 database you wish to create a migration for.

• A descriptive name for the migration you wish to create.

• The name of the D1 database you wish to list unapplied migrations for.

• Show the list of unapplied migration files on your locally persisted D1 database.

• Specify directory to use for local persistence (for use in combination with --local).

• Show the list of unapplied migration files on your preview D1 database (as defined by preview_database_id in wrangler.toml).

• The name of the D1 database you wish to apply your migrations on.

• Execute any unapplied migrations on your locally persisted D1 database.

• Execute any unapplied migrations on your remote D1 database.

• Specify directory to use for local persistence (for use in combination with --local).

• Execute any unapplied migrations on your preview D1 database (as defined by preview_database_id in wrangler.toml).

• Number of queries to send in a single batch.

• The ID of the Hyperdrive configuration to create.

• The database connection string in the form postgres://user:password@hostname:port/database.

• Disables the caching of SQL responses.

• Specifies max duration for which items should persist in the cache, cannot be set when caching is disabled.

• Stale While Revalidate - Indicates the number of seconds cache may serve the response after it becomes stale, cannot be set when caching is disabled.

• The ID of the Hyperdrive configuration to update.

• The new name of the Hyperdrive configuration.

• The new database hostname or IP address Hyperdrive should connect to.

• The new database port to connect to.

• The new database (name) to connect to. For example, Postgres or defaultdb.

• The new username used to authenticate to the database.

• The new password used to authenticate to the database.

• Disables the caching of SQL responses.

• Specifies max duration for which items should persist in the cache, cannot be set when caching is disabled.

• Stale While Revalidate - Indicates the number of seconds cache may serve the response after it becomes stale, cannot be set when caching is disabled.

• The name of the Hyperdrive configuration to delete.

• The name of the Hyperdrive configuration to get.

• The name of the new index to create. Cannot be changed.

• The vector dimension width to configure the index for. Cannot be changed after creation.

• The distance metric to use for calculating vector distance. Must be one of cosine, euclidean, or dot-product.

• The name of the index to fetch details for.

• The name of the Vectorize index to delete.

• Skip confirmation when deleting the index (Note: This is not a recoverable operation).

• The name of the Vectorize index to delete.

• A file containing the vectors to insert in newline-delimited JSON (JSON) format.

• The number of vectors to insert at a time (default: 5000).

• The path to an entry point for your Worker. Only required if your wrangler.toml does not include a main key (for example, main = "index.js").

• Name of the Worker.

• Skip Wrangler’s build steps. Particularly useful when using custom builds. Refer to Bundling for more information.

• Perform on a specific environment.

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

• Flags to use for compatibility checks.

• Use the latest version of the Workers runtime.

• IP address to listen on, defaults to localhost.

• Port to listen on.

• Port for devtools to connect to.

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

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

• Protocol to listen to requests on.

• Path to a custom certificate key.

• Path to a custom certificate.

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

• Root folder of static assets to be served.
• 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 for Workers Sites.

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

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

• Protocol to forward requests to host on.

• 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.

• 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.

• Path to a custom tsconfig.json file.

• Minify the Worker.

• Enable Node.js compatibility.

• Specify directory to use for local persistence.

• Develop against remote resources and data stored on Cloudflare’s network.

• 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=*+*+*+*+*.

• Specify Wrangler’s logging level.

• Show the interactive dev session.

• The path to an entry point for your Worker. Only required if your wrangler.toml does not include a main key (for example, main = "index.js").

• Name of the Worker.

• Skip Wrangler’s build steps. Particularly useful when using custom builds. Refer to Bundling for more information.

• Perform on a specific environment.

• Path to directory where Wrangler will write the bundled Worker files.

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

• Flags to use for compatibility checks.

• Use the latest version of the Workers runtime.

• Root folder of static assets to be served.
• Use in combination with --name and --latest for basic static file hosting. For example: npx wrangler deploy --name personal_blog --assets dist/ --latest.

• Root folder of static assets for Workers Sites.

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

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

• 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.

• 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.

• Cron schedules to attach to the deployed Worker. Refer to Cron Trigger Examples.

• Routes where this Worker will be deployed.
• For example: --route example.com/*.

• Path to a custom tsconfig.json file.

• Minify the bundled Worker before deploying.

• Enable node.js compatibility.

• Compile a project without actually deploying to live servers. Combined with --outdir, this is also useful for testing the output of npx wrangler deploy. 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.

• 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.

• Specify the Workers for Platforms dispatch namespace to upload this Worker to.

• The path to an entry point for your Worker. Only required if your wrangler.toml does not include a main key (for example, main = "index.js").

• Name of the Worker.

• Perform on a specific environment.

• Do not actually delete the Worker. This is useful for testing the output of wrangler delete.

• The name of the new namespace.

• Perform on a specific environment.

• Interact with a preview namespace (the preview_id value).

• The binding name of the namespace, as stored in the wrangler.toml file, to delete.

• The ID of the namespace to delete.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• The key to write to.

• The value to write.

• 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.

• The binding name of the namespace, as stored in the wrangler.toml file, to delete.

• The ID of the namespace to delete.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• 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.

• The timestamp, in UNIX seconds, indicating when the key-value pair should expire.

• Any (escaped) JSON serialized arbitrary object to a maximum of 1024 bytes.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The binding name of the namespace, as stored in the wrangler.toml file, to delete.

• The ID of the namespace to delete.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• Only list keys that begin with the given prefix.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The key value to get.

• The binding name of the namespace, as stored in the wrangler.toml file, to get from.

• The ID of the namespace to get from.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• Decode the returned value as a UTF-8 string.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The key value to get.

• The binding name of the namespace, as stored in the wrangler.toml file, to delete.

• The ID of the namespace to delete.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The JSON file containing an array of key-value pairs to write to the namespace.

• The binding name of the namespace, as stored in the wrangler.toml file, to delete.

• The ID of the namespace to delete.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The key’s name. The name may be 512 bytes maximum. All printable, non-whitespace characters are valid.

• The UTF-8 encoded string to be stored, up to 25 MB in length.

• Any arbitrary object (must serialize to JSON) to a maximum of 1024 bytes.

• The time, measured in number of seconds since the UNIX epoch, at which the key should expire.

• The number of seconds the document should exist before expiring. Must be at least 60 seconds.

• 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.

• The JSON file containing an array of keys to delete from the namespace.

• The binding name of the namespace, as stored in the wrangler.toml file, to delete.

• The ID of the namespace to delete.

• Perform on a specific environment.

• Interact with a preview namespace instead of production.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The name of the new R2 bucket.

• The default storage class for objects uploaded to the bucket.

• The jurisdiction where the R2 bucket is created. Refer to Jurisdictional Restrictions.

• The name of the R2 bucket to delete.

• The name of the R2 bucket to create an event notification rule for.

• The type of event that will trigger event notifications.

• The name of the queue that will receive event notification messages.

• Specifies the key name prefix that an object must match to trigger event notifications.

• Specifies the key name suffix that an object must match to trigger event notifications.

• The name of the R2 bucket to delete an event notification rule for.

• The name of the queue that corresponds to the event notification rule.

• The name of the R2 bucket to get event notification configuration for.

• The name of the R2 bucket to enable Sippy.

• The provider of your source object storage bucket.

• The name of your source object storage bucket.

• Your R2 Access Key ID. Requires read and write access.

• Your R2 Secret Access Key. Requires read and write access.

• The jurisdiction where this R2 bucket is located, if a jurisdiction has been specified. Refer to Jurisdictional Restrictions.

• Your AWS Access Key ID. Requires read and list access.

• Your AWS Secret Access Key. Requires read and list access.

• The AWS region where your S3 bucket is located. For example: us-west-2.

• The path to your Google Cloud service account key JSON file. This will read the service account key file and populate client_email and private_key options. Requires read and list access.

• The client email for your Google Cloud service account key. Requires read and list access.

• The private key for your Google Cloud service account key. Requires read and list access.

• The name of the R2 bucket to disable Sippy.

• The name of the R2 bucket to get the status of Sippy.

• The source object path in the form of {bucket}/{key}.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The destination object path in the form of {bucket}/{key}.

• The path of the file to upload. 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 --file or --pipe.

• A standard MIME type describing the format of the object data.

• Specifies presentational information for the object.

• 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.

• The language the content is in.

• Specifies caching behavior along the request/reply chain.

• The date and time at which the object is no longer cacheable.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

• The destination object path in the form of {bucket}/{key}.

• Interact with locally persisted data.

• Specify directory for locally persisted data.

KEY string required

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

--name string optional

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

--env string optional

• Perform on a specific environment.

KEY string required

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

--name string optional

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

--env string optional

• Perform on a specific environment.

--name string optional

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

--env string optional

• Perform on a specific environment

FILENAME string optional

• The JSON file containing key-value pairs to upload as secrets, in the form {"SECRET_NAME": "secret value", ...}.
• If omitted, Wrangler expects to receive input from stdin rather than a file.

--name string optional

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

--env string optional

• Perform on a specific environment.

• The name of your Worker or the route the Worker is running on.

• The format of the log entries.

• Filter by invocation status.

• Filter by HTTP header.

• Filter by HTTP method.

• Add a fraction of requests to log sampling rate (between 0 and 1).

• Filter by a text match in console.log messages.

• Filter by the IP address the request originates from. Use "self" to show only messages from your own IP.

• Filter by Worker version.

• The directory of static assets to serve.

• Run on your local machine.

• IP address to listen on, defaults to localhost.

• The port to listen on (serve from).

• Bind an environment variable or secret (for example, --binding <VARIABLE_NAME>=<VALUE>).

• Binding name of KV namespace to bind (for example, --kv <BINDING_NAME>).

• Binding name of R2 bucket to bind (for example, --r2 <BINDING_NAME>).

• Binding name of D1 database to bind (for example, --d1 <BINDING_NAME>).

• Binding name of Durable Object to bind (for example, --do <BINDING_NAME>=<CLASS>).

• Auto reload HTML pages when change is detected.

• Runtime compatibility flags to apply.

• Runtime compatibility date to apply.

• Show the interactive dev session.

• Path to a custom certificate key.

• Path to a custom certificate.

• The name of your Pages project.

• The name of the production branch of your project.

• The name of the Pages project to delete.

• Answer "yes" to confirmation prompt.

• The name of the project you would like to list deployments for.

• ID or URL of the deployment to tail. Specify by environment if deployment ID is unknown.

• The name of the project you would like to tail.

• When not providing a specific deployment ID, specifying environment will grab the latest production or preview deployment.

• The format of the log entries.

• Filter by invocation status.

• Filter by HTTP header.

• Filter by HTTP method.

• Add a percentage of requests to log sampling rate.

• Filter by a text match in console.log messages.

• Filter by the IP address the request originates from. Use "self" to show only messages from your own IP.

• The directory of static files to upload. As of Wrangler 3.45.0, this is only required when your Pages project does not have a wrangler.toml file. Refer to the Pages Functions configuration guide for more information.

• The name of the project you want to deploy to.

• The name of the branch you want to deploy to.

• The SHA to attach to this deployment.

• The commit message to attach to this deployment.

• Whether or not the workspace should be considered dirty for this deployment.

• The name of the queue to create.

• How long a published message should be delayed for, in seconds. Must be a positive integer.

• The name of the queue to delete.

• The name of the queue to add the consumer to.

• The name of the Workers script to add as a consumer of the named queue.

• Maximum number of messages per batch. Must be a positive integer.

• Maximum number of seconds to wait to fill a batch with messages. Must be a positive integer.

• Maximum number of retries for each message. Must be a positive integer.

• The maximum number of concurrent consumer invocations that will be scaled up to handle incoming message volume. Must be a positive integer.

• How long a retried message should be delayed for, in seconds. Must be a positive integer.

• The name of the queue to remove the consumer from.

• The name of the Workers script to remove as the consumer.

• List all the available OAuth scopes with descriptions.

• Allows to choose your set of OAuth scopes. The set of scopes must be entered in a whitespace-separated list, for example, $ npx wrangler login --scopes account:read user:read.

• Required for wrangler versions commands. Can be replaced with --x-versions.

• Add a version tag. Accepts empty string.

• Add a version message. Accepts empty string.

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

• Required for wrangler versions commands. Can be replaced with --x-versions.

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

• Required for wrangler versions commands. Can be replaced with --x-versions.

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

• Required for wrangler versions commands. Can be replaced with --x-versions.

• The ID of the version you wish to view.

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

• Required for wrangler versions commands. Can be replaced with --x-versions.

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

• The ID of the deployment you wish to view.

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

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

--experimental-versions string required

• Required for version commands. Can be replaced with --x-versions.

--name string optional

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

--experimental-versions string required

• Required for version commands. Can be replaced with --x-versions.

--name string optional

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

• The ID of the deployment you wish to roll back to.

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

• Add message for rollback. Accepts empty string. When specified, interactive prompts for rollback confirmation and message are skipped.

• Required for version commands. Can be replaced with --x-versions.

• The ID of the version you wish to roll back to. If not supplied, the rollback command defaults to the version uploaded before the latest version.

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

• Add message for rollback. Accepts empty string. When specified, interactive prompts for rollback confirmation and message are skipped.

NAME string required

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

NAME string required

• The name of the dispatch namespace to create.

NAME string required

• The name of the dispatch namespace to delete.

OLD_NAME string required

• The previous name of the dispatch namespace.

NEW_NAME string required

• The new name of the dispatch namespace.

• A path to the TLS certificate to upload. Certificate chains are supported.

• A path to the private key to upload.

• The name assigned to the mTLS certificate at upload.

• The ID of the mTLS certificate.

• The name assigned to the mTLS certificate at upload.

PATH string (default: worker-configuration.d.ts)

• The path to where the declaration file for your Worker will be written.
• The path to the declaration file must have a d.ts extension.

--env-interface string (default: Env)

• The name of the interface to generate for the environment object.
• Not valid if the Worker uses the Service Worker syntax.