Changelog

Rate limiting for applications, static sites, and load balancers#

You can now protect your services from abusive traffic with built-in rate limiting, enforced by Cloudflare at the edge before requests ever reach your service.

When enabled, each visitor is limited to 100 requests per minute, counted per IP address, per domain, and per Cloudflare data center. Each combination has its own counter, so the limit caps individual abusive clients rather than the total traffic your service receives - a service with several domains, or an attack spread across many IPs or locations, can still exceed 100 requests per minute in aggregate. When a visitor exceeds the limit, we apply the action you choose:

• Challenge - visitors must pass a Cloudflare managed challenge to continue. Mitigation lasts 5 minutes.
• Throttle - requests over the limit are blocked only while the rate stays above the limit. Traffic resumes as soon as the rate drops.
• Ban - visitors that exceed the limit are blocked for 5 minutes.

You'll find the new Rate limiting section on your service's Networking tab. Static sites and load balancers get a brand-new Networking tab with this release - for static sites, the CDN/Edge cache purge also moved there from Settings.

Rate limiting requires an enabled primary domain with active or pointing status, and changes take effect within about a minute. See the docs for applications, static sites, and load balancers.

More control over how cron jobs run#

Cron jobs now expose two Kubernetes scheduling controls, so a run that hangs can no longer quietly wedge your schedule - the exact situation that used to leave a cron job stuck after a deploy until you recreated it.

Concurrency policy - decide what happens when a run is triggered while the previous one is still going:

• Forbid (default) - skip the new run until the current one finishes. Nothing changes for your existing cron jobs.
• Replace - cancel the still-running job and start a fresh one. This is the self-healing option: a stuck run gets cleared on the next tick instead of blocking every run after it.

Max run time - optionally cap how long each scheduled run may take. If a run exceeds it, Kubernetes terminates it. Leave it empty (or set 0) for no limit.

Both settings live in your process settings and through the API - see Create process and Update process. They apply to cron processes only.

Railpack build type (beta)#

You can now build your applications with Railpack, the successor to Nixpacks. Railpack analyzes your repository and builds an optimized container image with zero configuration, powered by BuildKit.

To try it, choose Railpack as the build type in your application's build settings (Settings > Build strategy > Update build strategy). It is also available through the public API by setting build_type to railpack.

Railpack detects and builds Node, Python, Go, PHP, Java, Ruby, .NET, Deno, Rust, and Elixir out of the box. Custom start commands work the same way as with other build types: if your web process has a start command set, it overrides the one Railpack detects.

Railpack support is currently in beta. Nixpacks remains the default build type for new applications.

Purge your CDN cache in one click#

Serving stale content after a deploy or an upload? You can now clear it yourself — no need to wait for the cache to expire or reach out to support.

We've added a new Cache section to the settings of both static sites and object storage. Head to Settings → Cache and hit Purge cache to instantly clear the cached assets served from our global CDN.

• Static sites — purges the CDN/Edge cache for your site. Reach for it right after a deploy when updated assets aren't showing up yet.
• Object storage — purges the CDN cache for your bucket, so freshly uploaded or replaced objects are served immediately.

The purge takes effect right away, and you'll get a confirmation the moment the cache is cleared. Available to anyone with update access to the service.

Faster deploys with clearer upload progress#

We've made a round of optimizations to how static sites are deployed, and your deploys are now noticeably quicker. Across 264 sites, deploy time dropped by 32.84% on average - the typical deploy went from 82.51s down to 56.6s. Nothing changes in how you deploy. Push your code as usual and the speedup is automatic.

Deploy logs are clearer, too. You'll now see a live upload progress bar so you can follow exactly how far along your upload is, instead of waiting on a silent step. Each deploy prints the total number of files being uploaded, a progress bar that advances with file count and total size, and a closing summary with the final count, size, and how long it took. If any files fail, they're clearly flagged.

⬆️  Uploading 1842 files...
   [████████████░░░░░░░░]  60% · 1105/1842 files · 24.3 MB
✅ Uploaded 1842 files (41.2 MB) in 18.7s