ConfigGenerator

wrangler.toml Generator

Generate wrangler.toml configuration for Cloudflare Workers, Pages Functions, environments, routes, compatibility dates, assets, and bindings.

Output:A ready-to-use configuration file for wrangler.toml with best practices applied.

Basic Configuration

Choose a date no later than your deployment date. Newer dates enable newer runtime features.

Specify custom route patterns for the Worker.

Bindings

File Location

Where to place your wrangler.toml

Source Repository
wrangler.toml
After Build
wrangler.toml
  • •Place wrangler.toml at the root of your project repository.
  • •Do not commit sensitive secrets directly in wrangler.toml; use Wrangler secrets instead.
Validation Warnings
  • The selected compatibility_date is over 6 months old. Consider updating it to use newer V8 features and bug fixes.
Security WarningNever put sensitive secrets (API keys, tokens, passwords) in your wrangler.toml file. Use npx wrangler secret put instead.
name = "my-worker"
main = "src/index.ts"
compatibility_date = "2025-07-01"

[vars]
ENVIRONMENT = "production"
API_URL = "https://api.example.com"

Quick Summary

Use a wrangler.toml Generator when you need to configure a Cloudflare Worker or Pages deployment with specific environments, compatibility dates, or resource bindings (KV, D1, R2).

What is this tool?

The wrangler.toml file is the heart of any Cloudflare Workers project. It tells Cloudflare's infrastructure exactly how to run your code, what resources it has access to, and what its routing rules are.

It supports configuring multiple environments, connecting to databases (D1), object storage (R2), key-value stores (KV), and defining static asset directories.

How to Use This Tool

  1. Select if you are configuring a Worker or Pages deployment.
  2. Enter your project name and compatibility date.
  3. Configure your environments (Production, Preview).
  4. Add any necessary bindings for KV, R2, or D1.
  5. Copy the generated wrangler.toml to your project root.

What This Tool Generates

  • wrangler.toml — The primary configuration file for Wrangler CLI.

Best Practices

  • Always set a compatibility_date. This ensures your Worker won't break if Cloudflare updates their runtime behavior.
  • Use [env.production] blocks to cleanly separate your local/preview configurations from your live production settings.
  • Keep your wrangler.toml checked into version control.

Common Mistakes

  • Putting secrets directly in the [vars] section of wrangler.toml. They will be exposed in your git repository.
  • Forgetting to update the compatibility_date to access new V8 runtime features.
  • Misconfiguring the main entry point (e.g., pointing to src/index.ts instead of dist/index.js if you are compiling manually).

Security Notes

  • Use Wrangler Secrets for all sensitive environment variables.
  • Review your bindings carefully; do not give a preview environment access to your production D1 database unless absolutely necessary.

Frequently Asked Questions

What is wrangler.toml?
wrangler.toml is the configuration file used by Wrangler, the official Cloudflare CLI. It defines how your Cloudflare Workers or Pages Functions are built, configured, and deployed.
How do I create wrangler.toml?
You can create a wrangler.toml file manually in the root of your project repository, or use our generator to visually configure your environments, bindings, and compatibility dates.
Where do I put wrangler.toml?
It typically goes in the root of your repository, next to your package.json.
Should secrets go in wrangler.toml?
No. Never put sensitive secrets (like API keys or database passwords) directly in your wrangler.toml file. Instead, use Wrangler secrets ('npx wrangler secret put KEY_NAME') or the Cloudflare dashboard.
How do I configure Cloudflare Workers environments?
You can define environments using headers like [env.production] or [env.staging] in your wrangler.toml. This allows you to set different variables and bindings for different deployment targets.

How We Keep Your Configs Safe & Valid

Built-in Error Checking

Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.

100% Private & Local

All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.

Secure Settings by Default

Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.

Ready for CI/CD & Git

Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.

Infrastructure as Code

Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.

Monitoring & Tracing

Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.

Container & Docker Safety

Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.

Multiple Output Formats

Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.

Related Tools

Docker Compose Generator

If you are migrating from containers to Workers.