{"id":498262,"date":"2026-10-12T12:28:32","date_gmt":"2026-10-12T09:28:32","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=498262"},"modified":"2026-10-12T12:28:32","modified_gmt":"2026-10-12T09:28:32","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=498262","title":{"rendered":"Astro on Cloudflare: when every prerendered page builds to [object Object] and the build stays green"},"content":{"rendered":"
\n

A green build that produces a 15-byte\u00a0index.html<\/code>\u00a0is a strange thing to look at. The file contains exactly this:<\/p>\n

[object Object]<\/code>
<\/span><\/a><\/div><\/pre>\n
No HTML, no error, no warning, exit code 0. I ran into this while setting up a static site on Astro and Cloudflare Workers. More precisely, I ran into the bug report first:\u00a0withastro\/astro#18009<\/a>\u00a0describes every prerendered page turning into\u00a0[object Object]<\/code>\u00a0when\u00a0nodejs_compat<\/code>\u00a0is enabled with a recent\u00a0compatibility_date<\/code>. The author found out in production. I wanted to know whether my setup was exposed before deciding how to guard against it, so I reproduced it locally.<\/p>\n
The reproduction also turned up something the issue does not mention: the date at which the bug starts is not fixed. It depends on which versions of the toolchain you happen to install.<\/p>\n
The reproduction<\/h3>\n
The issue comes with a four\u2011file reproduction, and I used it as is.<\/p>\n
package.json<\/code>:<\/p>\n
{  \"name\": \"cf-prerender-repro\",  \"type\": \"module\",  \"private\": true,  \"scripts\": { \"build\": \"astro build\" },  \"dependencies\": {    \"@astrojs\/cloudflare\": \"14.3.1\",    \"astro\": \"7.3.2\",    \"wrangler\": \"4.131.2\"  }}<\/code>
<\/span><\/a><\/div><\/pre>\n
astro.config.mjs<\/code>:<\/p>\n
import { defineConfig } from 'astro\/config';import cloudflare from '@astrojs\/cloudflare';export default defineConfig({ output: 'server', adapter: cloudflare() });<\/code>
<\/span><\/a><\/div><\/pre>\n
src\/pages\/index.astro<\/code>:<\/p>\n
---export const prerender = true;---<html><body><h1>hello<\/h1><\/body><\/html><\/code>
<\/span><\/a><\/div><\/pre>\n
And a\u00a0wrangler.toml<\/code>\u00a0whose two settings I changed between runs:<\/p>\n
name = \"r\"compatibility_date = \"2025-10-01\"compatibility_flags = [\"nodejs_compat\"]<\/code>
<\/span><\/a><\/div><\/pre>\n
After\u00a0npm install<\/code>, the resolved versions were astro 7.3.2, @astrojs\/cloudflare 14.3.1, wrangler 4.131.2, workerd 1.20261006.1\u00a0and @cloudflare\/unenv\u2011preset 2.16.2. Each run was\u00a0rm -rf dist && npx astro build<\/code>, then a look at\u00a0dist\/client\/index.html<\/code>.<\/p>\n
Isolating it<\/h3>\n
\n
\n\n\n\n\n\n\n\n\n\n\n
\n
compatibility_date<\/p>\n<\/th>\n
\n
compatibility_flags<\/p>\n<\/th>\n
\n
dist\/client\/index.html<\/p>\n<\/th>\n<\/tr>\n
\n
2025\u201310-01<\/p>\n<\/td>\n
\n
none<\/p>\n<\/td>\n
\n
55\u00a0bytes, correct HTML<\/p>\n<\/td>\n<\/tr>\n
\n
2025\u201310-01<\/p>\n<\/td>\n
\n
nodejs_compat<\/p>\n<\/td>\n
\n
15\u00a0bytes,\u00a0<\/strong>[object Object]<\/strong><\/code><\/p>\n<\/td>\n<\/tr>\n
\n
2025\u201310-01<\/p>\n<\/td>\n
\n
nodejs_compat, disable_nodejs_process_v2<\/p>\n<\/td>\n
\n
55\u00a0bytes, correct HTML<\/p>\n<\/td>\n<\/tr>\n
\n
2025\u201309-30<\/p>\n<\/td>\n
\n
nodejs_compat<\/p>\n<\/td>\n
\n
15\u00a0bytes<\/strong><\/p>\n<\/td>\n<\/tr>\n
\n
2025\u201309-15<\/p>\n<\/td>\n
\n
nodejs_compat<\/p>\n<\/td>\n
\n
15\u00a0bytes<\/strong><\/p>\n<\/td>\n<\/tr>\n
\n
2025\u201309-14<\/p>\n<\/td>\n
\n
nodejs_compat<\/p>\n<\/td>\n
\n
55\u00a0bytes, correct HTML<\/p>\n<\/td>\n<\/tr>\n
\n
2025\u201309-01<\/p>\n<\/td>\n
\n
nodejs_compat<\/p>\n<\/td>\n
\n
55\u00a0bytes, correct HTML<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
Every one of these builds exited with code 0\u00a0and printed no warnings.<\/p>\n
Three things follow from the table.\u00a0nodejs_compat<\/code>\u00a0is required: without it, even a current date builds correctly. The\u00a0disable_nodejs_process_v2<\/code>\u00a0flag is a complete workaround, which points at the\u00a0process<\/code>\u00a0global. And the date matters, but not in the way the issue describes.<\/p>\n
The date boundary moved<\/h3>\n
The issue reports the boundary as 2025\u201309-30\u00a0working and 2025\u201310-01\u00a0broken. With the versions I got from npm, 2025\u201309-30\u00a0was already broken. Bisecting the dates put the boundary between 2025\u201309-14\u00a0and 2025\u201309-15.<\/p>\n
I went looking for that date in\u00a0node_modules<\/code>\u00a0and found it in\u00a0@cloudflare\/unenv-preset<\/code>, the package that decides which Node.js APIs a Worker gets natively and which it gets as polyfills:<\/p>\n
function getProcessOverrides({ compatibilityDate, compatibilityFlags }) {  const disabledV2ByFlag = compatibilityFlags.includes(\"disable_nodejs_process_v2\");  const enabledV2ByFlag = compatibilityFlags.includes(\"enable_nodejs_process_v2\");  const enabledV2ByDate = compatibilityDate >= \"2025-09-15\";  \/\/ ...}<\/code>
<\/span><\/a><\/div><\/pre>\n
The same function also checks a second date, so I cannot claim this line alone decides the outcome. What I can say from the measurements is that the boundary in my environment is 2025\u201309-15, the issue reporter observed 2025\u201310-01, and the difference lines up with this kind of date constant living in a dependency that gets updated independently of your own config.<\/p>\n
That changes how I think about the obvious workaround. \u201cPin\u00a0compatibility_date<\/code>\u00a0to 2025\u201309-30\u201d is advice that was correct for one combination of package versions and wrong for the next. A date pin protects you only as long as nobody upgrades anything underneath it.<\/p>\n
Root cause<\/h3>\n
The fix landed in\u00a0withastro\/astro#18011<\/a>, and its description explains the mechanism. Astro decides whether it is running on Node with this check:<\/p>\n
const isNode = typeof process !== \"undefined\" &&  Object.prototype.toString.call(process) === \"[object process]\";<\/code>
<\/span><\/a><\/div><\/pre>\n
With\u00a0nodejs_compat<\/code>\u00a0and the newer\u00a0process<\/code>\u00a0implementation, workerd’s\u00a0process<\/code>\u00a0passes that check. So during prerendering, which runs inside workerd, Astro takes its Node streaming path. In 7.3.2\u00a0that path looks like this:<\/p>\n
if (streaming) {  if (isNode && !isDeno) {    const nodeBody = await renderToAsyncIterable(result, componentFactory, props, children, true, route);    body = nodeBody;  } else {    body = await renderToReadableStream(result, componentFactory, props, children, true, route);  }}<\/code>
<\/span><\/a><\/div><\/pre>\n
The body is an\u00a0AsyncIterable<Uint8Array><\/code>, which Node’s\u00a0Response<\/code>\u00a0accepts. Workerd’s\u00a0Response<\/code>\u00a0does not support\u00a0AsyncIterable<\/code>\u00a0as a body type, so it converts the object to a string.\u00a0String(someObject)<\/code>\u00a0is\u00a0\"[object Object]\"<\/code>, fifteen characters, and that is what gets written to disk.<\/p>\n
The issue author had already confirmed the corruption was present in the response coming back from the prerender worker, before Astro writes any file. That is also why the build stays green. The\u00a0Response<\/code>\u00a0is constructed successfully with status 200, and from the build’s point of view a page was rendered and saved.<\/p>\n
The fix in 7.3.3\u00a0adds a second runtime check and wraps the iterable in a stream that workerd understands:<\/p>\n
const isWorkerd = typeof navigator !== \"undefined\" &&  navigator.userAgent === \"Cloudflare-Workers\";\/\/ inside the streaming branchif (isWorkerd && !(nodeBody instanceof Response)) {  body = ReadableStream.from(nodeBody);} else {  body = nodeBody;}<\/code>
<\/span><\/a><\/div><\/pre>\n
I upgraded the reproduction to astro 7.3.3\u00a0and @astrojs\/cloudflare 14.3.2\u00a0and rebuilt with\u00a0nodejs_compat<\/code>\u00a0at 2025\u201309-15, 2025\u201310-01\u00a0and 2026\u201309-01. All three produced the correct 55-byte page.<\/p>\n
What I actually put in place<\/h3>\n
For the real project I ended up with three layers, and the date pin is not one of them that I rely on.<\/p>\n
Do not enable\u00a0<\/strong>nodejs_compat<\/strong><\/code>\u00a0unless a dependency needs it.<\/strong>\u00a0The site uses D1\u00a0through its Workers binding, which does not need any Node APIs. Without the flag, the bug cannot trigger regardless of the date. If you do need the flag, adding\u00a0disable_nodejs_process_v2<\/code>\u00a0fixed the reproduction, though it turns off the newer\u00a0process<\/code>\u00a0implementation for your whole Worker.<\/p>\n
Require\u00a0<\/strong>astro >= 7.3.3<\/strong><\/code>.<\/strong>\u00a0Anything below it reintroduces the bug the moment someone turns\u00a0nodejs_compat<\/code>\u00a0on.<\/p>\n
Check the build output itself.<\/strong>\u00a0This is the layer I trust most, because it does not depend on knowing the cause. The build script runs a small check after\u00a0astro build<\/code>:<\/p>\n
\/\/ check-prerender.mjs: fail if any prerendered HTML is tiny or contains \"[object Object]\".import { readdirSync, readFileSync, statSync } from 'node:fs';import { join } from 'node:path';const DIST = process.argv[2] ?? 'dist';const MIN_BYTES = 200;function* walk(dir) {  for (const entry of readdirSync(dir, { withFileTypes: true })) {    const full = join(dir, entry.name);    if (entry.isDirectory()) yield* walk(full);    else if (entry.name.endsWith('.html')) yield full;  }}const problems = [];let count = 0;for (const file of walk(DIST)) {  count++;  const size = statSync(file).size;  if (size < MIN_BYTES) problems.push(`${file}: only ${size} bytes`);  else if (readFileSync(file, 'utf8').includes('[object Object]')) problems.push(`${file}: contains \"[object Object]\"`);}if (count === 0) problems.push(`no .html files under ${DIST}`);if (problems.length > 0) {  console.error(`check-prerender: ${problems.length} problem(s)\\n  ${problems.join('\\n  ')}`);  process.exit(1);}console.log(`check-prerender: ${count} HTML file(s) OK`);<\/code>
<\/span><\/a><\/div><\/pre>\n
wired in as\u00a0\"build\": \"astro build && node check-prerender.mjs\"<\/code>. Against the reproduction, with a page body long enough to clear the size threshold:<\/p>\n
astro 7.3.3:  build exit 0, check-prerender: 1 HTML file(s) OKastro 7.3.2:  build exit 0, check-prerender: 1 problem(s)                dist\/client\/index.html: only 15 bytes              check exit 1<\/code>
<\/span><\/a><\/div><\/pre>\n
The 200-byte threshold is arbitrary. Any real page of mine is far larger, and the broken output is always exactly 15\u00a0bytes, so there is a lot of room. The empty\u2011directory case is checked as well, because a build that silently produces nothing is the same class of failure.<\/p>\n
The production version of this script has grown other checks since, but this part has not changed. It catches this specific bug, and it would catch the next one that breaks prerendering in a different way, as long as the result is a page that is obviously too small or contains a stringified object.<\/p>\n
Takeaways<\/h3>\n