Thank you for the quick response! The ticket has been updated upon new evidence. Please review it and respond.

Thank you for the helpful and quick responses! Neither quite fits the evidence though: every failed build ran in a fresh container with an empty DENO_DIR, so there was no local cache to bust — Deno fetched the URL fresh each time and got corrupt bytes. And we'd rather not relocate the whole environment. We've since added a retry loop around deno cache, which both mitigates and proves the point: today at 16:30Z, attempt 1 on the same URL failed with the brotli error and attempt 2 seconds later fetched it clean — intermittent corruption on the builder egress path for that one object. Still hoping someone from Railway infra can take a look at it. Full logs from all five failed builds available.

Hi — you've already proven the important part (fresh container, empty DENO_DIR, same URL fails then succeeds seconds later → it's the fetch path, not your code). While the builder-egress side is the infra team's to look at, there is a change on your side that removes the problem entirely, because it removes the fetch from the build: stop downloading deno.land/std at build time at all.

1. Vendor the remote modules and commit them. Deno supports this natively — in deno.json:

json

{ "vendor": true }

Then locally run deno install --entrypoint main.ts (deno cache is deprecated in Deno 2; deno install --entrypoint is its replacement). Deno writes every remote module into a vendor/ directory next to your code. Commit that directory. From then on, builds resolve https://deno.land/std@0.132.0/... from vendor/ and never touch the network for those imports — no brotli, no CDN, no egress path. The Deno docs describe "vendor": true specifically as the option for "CI servers, Docker containers" for exactly this reason.

1. Lock it so drift fails loudly instead of silently re-fetching. Commit deno.lock and build with the frozen flag, so a new or changed dependency fails the build rather than triggering a fresh download mid-build:

dockerfile

FROM denoland/deno:2.8.1

WORKDIR /app

COPY deno.json deno.lock ./

COPY vendor ./vendor

COPY . .

RUN deno install --frozen --entrypoint main.ts

CMD ["deno", "run", "-A", "main.ts"]

(Deno 2.8 also has deno ci --prod for the install step; either works.)

1. The failing import itself is worth a look. std@0.132.0/node/internal/streams/from.mjs is the 2022-era Node polyfill layer of the old std library. In Deno 2 the node: built-ins are native, and std moved to JSR (jsr:@std/..., served from jsr.io, a different CDN than deno.land). Something in your dependency graph is still pulling that very old path — deno info main.ts | grep 0.132 will show which import brings it in. Upgrading that one dependency (or replacing https://deno.land/std@0.132.0/node/... with the node: equivalent) drops ~290 deno.land fetches from your build and makes step 1 smaller too.

Net effect: the build becomes deterministic and offline with respect to deno.land, the retry loop can go, and if the builder egress really does have an intermittent brotli issue, it simply stops being your problem. Happy to help trace the 0.132.0 import if deno info output is unclear.