Astro Middleware vs. Adapter Static Asset Serving: Auth Bypass Risk in Hybrid Rendering

Integration Boundary

Astro's hybrid rendering mode (output: 'hybrid') splits routes into prerendered static pages and server-rendered endpoints. Middleware is intended to provide cross-cutting concerns like authentication, but the framework delegates static asset serving to the deployment adapter (Node, Vercel, Netlify, Cloudflare). This creates an integration boundary where middleware execution guarantees diverge from developer expectations.

Constraints and Uncertainty

Prerendered pages generate HTML at build time; middleware never executes for them at runtime. Static files in public/ are served directly by the adapter, bypassing Astro middleware entirely. The astro:config:setup API cannot distinguish static from dynamic routes at build time, so middleware authors cannot automatically skip auth checks for prerendered pages without maintaining manual route lists. Adapter behavior varies: the Node adapter runs middleware for all requests, while edge adapters may skip middleware for static assets.

Questions

1. Which deployment adapters guarantee middleware execution for every request path, including public/ assets and prerendered routes?
2. Is there a supported pattern to declaratively exclude static assets from middleware without hardcoding path lists?
3. How should library authors document middleware behavior when the framework provides no stable protected route convention?