Workers

Wrangler commands for creating, developing, deploying, and managing Workers.

Create a new project via the create-cloudflare-cli (C3) tool. A variety of web frameworks are available to choose from as well as templates. Dependencies are installed by default, with the option to deploy your project immediately.

wrangler init [<NAME>] [OPTIONS]

• NAME stringoptional (default: name of working directory)
  • The name of the Workers project. This is both the directory name and name property in the generated Wrangler configuration.
• --yes booleanoptional
  • Answer yes to any prompts for new projects.
• --from-dash stringoptional
  • 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 following global flags work on every command:

• --help boolean
  • Show help.
• --config string (not supported by Pages)
  • Path to your Wrangler configuration file.
• --cwd string
  • Run as if Wrangler was started in the specified directory instead of the current working directory.

Start a local server for developing your Worker.

wrangler dev [<SCRIPT>] [OPTIONS]

• SCRIPT string

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

• --name stringoptional

  • Name of the Worker.

• --config, -c string[]optional

  • Path(s) to Wrangler configuration file. If not provided, Wrangler will use the nearest config file based on your current working directory.
  • You can provide multiple configuration files to run multiple Workers in one dev session like this: wrangler dev -c ./wrangler.toml -c ../other-worker/wrangler.toml. The first config will be treated as the primary Worker, which will be exposed over HTTP. The remaining config files will only be accessible via a service binding from the primary Worker.

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

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

• --env stringoptional

  • Perform on a specific environment.

• --compatibility-date stringoptional

  • 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 string[]optional

  • Flags to use for compatibility checks.

• --latest boolean(default: true) optional

  • Use the latest version of the Workers runtime.

• --ip stringoptional

  • IP address to listen on, defaults to localhost.

• --port numberoptional

  • Port to listen on.

• --inspector-port numberoptional

  • Port for devtools to connect to.

• --routes, --route string[]optional

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

• --host stringoptional

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

• --local-protocol 'http'|'https'(default: http) optional

  • Protocol to listen to requests on.

• --https-key-path stringoptional

  • Path to a custom certificate key.

• --https-cert-path stringoptional

  • Path to a custom certificate.

• --local-upstream stringoptional

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

• --assets stringoptional beta

  • Folder of static assets to be served. Replaces Workers Sites. Visit assets for more information.

• --site stringoptional deprecated, use `--assets`

  • Folder of static assets for Workers Sites.

• --site-include string[]optional deprecated

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

• --site-exclude string[]optional deprecated

  • 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) optional

  • Protocol to forward requests to host on.

• --var key:value\[]optional

  • 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 configuration file. If defined in both places, this flag's values will be used.

• --define key:value\[]optional

  • 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 configuration file. If defined in both places, this flag's values will be used.

• --tsconfig stringoptional

  • Path to a custom tsconfig.json file.

• --minify booleanoptional

  • Minify the Worker.

• --persist-to stringoptional

  • Specify directory to use for local persistence.

• --remote boolean(default: false) optional

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

• --tunnel boolean(default: false) optional

  • Expose your local dev server over a Cloudflare Tunnel. For more information, refer to Share a local dev server.

• --tunnel-name stringoptional

  • Use an existing named Cloudflare Tunnel. Combine with --tunnel to open it automatically at startup.

• --test-scheduled boolean(default: false) optional

  • 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=*+*+*+*+* or /cdn-cgi/handler/scheduled?cron=*+*+*+*+*.

• --log-level 'debug'|'info'|'log'|'warn'|'error|'none'(default: log) optional

  • Specify Wrangler's logging level.

• --show-interactive-dev-session boolean(default: true if the terminal supports interactivity) optional

  • Show the interactive dev session.

• --alias Array<string>

  • Specify modules to alias using module aliasing.

• --types boolean(default: false) optional

  • Generate types from your Worker configuration.

• --local boolean(default: false) optional

  • Run in local mode. In this mode:
    • the Worker code is running locally on your machine
    • all remote bindings are disabled, which behaves exactly as if they were configured with remote: false.

The following global flags work on every command:

• --help boolean
  • Show help.
• --config string (not supported by Pages)
  • Path to your Wrangler configuration file.
• --cwd string
  • Run as if Wrangler was started in the specified directory instead of the current working directory.

wrangler dev is a way to locally test your Worker while developing. With wrangler dev running, 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.

Deploy your Worker to Cloudflare.

When you run wrangler deploy in a project directory without a Wrangler configuration file, Wrangler will automatically detect your framework and configure your project for Cloudflare Workers. This command will prompt you to confirm the detected settings before applying changes. Confirm that you would like to proceed, and your project will be configured and deployed.

To deploy from an AI agent or another environment before Cloudflare authentication is available, use wrangler deploy --temporary. This flow requires Wrangler 4.102.0 or later. Wrangler creates or reuses a temporary preview account, deploys to that account, and prints a claim URL. For more information, refer to Claim deployments.

To configure your project without deploying, use wrangler setup instead.

wrangler deploy [<PATH>] [OPTIONS]

• PATH string

  • A path specific what needs to be deployed, this can either be:

    • The path to an entry point for your Worker.

      • Only required if your Wrangler configuration file does not include a main key (for example, main = "index.js").

    • Or the path to an assets directory for the deployment of a static site.

      • Visit assets for more information.
      • This overrides the eventual assets configuration in your Wrangler configuration file.
      • This is equivalent to the --assets option listed below.
      • Note: this option currently only works only in interactive mode (so not in CI systems).

• --name stringoptional

  • Name of the Worker.

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

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

• --env stringoptional

  • Perform on a specific environment.

• --outdir stringoptional

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

• --compatibility-date stringoptional

  • 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 string[]optional

  • Flags to use for compatibility checks.

• --latest boolean(default: true) optional

  • Use the latest version of the Workers runtime.

• --assets stringoptional beta

  • Folder of static assets to be served. Replaces Workers Sites. Visit assets for more information.

• --site stringoptional deprecated, use `--assets`

  • Folder of static assets for Workers Sites.

• --site-include string[]optional deprecated

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

• --site-exclude string[]optional deprecated

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

• --var key:value\[]optional

  • 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 configuration file. If defined in both places, this flag's values will be used.

• --define key:value\[]optional

  • 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 configuration file. If defined in both places, this flag's values will be used.

• --triggers, --schedule, --schedules string[]optional

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

• --routes, --route string[] optional

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

• --domain string[]optional

  • Custom domains where this Worker will be deployed.
  • For example: --domain example.com.

• --tsconfig stringoptional

  • Path to a custom tsconfig.json file.

• --minify booleanoptional

  • Minify the bundled Worker before deploying.

• --dry-run boolean(default: false) optional

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

• --keep-vars boolean(default: false) optional

  • 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 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.
  • Secrets are never deleted by a deployment whether this flag is true or false.

• --secrets-file stringoptional

  • Path to a file containing secrets to upload alongside the deployment. Accepts JSON or .env format — the same formats used by wrangler secret bulk. Existing secrets not included in the file are preserved from the previous version. Refer to Secrets — Upload secrets alongside code for more details.

• --dispatch-namespace stringoptional

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

• --metafile stringoptional

  • Specify a file to write the build metadata from esbuild to. If flag is used without a path string, this defaults to bundle-meta.json inside the directory specified by --outdir. This can be useful for understanding the bundle size.

• --containers-rollout immediate | gradual | noneoptional

  • Specify the rollout strategy for Containers associated with the Worker. If set to immediate, 100% of container instances will be updated in one rollout step, overriding any configuration in rollout_step_percentage. Note that rollout_active_grace_period, if configured, still applies.
  • If set to none, Wrangler deploys the Worker without building or updating associated Containers.
  • Defaults to gradual, where the default rollout is 10% then 100% of instances.

• --strict boolean(default: false) optional

  • Turns on strict mode for the deployment command, meaning that the command will be more defensive and prevent deployments which could introduce potential issues. In particular, this mode prevents deployments if the deployment would potentially override remote settings in non-interactive environments.

• --tag stringoptional

  • A tag for this Worker version. Matches the behavior of wrangler versions upload --tag.

• --message stringoptional

  • A descriptive message for this Worker version and deployment. Matches the behavior of wrangler versions upload --message. The message is also applied to the deployment.

• --yes boolean(default: false) optional

  • Skip confirmation prompts and run automatic project configuration non-interactively using detected settings. Only applicable when no Wrangler configuration file exists in your project.

• --temporary booleanoptional

  • Deploy with a temporary preview account when no Cloudflare credentials are available. Requires Wrangler 4.102.0 or later. Wrangler prints a claim URL that lets you claim the deployment within 60 minutes. This is intended for AI agents and other first-time deployment flows. If Wrangler can already use OAuth, CLOUDFLARE_API_TOKEN, or a global API key, this flag returns an error. For more information, refer to Claim deployments.

The following global flags work on every command:

• --help boolean
  • Show help.
• --config string (not supported by Pages)
  • Path to your Wrangler configuration file.
• --cwd string
  • Run as if Wrangler was started in the specified directory instead of the current working directory.

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. Only required if your Wrangler configuration file does not include a main key (for example, main = "index.js").
• --name stringoptional
  • Name of the Worker.
• --env stringoptional
  • Perform on a specific environment.
• --dry-run boolean(default: false) optional
  • Do not actually delete the Worker. This is useful for testing the output of wrangler delete.

The following global flags work on every command:

• --help boolean
  • Show help.
• --config string (not supported by Pages)
  • Path to your Wrangler configuration file.
• --cwd string
  • Run as if Wrangler was started in the specified directory instead of the current working directory.

setup

🪄 Setup a project to work on Cloudflare

npx wrangler setup

yarn wrangler setup

pnpm wrangler setup

• --yesboolean alias: --ydefault: false

  Answer "yes" to any prompts for configuring your project

• --buildboolean default: false

  Run your project's build command once it has been configured

• --dry-runboolean

  Runs the command without applying any filesystem modifications

This command configures your project for Cloudflare Workers without deploying. It performs the same automatic project configuration as wrangler deploy, but does not deploy. This is useful when you want to review the generated configuration before deploying.

Manage the secret variables for a Worker.

This action creates a new version of the Worker and deploys it immediately. To only create a new version of the Worker, use the wrangler versions secret commands.

secret put

Create or update a secret for a Worker

npx wrangler secret put [KEY]

yarn wrangler secret put [KEY]

pnpm wrangler secret put [KEY]

• [KEY]string required

  The variable name to be accessible in the Worker

• --namestring

  Name of the Worker. If this is not specified, it will default to the name specified in your Wrangler config file.

When running this command, you will be prompted to input the secret's value:

npx wrangler secret put FOO

? Enter a secret value: > ***
🌀 Creating the secret for script worker-app
✨ Success! Uploaded secret FOO

The put command can also receive piped input. For example:

echo "-----BEGIN PRIVATE KEY-----\nM...==\n-----END PRIVATE KEY-----\n" | wrangler secret put PRIVATE_KEY

secret delete

Delete a secret from a Worker

npx wrangler secret delete [KEY]

yarn wrangler secret delete [KEY]

pnpm wrangler secret delete [KEY]

• [KEY]string required

  The variable name to be accessible in the Worker

• --namestring

  Name of the Worker. If this is not specified, it will default to the name specified in your Wrangler config file.

secret list

List all secrets for a Worker

npx wrangler secret list

yarn wrangler secret list

pnpm wrangler secret list

• --namestring

  Name of the Worker. If this is not specified, it will default to the name specified in your Wrangler config file.

• --format"json" | "pretty" default: json

  The format to print the secrets in

The following is an example of listing the secrets for the current Worker.

npx wrangler secret list

[
  {
    "name": "FOO",
    "type": "secret_text"
  }
]

secret bulk

Create, update, or delete multiple secrets for a Worker in a single request, with up to 100 secrets per command.

npx wrangler secret bulk [FILE]

yarn wrangler secret bulk [FILE]

pnpm wrangler secret bulk [FILE]

• [FILE]string

  The file of key-value pairs to create, update, or delete, as JSON in form {"key": "value", ...} or .env file in the form KEY=VALUE. Set a key to null in the JSON file to delete it. Deletion is not supported with .env files. If omitted, Wrangler expects to receive input from stdin rather than a file.

• --namestring

  Name of the Worker. If this is not specified, it will default to the name specified in your Wrangler config file.

The following is an example of creating, updating, and deleting secrets from a JSON file redirected to stdin. Set a key to null to delete it.

{
	"secret-name-1": "secret-value-1",
	"secret-name-2": "secret-value-2",
	"secret-name-3": null
}

npx wrangler secret bulk < secrets.json

🌀 Processing the secrets for the Worker "script-name"
✨ Successfully created secret for key: secret-name-1
✨ Successfully created secret for key: secret-name-2
💥 Successfully deleted secret for key: secret-name-3

Finished processing secrets file:
✨ 2 secrets successfully created
💥 1 secrets successfully deleted

tail

🦚 Start a log tailing session for a Worker

npx wrangler tail [WORKER]

yarn wrangler tail [WORKER]

pnpm wrangler tail [WORKER]

• [WORKER]string

  Name or route of the worker to tail

• --format"json" | "pretty"

  The format of log entries

• --status"ok" | "error" | "canceled"

  Filter by invocation status

• --headerstring

  Filter by HTTP header

• --methodstring

  Filter by HTTP method

• --sampling-ratenumber

  Adds a percentage of requests to log sampling rate

• --searchstring

  Filter by a text match in console.log messages

• --ipstring

  Filter by the IP address the request originates from. Use "self" to filter for your own IP

• --version-idstring

  Filter by Worker version

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.

versions upload

Upload a new version of your Worker that is not deployed immediately.

npx wrangler versions upload [PATH]

yarn wrangler versions upload [PATH]

pnpm wrangler versions upload [PATH]

• [PATH]string

  The path to an entry point for your Worker or a directory of static assets

• --namestring

  Name of the Worker

• --tagstring

  A tag for this Worker Version

• --messagestring

  A descriptive message for this Worker Version

• --no-bundleboolean default: false

  Skip internal build steps and directly upload Worker

• --outdirstring

  Output directory for the bundled Worker

• --outfilestring

  Output file for the bundled worker

• --compatibility-datestring

  Date to use for compatibility checks

• --compatibility-flagsstring alias: --compatibility-flag

  Flags to use for compatibility checks

• --latestboolean default: false

  Use the latest version of the Workers runtime

• --assetsstring

  Static assets to be served. Replaces Workers Sites.

• --varstring

  A key-value pair to be injected into the script as a variable

• --definestring

  A key-value pair to be substituted in the script

• --aliasstring

  A module pair to be substituted in the script

• --jsx-factorystring

  The function that is called for each JSX element

• --jsx-fragmentstring

  The function that is called for each JSX fragment

• --tsconfigstring

  Path to a custom tsconfig.json file

• --minifyboolean

  Minify the Worker

• --upload-source-mapsboolean

  Include source maps when uploading this Worker

• --dry-runboolean

  Compile a project and run checks without actually uploading the Worker

• --secrets-filestring

  Path to a file containing secrets to upload with the version (JSON or .env format). Applies additively with secrets from previous deployments - omitted secrets will not be deleted.

• --keep-varsboolean default: false

  When not used (or set to false), Wrangler will delete all vars before setting those found in the Wrangler configuration. When used (and set to true), the environment variables are not deleted before the deployment. If you set variables via the dashboard you probably want to use this flag. Note that secrets are never deleted by deployments.

• --strictboolean default: false

  Enables strict mode, which prevents uploads when there are conflicting remote changes.

• --preview-aliasstring

  Name of an alias for this Worker version

versions deploy

Deploy a previously created version of your Worker all at once or create a gradual deployment to incrementally shift traffic to a new version by following an interactive prompt.

npx wrangler versions deploy [VERSION-SPECS]

yarn wrangler versions deploy [VERSION-SPECS]

pnpm wrangler versions deploy [VERSION-SPECS]

• --namestring

  Name of the worker

• --version-idstring

  Worker Version ID(s) to deploy

• --percentagenumber

  Percentage of traffic to split between Worker Version(s) (0-100)

• [VERSION-SPECS]string

  Shorthand notation to deploy Worker Version(s) [<version-id>@<percentage>..]. Omitted percentages share the remaining traffic.

• --version-tagstring

  Worker Version tag(s) to deploy, resolved to a Version ID against the deployable versions. Supports the shorthand notation [<version-tag>@<percentage>..].

• --messagestring

  Description of this deployment (optional)

• --yesboolean alias: --ydefault: false

  Automatically accept defaults to prompts

• --dry-runboolean default: false

  Don't actually deploy

versions list

Retrieve details for the 10 most recent versions. Details include Version ID, Created on, Author, Source, and optionally, Tag or Message.

npx wrangler versions list

yarn wrangler versions list

pnpm wrangler versions list

• --namestring

  Name of the Worker

• --jsonboolean default: false

  Display output as JSON

versions view

View the details of a specific version of your Worker

npx wrangler versions view [VERSION-ID]

yarn wrangler versions view [VERSION-ID]

pnpm wrangler versions view [VERSION-ID]

• [VERSION-ID]string required

  The Worker Version ID to view

• --namestring

  Name of the worker

• --jsonboolean default: false

  Display output as JSON

versions secret put

Create or update a secret variable for a Worker

npx wrangler versions secret put [KEY]

yarn wrangler versions secret put [KEY]

pnpm wrangler versions secret put [KEY]

• [KEY]string

  The variable name to be accessible in the Worker

• --namestring

  Name of the Worker

• --messagestring

  Description of this deployment

• --tagstring

  A tag for this version

versions secret delete

Delete a secret variable from a Worker

npx wrangler versions secret delete [KEY]

yarn wrangler versions secret delete [KEY]

pnpm wrangler versions secret delete [KEY]

• [KEY]string

  The variable name to be accessible in the Worker

• --namestring

  Name of the Worker

• --messagestring

  Description of this deployment

• --tagstring

  A tag for this version

versions secret bulk

Create or update a secret variable for a Worker

npx wrangler versions secret bulk [FILE]

yarn wrangler versions secret bulk [FILE]

pnpm wrangler versions secret bulk [FILE]

• [FILE]string

  The file of key-value pairs to upload, as JSON in form {"key": value, ...} or .dev.vars file in the form KEY=VALUE

• --namestring

  Name of the Worker

• --messagestring

  Description of this deployment

• --tagstring

  A tag for this version

triggers deploy

Apply changes to triggers (Routes or domains and Cron Triggers) when using wrangler versions upload

npx wrangler triggers deploy

yarn wrangler triggers deploy

pnpm wrangler triggers deploy

• --namestring

  Name of the worker

• --triggersstring aliases: --schedule, --schedules

  cron schedules to attach

• --routesstring alias: --route

  Routes to upload

• --dry-runboolean

  Don't actually deploy

Deployments track the version(s) of your Worker that are actively serving traffic.

deployments list

Displays the 10 most recent deployments of your Worker

npx wrangler deployments list

yarn wrangler deployments list

pnpm wrangler deployments list

• --namestring

  Name of the Worker

• --jsonboolean default: false

  Display output as JSON

deployments status

View the current state of your production

npx wrangler deployments status

yarn wrangler deployments status

pnpm wrangler deployments status

• --namestring

  Name of the Worker

• --jsonboolean default: false

  Display output as JSON

wrangler rollback [<VERSION_ID>] [OPTIONS]

• VERSION_ID stringoptional
  • 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.
• --name stringoptional
  • Perform on a specific Worker rather than inheriting from the Wrangler configuration file.
• --message stringoptional
  • Add message for rollback. Accepts empty string. When specified, interactive prompts for rollback confirmation and message are skipped.

The following global flags work on every command:

• --help boolean
  • Show help.
• --config string (not supported by Pages)
  • Path to your Wrangler configuration file.
• --cwd string
  • Run as if Wrangler was started in the specified directory instead of the current working directory.

Generate types based on your Worker configuration, including Env types based on your bindings, module rules, and runtime types based on thecompatibility_date and compatibility_flags in your config file.

wrangler types [<PATH>] [OPTIONS]

By default, wrangler types generates types for bindings from all environments defined in your configuration file. This ensures your generated Env type includes all bindings that might be used across different deployment environments (such as staging and production), preventing TypeScript errors when accessing environment-specific bindings.

For example, if you have a KV namespace binding only in production and an R2 bucket binding only in staging, both will be included in the generated types as optional properties.

To generate types for only a specific environment, use the --env flag.

• PATH string(default: `./worker-configuration.d.ts`)
  • The path to where types for your Worker will be written.
  • The path must have a d.ts extension.
• --env stringoptional
  • Generate types for bindings in a specific environment only, rather than aggregating bindings from all environments.
• --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.
• --include-runtime boolean(default: true)
  • Whether to generate runtime types based on thecompatibility_date and compatibility_flags in your config file.
• --include-env boolean(default: true)
  • Whether to generate Env types based on your Worker bindings.
• --strict-vars booleanoptional (default: true)
  • Control the types that Wrangler generates for vars bindings.
  • If true, (the default) Wrangler generates literal and union types for bindings (e.g. myVar: 'my dev variable' | 'my prod variable').
  • If false, Wrangler generates generic types (e.g. myVar: string). This is useful when variables change frequently, especially when working across multiple environments.
• --check booleanoptional
  • Check if the generated types at the specified path are up-to-date without regenerating them.
  • Exits with code 0 if types are up-to-date, or code 1 if types are out-of-date.
  • Useful for CI/CD pipelines and pre-commit hooks to ensure types have been regenerated after configuration changes.
• --config, -c string[]optional
  • Path(s) to Wrangler configuration file. If the Worker you are generating types for has service bindings or bindings to Durable Objects, you can also provide the paths to those configuration files so that the generated Env type will include RPC types. For example, given a Worker with a service binding, wrangler types -c wrangler.toml -c ../bound-worker/wrangler.toml will generate an Env type like this:

  interface Env {
  	SERVICE_BINDING: Service<import("../bound-worker/src/index").Entrypoint>;
  }

Analyze your Worker's startup phase. Wrangler reports bundle size and a summary of local CPU activity. It also saves a detailed CPU profile.

wrangler check startup

Bundle: 42.31 KiB / gzip: 11.24 KiB

Local startup profile:
  Profile window: 25.2 ms
  Sampled time: 24.8 ms
  Active: 18.4 ms (including 1.2 ms garbage collection)
  Idle: 6.4 ms
  Samples: 25

The local startup profile includes the following metrics:

Import the generated .cpuprofile file into Chrome DevTools or open it directly in VS Code to view a flamegraph. When a Worker deployment fails with a startup time error, Wrangler also generates this profile automatically.

• --args stringoptional
  • To customise the way wrangler check startup builds your Worker for analysis, provide the exact arguments you use when deploying your Worker with wrangler deploy, or your Pages project with wrangler pages functions build. For instance, if you deploy your Worker with wrangler deploy --no-bundle, you should use wrangler check startup --args="--no-bundle" to profile the startup phase.
• --worker stringoptional
  • If you don't use Wrangler to deploy your Worker, you can use this argument to provide a Worker bundle to analyse. This should be a file path to a serialized multipart upload, with the exact same format as the API expects.
• --pages booleanoptional
  • If you don't use a Wrangler config file with your Pages project (i.e. a Wrangler config file containing pages_build_output_dir), use this flag to force wrangler check startup to treat your project as a Pages project.

The following global flags work on every command:

• --help boolean
  • Show help.
• --config string (not supported by Pages)
  • Path to your Wrangler configuration file.
• --cwd string
  • Run as if Wrangler was started in the specified directory instead of the current working directory.