Two CDN updates worth knowing about

Announcements
1

Vercel shipped a couple of CDN improvements on March 5th that are worth highlighting.

1. Update routing rules without a new deployment

You can now create and modify project-level routing rules: things like setting response headers or rewriting requests to an external API without triggering a new deployment. Changes take effect instantly once published.

Project-level routes sit between bulk redirects and your deployment config routes (e.g. vercel.json, vercel.ts, or next.config.js), so the full routing order is now:

  1. Bulk redirects
  2. Project-level routes ā† new
  3. Deployment config routes

These are available on all plans and can be managed via the dashboard, API, CLI, or Vercel SDK.

2. A new CDN dashboard experience

The CDN tab in your project dashboard has been redesigned to bring traffic, caching, and routing into one place. Hereā€™s whatā€™s included:

  • Overview: A live map of global traffic distribution across Vercel regions, plus top-level request volume and cache performance metrics.
  • Caches: A refreshed page for purging content across CDN caching layers (previously buried under project settings).
  • Project-level Routing: The new UI for managing the deployment-free routing rules mentioned above.
2 Likes
2

Thank you for your announcements.
Iā€™m Frontend Developer, especially Iā€™m very familiar with Next.js, Angular.js, Vue.js and Svelte.
May I ask some question?
How quickly do routing rule updates propagate across Vercelā€™s edge network?

Are there limitations or quotas for the number of project-level routing rules per project?

Can project-level routes be used to route traffic to external APIs or microservices?

How does Vercel ensure routing consistency across global edge regions after a rule update?

Can routing rules be tested safely before publishing them to production?

Can project-level routes be used to enforce security headers such as Content-Security-Policy or Strict-Transport-Security?

Are there safeguards to prevent misconfiguration that could expose internal APIs?

1 Like
3

Great questions

4
  1. How quickly do routing rule updates propagate across Vercelā€™s edge network? Routing rules take effect instantly after you publish them across all Vercel Regions.
  2. Are there limitations or quotas for the number of project-level routing rules per project? Project-level routes are available on all plans and include 100 project-level routes per project. In addition, you continue to have 2048 route limit per deployment. Bulk redirects support up to 1 million redirects per project (Pro/Enterprise feature)
  3. Can project-level routes be used to route traffic to external APIs or microservices? Yes, you can use project-level routes for external rewrites e.g., rewrites requests under /api to an external origin. It works the same as deployment-level rewrites but without requiring a redeployment.
  4. How does Vercel ensure routing consistency across global edge regions after a rule update? Vercel ensures consistency through
    • Global propagation of routing rules across all 20 compute regions with a p99 of a couple seconds
    • Within each region, we synchronize all metadata and cache expiry to the second, so all traffic within a region will start serving the new change at the same time.
  5. Can routing rules be tested safely before publishing them to production? Yes. When you create a new project-level rule, it defaults to draft mode. You can test changes while in draft mode, and then publish to production when ready.
  6. Can project-level routes be used to enforce security headers such as Content-Security-Policy or Strict-Transport-Security? Yes, you can modify response headers to set security headers including:
    • Content-Security-Policy for XSS protection
    • Strict-Transport-Security for HTTPS enforcement
    • X-Frame-Options for clickjacking prevention
    • X-Content-Type-Options for MIME type security
    • Custom CORS headers for API access control
  7. Are there safeguards to prevent misconfiguration that could expose internal APIs? Yes. Vercel includes multiple infrastructure and application-level safeguards to reduce the risk of exposing internal services through routing misconfiguration.
    • Network isolation: Routing rules execute in Vercel Regions. They cannot directly access Vercelā€™s internal control-plane services or customersā€™ infrastructure.
    • No implicit access to private networks: Rewrites and routing rules can only target publicly reachable endpoints unless you are intentionally using a private networking feature (e.g., Secure Compute on Enterprise). There is no automatic bridge to your private services.
    • WAF and security layer enforcement: All traffic passing through routing rules is subject to Vercelā€™s security layers (e.g., WAF, DDoS mitigation, Bot Protection where enabled). Routing rules do not bypass these protections.
    • Deployment Protection integration: Features such as Vercel Authentication, Password Protection, and Trusted IPs apply before application logic executes, helping prevent unintended public access to protected deployments.
    • Access controls & RBAC: Only authorized project members can modify routing rules, reducing risk of accidental or unauthorized exposure.
1 Like