Changelog

Cloudflare has supported both RSA and ECDSA certificates across our platform for a number of years. Both certificates offer the same security, but ECDSA is more performant due to a smaller key size. However, RSA is more widely adopted and ensures compatibility with legacy clients. Instead of choosing between them, you may want both – that way, ECDSA is used when clients support it, but RSA is available if not.

Now, you can upload both an RSA and ECDSA certificate on a custom hostname via the API.

curl -X POST https://api.cloudflare.com/client/v4/zones/$ZONE_ID/custom_hostnames \
    -H 'Content-Type: application/json' \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
    -d '{
    "hostname": "hostname",
    "ssl": {
        "custom_cert_bundle": [
            {
                "custom_certificate": "RSA Cert",
                "custom_key": "RSA Key"
            },
            {
                "custom_certificate": "ECDSA Cert",
                "custom_key": "ECDSA Key"
            }
        ],
        "bundle_method": "force",
        "wildcard": false,
        "settings": {
            "min_tls_version": "1.0"
        }
    }
}’

You can also:

• Upload an RSA or ECDSA certificate to a custom hostname with an existing ECDSA or RSA certificate, respectively.

• Replace the RSA or ECDSA certificate with a certificate of its same type.

• Delete the RSA or ECDSA certificate (if the custom hostname has both an RSA and ECDSA uploaded).

This feature is available for Business and Enterprise customers who have purchased custom certificates.

We have upgraded and streamlined Cloudflare Rules limits across all plans, simplifying rule management and improving scalability for everyone.

New limits by product:

• Bulk Redirects
  • Free: 20 → 10,000 URL redirects across lists
  • Pro: 500 → 25,000 URL redirects across lists
  • Business: 500 → 50,000 URL redirects across lists
  • Enterprise: 10,000 → 1,000,000 URL redirects across lists
• Cloud Connector
  • Free: 5 → 10 connectors
  • Enterprise: 125 → 300 connectors
• Custom Errors
  • Pro: 5 → 25 error assets and rules
  • Business: 20 → 50 error assets and rules
  • Enterprise: 50 → 300 error assets and rules
• Snippets
  • Pro: 10 → 25 code snippets and rules
  • Business: 25 → 50 code snippets and rules
  • Enterprise: 50 → 300 code snippets and rules
• Cache Rules, Configuration Rules, Compression Rules, Origin Rules, Single Redirects, and Transform Rules
  • Enterprise: 125 → 300 rules

We're introducing Custom Errors (beta), which builds on our existing Custom Error Responses feature with new asset storage capabilities.

This update allows you to store externally hosted error pages on Cloudflare and reference them in custom error rules, eliminating the need to supply inline content.

This brings the following new capabilities:

• Custom error assets – Fetch and store external error pages at the edge for use in error responses.
• Account-Level custom errors – Define error handling rules and assets at the account level for consistency across multiple zones. Zone-level rules take precedence over account-level ones, and assets are not shared between levels.

You can use Cloudflare API to upload your existing assets for use with Custom Errors:

curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_pages/assets" \
--header "Authorization: Bearer <API_TOKEN>" \
--header 'Content-Type: application/json' \
--data '{
  "name": "maintenance",
  "description": "Maintenance template page",
  "url": "https://example.com/"
}'

You can then reference the stored asset in a Custom Error rule:

curl --request PUT \
"https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets/phases/http_custom_errors/entrypoint" \
--header "Authorization: Bearer <API_TOKEN>" \
--header 'Content-Type: application/json' \
--data '{
  "rules": [
		{
			"action": "serve_error",
			"action_parameters": {
				"asset_name": "maintenance",
				"content_type": "text/html",
				"status_code": 503
			},
			"enabled": true,
			"expression": "http.request.uri.path contains \"error\""
		}
	]
}'

Added new records to the leaked credentials database from a third-party database.

The new Snippets code editor lets you edit Snippet code and rule in one place, making it easier to test and deploy changes without switching between pages.

What’s new:

• Single-page editing for code and rule – No need to jump between screens.
• Auto-complete & syntax highlighting – Get suggestions and avoid mistakes.
• Code formatting & refactoring – Write cleaner, more readable code.

Try it now in Rules > Snippets ↗.

Rules Overview gives you a single page to manage all your Cloudflare Rules.

What you can do:

• See all your rules in one place – No more clicking around.
• Find rules faster – Search by name.
• Understand execution order – See how rules run in sequence.
• Debug easily – Use Trace without switching tabs.

Check it out in Rules > Overview ↗.

The latest cloudflared build 2024.12.2 ↗ introduces the ability to collect all the diagnostic logs needed to troubleshoot a cloudflared instance.

A diagnostic report collects data from a single instance of cloudflared running on the local machine and outputs it to a cloudflared-diag file.

For more information, refer to Diagnostic logs.

Now, you can manage Cloudflare Snippets with Terraform. Use infrastructure-as-code to deploy and update Snippet code and rules without manual changes in the dashboard.

Example Terraform configuration:

resource "cloudflare_snippet" "my_snippet" {
	zone_id  = "<ZONE_ID>"
	name = "my_test_snippet_1"
	main_module = "file1.js"
	files {
		name = "file1.js"
		content = file("file1.js")
	}
}

resource "cloudflare_snippet_rules" "cookie_snippet_rule" {
	zone_id  = "<ZONE_ID>"
	rules {
		enabled = true
		expression = "http.cookie eq \"a=b\""
		description = "Trigger snippet on specific cookie"
		snippet_name = "my_test_snippet_1"
	}
	depends_on = [cloudflare_snippet.my_snippet]
}

Learn more in the Configure Snippets using Terraform documentation.

Now, you can use Cloud Connector to route traffic to your R2 buckets based on URLs, headers, geolocation, and more.

Example setup:

curl --request PUT \
"https://api.cloudflare.com/client/v4/zones/{zone_id}/cloud_connector/rules" \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '[
  {
    "expression": "http.request.uri.path wildcard \"/images/*\"",
    "provider": "cloudflare_r2",
    "description": "Connect to R2 bucket containing images",
    "parameters": {
      "host": "mybucketcustomdomain.example.com"
    }
  }
]'

Get started using Cloud Connector documentation.

It’s now easy to create wildcard-based URL Rewrites. No need for complex functions—just define your patterns and go.

What’s improved:

• Full wildcard support – Create rewrite patterns using intuitive interface.
• Simplified rule creation – No need for complex functions.

Try it via creating a Rewrite URL rule in the dashboard.

Now, you can create common rule configurations in just one click using Rules Templates.

What you can do:

• Pick a pre-built rule – Choose from a library of templates.
• One-click setup – Deploy best practices instantly.
• Customize as needed – Adjust templates to fit your setup.

Template cards are now also available directly in the rule builder for each product.

Need more ideas? Check out the Examples gallery in our documentation.