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?

Great questions

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.