Astro Cloudflare “Fetch API cannot load: /”: Fix Prerender Failures

Find the fetch that runs during the build#

Search application code and integration configuration before changing the adapter:

1
rg -n 'fetch\(|new URL\(|Astro\.url|prerender' src astro.config.mjs
2
pnpm build

Pay attention to code imported by a page with prerender = true, content loaders, layout data functions, and dependencies that perform a request while a module is evaluated. The visible / in the error is the URL that workerd rejected; it may come from your code or a package called by it.

These two cases are different:

1
// Browser-side code: the browser can resolve this against the current page.
2
const response = await fetch('/api/data')
3

4
// Build/server-side code: give the request an absolute URL or avoid the loopback request.
5
const response = await fetch(new URL('/api/data', Astro.url))

The second form still requires the target to exist at build time. For a prerendered page, a direct function or data-layer call is often more reliable than making the build call its own API route. Do not “fix” the message by making every browser fetch absolute; the relevant question is which runtime executes the call.

Understand the Astro Cloudflare runtime boundary#

The current Astro Cloudflare adapter guide documents workerd as the default prerender environment for Astro 6 with adapter v13. The workerd runtime is close to Cloudflare’s production environment, but it does not support every Node API or package shape. CommonJS-only dependencies and packages that assume Node built-ins are frequent reasons to test the alternate environment.

If the failing code genuinely needs Node during prerender, configure the adapter explicitly:

1
import { defineConfig } from 'astro/config'
2
import cloudflare from '@astrojs/cloudflare'
3

4
export default defineConfig({
5
  adapter: cloudflare({
6
    prerenderEnvironment: 'node',
7
  }),
8
})

Use this as a compatibility decision, not a blanket workaround. The option is intended for prerendered pages that depend on Node APIs or packages incompatible with workerd. On-demand pages still run in the Cloudflare runtime after deployment.

Choose the smallest safe repair#

Use the evidence from the failing stack to choose one of these repairs:

Do not add output: 'server' solely because this error mentions Cloudflare. Output mode decides whether routes are prerendered or rendered on demand; it does not automatically make a relative server fetch valid. Choose the output mode from the application’s rendering requirements.

The GitHub issue withastro/astro #16190 shows the same class of Astro 6 + Cloudflare adapter symptom: a workerd build reports Fetch API cannot load: /. The issue was closed without a planned fix because a reproduction was not established, which is why locating the exact call in your project matters more than copying a universal config change.

Rebuild and test both rendering paths#

After the smallest change, rebuild from a clean command boundary:

1
pnpm build

Then verify the result according to the chosen output mode:

• request a prerendered page and confirm its HTML is generated;
• request an on-demand page through the deployed Worker, if the project has one;
• exercise the API or binding-backed route used by the page;
• check that a Node-only dependency did not move into browser code accidentally.

If the site also uses sessions or Cloudflare bindings, keep that deployment concern separate from prerender resolution. The Astro Cloudflare session binding guide covers a binding-specific failure, while the Cloudflare Pages and Workers file-limit guide covers a static output decision.

The reliable sequence is: identify the server-side fetch, decide whether it should be an HTTP request at build time, and use Node prerendering only for a demonstrated compatibility boundary. A successful local build is useful evidence, but the deployed rendering path still needs a request-level check.

FAQ#