cloudflare build do not work not working | Astro Lounge | Page 1

sage raptor Mar 27, 2026, 2:40 PM

#

im using latest astro version but the build command do not work well. in dev mode i can see the website but on preview mode after build all the page have no content (all white)

astro config
// @ts-check
import { defineConfig } from 'astro/config';

import react from '<@&1055234544183287879>/react';

import tailwindcss from '@tailwindcss/vite';

import cloudflare from '<@&1055234544183287879>/cloudflare';

// https://astro.build/config
export default defineConfig({
integrations: [react()],

vite: {
plugins: [tailwindcss()]
},
output:"static",

adapter: cloudflare(),
});

wrangler
{
"compatibility_date": "2026-03-27",
"compatibility_flags": [
"global_fetch_strictly_public"
],
"name": "__",
"main": "<@&1055234544183287879>/cloudflare/entrypoints/server",
"assets": {
"directory": "./dist",
"binding": "ASSETS"
},
"observability": {
"enabled": true
}
}

rocky chasmBOT Mar 27, 2026, 2:40 PM

#

Hi @sage raptor. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Looking at your config, I can spot the likely issue: you have output: "static" set, but you're also using the Cloudflare adapter. For a static site, you don't need the adapter at all, and the adapter's wrangler entrypoint (@astrojs/cloudflare/entrypoints/server) is meant for server-rendered (on-demand) deployments.

Here are the two paths to fix this:

Option 1: Pure Static Site (no adapter needed)

If all your pages are static, remove the adapter entirely:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
import tailwindcss from '@tailwindcss/vite';

export default defineConfig({
  integrations: [react()],
  vite: {
    plugins: [tailwindcss()]
  },
  output: 'static',
  // No adapter needed
});

And use a simpler wrangler.jsonc for static assets: [Cloudflare Workers deploy]

{
  "name": "my-astro-app",
  "compatibility_date": "2026-03-27",
  "assets": {
    "directory": "./dist"
  }
}

Option 2: Server-Side Rendering (keep the adapter)

If you want on-demand/server rendering, switch to output: 'server' and keep the adapter: [output config]

// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
import tailwindcss from '@tailwindcss/vite';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  integrations: [react()],
  vite: {
    plugins: [tailwindcss()]
  },
  output: 'server',
  adapter: cloudflare(),
});

#

Root cause summary: The `@astrojs/cloudflare` adapter's server entrypoint (`@astrojs/cloudflare/entrypoints/server`) is designed for server-rendered pages. Using it with `output: "static"` causes a mismatch — the adapter expects server output but your build produces static files, resulting in blank pages in preview. [adapter mismatch error]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:05 PM

#

@rocky chasm this is my wrangler:
{
"main": "dist/_worker.js/index.js",
"name": "...",
"compatibility_date": "2026-03-31", // Update to the day you deploy
"compatibility_flags": [
"nodejs_compat",
"global_fetch_strictly_public"
],
"assets": {
"binding": "ASSETS",
"directory": "./dist"
},
"observability": {
"enabled": true
}
}

this my astro cnfig:
import tailwindcss from '@tailwindcss/vite';

import cloudflare from '<@&1055234544183287879>/cloudflare';

// https://astro.build/config
export default defineConfig({

integrations: [react()],

vite: {
plugins: [tailwindcss()]
},
output: 'server',
adapter: cloudflare(),
});
and i get this two error: when i try to build:
[ERROR] [config] The provided Wrangler config main field (...\dist_worker.js\index.js) doesn't point to an existing file

and 17:58:21 [ERROR] Continuing with previous valid configuration

rocky chasmBOT Mar 31, 2026, 4:05 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

The error occurs because you're using the old Astro 5 wrangler entrypoint (dist/_worker.js/index.js), but with Astro 6 and @astrojs/cloudflare v13+, the main field should point to the new unified entrypoint instead.

Update your wrangler.jsonc to use the new entrypoint: [wrangler entrypoint change]

{
  "main": "@astrojs/cloudflare/entrypoints/server",
  "name": "...",
  "compatibility_date": "2026-03-31",
  "compatibility_flags": [
    "nodejs_compat",
    "global_fetch_strictly_public"
  ],
  "assets": {
    "binding": "ASSETS",
    "directory": "./dist"
  },
  "observability": {
    "enabled": true
  }
}

The key change is replacing:

"main": "dist/_worker.js/index.js"

with:

"main": "@astrojs/cloudflare/entrypoints/server"

This single entrypoint handles both `astro dev` and production deployments in Astro 6. [wrangler entrypoint change]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:08 PM

#

@rocky chasm now build but when i try to preview it give me this error:
The latest compatibility date supported by the installed Cloudflare Workers Runtime is "2026-03-17",
but you've requested "2026-03-31". Falling back to "2026-03-17"...
18:06:37 [ERROR] Error: Disallowed operation called within global scope. Asynchronous I/O (ex: fetch() or connect()), setting a timeout, and generating random values are not allowed within global scope. To fix this error, perform this operation within a handler. https://developers.cloudflare.com/workers/runtime-apis/handlers/
at file:///[REDACTED]/dist/server/chunks/BaseLayout_D-ordnBn.mjs:11932:1
GET / 500 Internal Server Error (60ms)
18:06:38 [ERROR] Error: Disallowed operation called within global scope. Asynchronous I/O (ex: fetch() or connect()), setting a timeout, and generating random values are not allowed within global scope. To fix this error, perform this operation within a handler. https://developers.cloudflare.com/workers/runtime-apis/handlers/
at file:///[REDACTED]/dist/server/chunks/BaseLayout_D-ordnBn.mjs:11932:1
GET / 500 Internal Server Error (2ms)

Cloudflare Docs

Handlers

Methods, such as fetch(), on Workers that can receive and process external inputs.

rocky chasmBOT Mar 31, 2026, 4:08 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

The compatibility date warning is harmless (just update it to 2026-03-17 or earlier to avoid the fallback message), but the real error is the important one:

"Disallowed operation called within global scope"

This means your code (in BaseLayout) is executing something asynchronous — like a fetch(), setTimeout(), or Math.random() — at the top level of a module, outside of any request handler. Cloudflare's workerd runtime does not allow this.

This is a code issue in your project, not a configuration issue. Common causes include:

Calling fetch() at the top level of a component or layout (outside a function/handler)
Using Math.random() or crypto.randomUUID() at module initialization time
Setting a timeout at the top level

How to fix it: Move any async operations (fetch calls, random value generation, timers) inside a function that runs per-request, such as inside your Astro component's frontmatter (--- block), an API route handler, or a React component's render/effect.

For example, instead of:

// ❌ Top-level fetch (not allowed in workerd)
const data = await fetch('<https://api.example.com/data'>).then(r => r.json());

Do:

---
// ✅ Inside the Astro frontmatter (runs per request)
const data = await fetch('<https://api.example.com/data'>).then(r => r.json());
---

#

The knowledge sources note that the `workerd` runtime (now used in both `astro dev` and `astro preview` in Astro 6) enforces this restriction strictly, and issues like this would previously only appear in production. [dev server workerd] You'll need to inspect your `BaseLayout` component and find what's being called at module scope.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:09 PM

#

@rocky chasm this is my baseLayout

import "../styles/global.css";

interface Props {
title?: string;
lang?: string;
}

const { title = "CS Edilizia", lang = "it" } = Astro.props;

<!doctype html>
<html lang={lang}>
<head>
<meta charset="utf-8" />
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
<link rel="icon" href="/favicon.ico" />
<meta name="viewport" content="width=device-width" />
<meta name="generator" content={Astro.generator} />
<title>{title}</title>
</head>
<body>
<slot />
</body>
</html>

rocky chasmBOT Mar 31, 2026, 4:10 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

Your BaseLayout component looks completely fine — there's no fetch(), Math.random(), or any async operation at the top level. The issue is not in this file.

The error points to line 11932 of the compiled BaseLayout_D-ordnBn.mjs chunk, which suggests that a dependency bundled into that chunk is the culprit — likely a library imported by one of your other components or pages that gets tree-shaken into the same output chunk as your layout.

What to check next:

Look at the pages/components that use BaseLayout — check if any of them (or their imports) call fetch(), Math.random(), crypto, or set timers at the module's top level.
Check your npm dependencies — some libraries execute code at import time (e.g., initializing a client, generating a random ID, making a network request). These will fail in Cloudflare's workerd runtime.
Enable unminified output to get better error details. Add this to your astro.config.mjs: [local preview]

export default defineConfig({
  adapter: cloudflare(),
  vite: {
    build: {
      minify: false,
    },
  },
});

This will make the stack trace point to a more readable line, helping you identify exactly which library or module is causing the issue.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:14 PM

#

inside server/chunk/astro_assets.js there is one fetch. and in image transform enpoint there are 2 fetch @rocky chasm

rocky chasmBOT Mar 31, 2026, 4:14 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

The knowledge sources don't contain specific information about astro_assets.js or the image transform endpoint internals, so I can't give you a definitive answer about those specific files.

However, based on the error you're seeing ("Disallowed operation called within global scope"), the issue is that a fetch() call is being executed at module initialization time (top-level), rather than inside a request handler.

What I can suggest based on the knowledge sources:

The Cloudflare workerd runtime strictly forbids async I/O outside of handlers. This is a known behavior difference that Astro 6 now surfaces during development. [dev server workerd]

Practical next steps to investigate:

Enable unminified builds to get clearer stack traces pointing to the exact line: [local preview]

export default defineConfig({
  adapter: cloudflare(),
  vite: {
    build: {
      minify: false,
    },
  },
});

Check if you're using Astro's image optimization — if you have <Image /> components or image services configured, those may be triggering fetches at module scope in the workerd environment.
Consider opening an issue on the @astrojs/cloudflare GitHub repository if the fetch calls in astro_assets.js and the image transform endpoint are part of Astro's own internals, as this may be a bug in the adapter itself rather than something in your code.

#

The knowledge sources don't provide enough detail for me to confirm whether this is a bug in Astro's internals or something triggered by your project's configuration.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:16 PM

#

@rocky chasm im using <Image /> all over the site but they should just compile

rocky chasmBOT Mar 31, 2026, 4:16 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

Since you're using <Image /> throughout your site and want images to be compiled at build time (not transformed at runtime), you should set imageService: 'compile' in your Cloudflare adapter config. This uses local transformation at build time for prerendered routes and avoids any runtime image fetch calls that could trigger the "global scope" error. [imageService option]

// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
import tailwindcss from '@tailwindcss/vite';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  integrations: [react()],
  vite: {
    plugins: [tailwindcss()],
    build: {
      minify: false, // optional, for better error messages
    },
  },
  output: 'server',
  adapter: cloudflare({
    imageService: 'compile',
  }),
});

Note that with imageService: 'compile', the passthrough (no-op) option is automatically configured for any on-demand rendered pages — meaning images on those pages won't be transformed. [imageService option]

This should eliminate the runtime `fetch()` calls from the image transform endpoint that were likely causing your "Disallowed operation called within global scope" error.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:21 PM

#

@rocky chasm now i get only these: The latest compatibility date supported by the installed Cloudflare Workers Runtime is "2026-03-17",
but you've requested "2026-03-31". Falling back to "2026-03-17"...
18:20:36 [ERROR] Error: Disallowed operation called within global scope. Asynchronous I/O (ex: fetch() or connect()), setting a timeout, and generating random values are not allowed within global scope. To fix this error, perform this operation within a handler. https://developers.cloudflare.com/workers/runtime-apis/handlers/
at file:///[path]/dist/server/chunks/BaseLayout_ChszNFDe.mjs:11932:1
GET / 500 Internal Server Error (44ms)

Cloudflare Docs

Handlers

Methods, such as fetch(), on Workers that can receive and process external inputs.

rocky chasmBOT Mar 31, 2026, 4:21 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

The error persists even after switching to imageService: 'compile', and it's still pointing to the same compiled chunk (BaseLayout_ChszNFDe.mjs:11932). This strongly suggests the problematic fetch() is coming from a third-party dependency that gets bundled into that chunk — not from Astro's image service.

Since the knowledge sources don't contain enough detail to identify the exact culprit, here's what I'd recommend to narrow it down:

1. Enable unminified builds for a readable stack trace: [local preview]

export default defineConfig({
  adapter: cloudflare({
    imageService: 'compile',
  }),
  vite: {
    build: {
      minify: false,
    },
  },
});

After rebuilding and running astro preview, the error will point to a human-readable line, making it much easier to identify which library is calling fetch() at module scope.

2. Fix CommonJS dependencies — the knowledge sources note that the workerd runtime does not support CommonJS (require, module.exports), and some dependencies may execute code at import time. If you identify the offending package, you can pre-bundle it using optimizeDeps.include: [dev server workerd]

function noExternalPlugin() {
  return {
    name: "optimize-dependencies",
    configEnvironment(environment) {
      if (environment !== 'client') {
        return {
          optimizeDeps: {
            include: ["your-problematic-package"]
          }
        }
      }
    }
  }
}

#

The key next step is enabling `minify: false` and rebuilding — the stack trace will then tell you exactly which package is the source of the global-scope `fetch()`.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:26 PM

#

@rocky chasm all the error i sent to you ARE with the minified set to false

rocky chasmBOT Mar 31, 2026, 4:26 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

You're right, I apologize for the repeated suggestion. Since minify: false is already set and the error still points to line 11932 of the compiled chunk, the stack trace itself isn't giving us a clear library name.

At this point, the knowledge sources don't contain enough information for me to identify exactly which dependency is calling fetch() at module scope in your specific project.

What I can confirm from the knowledge sources:

The workerd runtime does not support CommonJS syntax or async I/O at global scope. If a dependency is the cause, you can try pre-bundling it with optimizeDeps.include: [dev server workerd]

function noExternalPlugin() {
  return {
    name: "optimize-dependencies",
    configEnvironment(environment) {
      if (environment !== 'client') {
        return {
          optimizeDeps: {
            include: [
              "the-offending-package"
            ]
          }
        }
      }
    }
  }
}

To identify the offending package, I'd suggest:

Open dist/server/chunks/BaseLayout_ChszNFDe.mjs directly and go to line 11932 — since minification is off, you should be able to read the code there and see which library it belongs to.
Once identified, either pre-bundle it with the above plugin, or check if there's a workerd-compatible alternative.

#

Beyond this, I'd recommend opening an issue on the `@astrojs/cloudflare` GitHub repository with your full setup, as this may be a known compatibility issue with a specific package. [official integrations]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Mar 31, 2026, 4:27 PM

#

the line is pointing is this: new AbortController(); @rocky chasm

rocky chasmBOT Mar 31, 2026, 4:27 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

The knowledge sources don't contain specific information about AbortController usage in Cloudflare's workerd runtime or how Astro handles it internally, so I can't give you a fully evidence-based answer on this specific issue.

What I can say is that new AbortController() itself is a standard Web API and should be supported in workerd — the issue is that it's being called at module initialization time (top level), not inside a request handler. The workerd runtime forbids this even for otherwise-supported APIs when they involve certain operations.

What to do next:

Look at the surrounding code at line 11932 in BaseLayout_ChszNFDe.mjs to identify which library is instantiating AbortController at the top level. It will likely be a third-party package bundled into that chunk.
Once you identify the package, try pre-bundling it using optimizeDeps.include to force Vite to pre-compile it, which can resolve top-level execution issues: [dev server workerd]

function noExternalPlugin() {
  return {
    name: "optimize-dependencies",
    configEnvironment(environment) {
      if (environment !== 'client') {
        return {
          optimizeDeps: {
            include: ["the-offending-package"]
          }
        }
      }
    }
  }
}

If the package is one you control, move the new AbortController() call inside a request handler function rather than at module scope.

#

Beyond this, I'd recommend reporting the issue on the `@astrojs/cloudflare` GitHub with the full context, as the knowledge sources don't provide enough detail to resolve this further. [Cloudflare adapter]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@sage raptor Kapa.ai is still learning and improving, please let me know how I did by reacting below.

sage raptor Apr 2, 2026, 1:11 PM

#

@rocky chasm the problem was the output:"server".
now for some reason if i use import { env } from 'cloudflare:workers';
it woek perfectly but vscode give me an error: Cannot find module 'cloudflare:workers' or its corresponding type declarations.ts(2307)
there are some type i have to change?

rocky chasmBOT Apr 2, 2026, 1:11 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

This is a TypeScript typing issue. You need to run wrangler types to generate the TypeScript types for your Cloudflare bindings, which will make VS Code recognize cloudflare:workers and your environment variables. [Cloudflare typing]

Run it once manually:

npx wrangler types

Then, to keep types in sync automatically, update your package.json scripts to run wrangler types before every command: [Cloudflare typing]

{
  "scripts": {
    "dev": "wrangler types && astro dev",
    "start": "wrangler types && astro dev",
    "build": "wrangler types && astro check && astro build",
    "preview": "wrangler types && astro preview",
    "astro": "astro"
  }
}

`wrangler types` generates TypeScript type definitions based on your `wrangler.jsonc` and `.dev.vars` files, so VS Code will know about `cloudflare:workers` and all your bindings. Remember to re-run it every time you change your Wrangler configuration.

#cloudflare build do not work not working

Option 1: Pure Static Site (no adapter needed)

Option 2: Server-Side Rendering (keep the adapter)

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

This single entrypoint handles both astro dev and production deployments in Astro 6. [wrangler entrypoint change]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

@rocky chasm this is my baseLayout

const { title = "CS Edilizia", lang = "it" } = Astro.props;

This will make the stack trace point to a more readable line, helping you identify exactly which library or module is causing the issue.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

The knowledge sources don't provide enough detail for me to confirm whether this is a bug in Astro's internals or something triggered by your project's configuration.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

This should eliminate the runtime fetch() calls from the image transform endpoint that were likely causing your "Disallowed operation called within global scope" error.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

The key next step is enabling minify: false and rebuilding — the stack trace will then tell you exactly which package is the source of the global-scope fetch().

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Beyond this, I'd recommend opening an issue on the @astrojs/cloudflare GitHub repository with your full setup, as this may be a known compatibility issue with a specific package. [official integrations]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Beyond this, I'd recommend reporting the issue on the @astrojs/cloudflare GitHub with the full context, as the knowledge sources don't provide enough detail to resolve this further. [Cloudflare adapter]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

wrangler types generates TypeScript type definitions based on your wrangler.jsonc and .dev.vars files, so VS Code will know about cloudflare:workers and all your bindings. Remember to re-run it every time you change your Wrangler configuration.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

This single entrypoint handles both `astro dev` and production deployments in Astro 6. [wrangler entrypoint change]

This should eliminate the runtime `fetch()` calls from the image transform endpoint that were likely causing your "Disallowed operation called within global scope" error.

The key next step is enabling `minify: false` and rebuilding — the stack trace will then tell you exactly which package is the source of the global-scope `fetch()`.

Beyond this, I'd recommend opening an issue on the `@astrojs/cloudflare` GitHub repository with your full setup, as this may be a known compatibility issue with a specific package. [official integrations]

Beyond this, I'd recommend reporting the issue on the `@astrojs/cloudflare` GitHub with the full context, as the knowledge sources don't provide enough detail to resolve this further. [Cloudflare adapter]

`wrangler types` generates TypeScript type definitions based on your `wrangler.jsonc` and `.dev.vars` files, so VS Code will know about `cloudflare:workers` and all your bindings. Remember to re-run it every time you change your Wrangler configuration.