Package and version
Prisma ORM 6.19.3; @prisma/client 6.19.3; @prisma/engines-version 7.1.1-3.c2990dca591cba766e3b7ef5d9e8a84796e47ab7. This concerns the public engine artifact delivery endpoint, not Prisma Next.
What happened?
A fixed public engine checksum URL returns HTTP 403 from our existing Ubuntu/WSL download controller.
GET https://binaries.prisma.sh/all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/debian-openssl-3.0.x/schema-engine.gz.sha256
- Client start: 2026-09-10T04:54:26.419016+00:00
- Client finish: 2026-09-10T04:54:28.638730+00:00
- Response Date: Thu, 10 Sep 2026 04:54:32 GMT
- HTTP status: 403
- Server: cloudflare
- CF-Ray: a38bd5d30fe99dfc-LAX
- Content-Type: text/plain; charset=UTF-8
- Content-Length: 17
The response read was bounded to 4096 bytes; 17 bytes were read. Unknown raw error text was not retained. No known fixed denial phrase was identified by our redaction filter. We cannot provide a full raw error body retrospectively.
What did you expect to happen?
Expected: the fixed official checksum artifact is accessible over standard verified HTTPS, or the maintainers can identify the supported access remediation.
Please correlate the Ray IDs/timestamps with the delivery logs and confirm whether the 403 was generated by an edge rule or the origin. We cannot infer the rejecting layer from CF-Ray alone. We are not asking to disable verification, upgrade the pinned build input, or use a third-party mirror.
Minimal reproduction
The failure occurs on a standalone GET of the URL above; no project or database is needed.
Actual downloader: Python urllib.request.build_opener(urllib.request.ProxyHandler({}), NoRedirect()), where NoRedirect is an HTTPRedirectHandler whose redirect_request returns None. It calls opener.open(exact_url, timeout=25), reads at most 4096 bytes, and records HTTPError.code and allowlisted headers.
Standard TLS verification; default urllib request identity; no credentials, custom User-Agent, redirect following, automatic retry loop, proxy substitution, or TLS bypass. The Python version was not recorded in the diagnostic.
Environment
Windows host invoking existing Ubuntu through WSL. Download executed using Ubuntu Python urllib outside the offline project sandbox; this was not a Node HTTP request.
Project toolchain: Node v24.19.0, pnpm 11.19.0, Prisma and @prisma/client 6.19.3. The lock and installed dependency identify @prisma/engines-version 7.1.1-3.c2990dca591cba766e3b7ef5d9e8a84796e47ab7. Requested target: debian-openssl-3.0.x.
No database is involved in this reproduction.
Additional context
An earlier same-path observation at 2026-09-10T03:31:13.240639+00:00 also returned 403, CF-Ray a38b5be29e63cba2-LAX. These were separately authorized bounded attempts, not an automatic retry loop.
We subsequently generated Prisma Client and built the application offline using an existing owner-confirmed cache with matching adjacent checksum records and matching engine version identifiers. This does not establish that official HTTP access has recovered. No dependency version or lock changes were required.
Related: #27700 (2025-07-18, closed, different commits). We do not assume it has the same cause. Searches for our exact commit plus 403 and September 2026 did not return a matching report; that is not proof no report exists.
The repository URL prisma/prisma redirected to prisma/orm. If this public engine-delivery issue belongs in another official tracker, please route it there.
Package and version
Prisma ORM 6.19.3; @prisma/client 6.19.3; @prisma/engines-version 7.1.1-3.c2990dca591cba766e3b7ef5d9e8a84796e47ab7. This concerns the public engine artifact delivery endpoint, not Prisma Next.
What happened?
A fixed public engine checksum URL returns HTTP 403 from our existing Ubuntu/WSL download controller.
GET https://binaries.prisma.sh/all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/debian-openssl-3.0.x/schema-engine.gz.sha256
The response read was bounded to 4096 bytes; 17 bytes were read. Unknown raw error text was not retained. No known fixed denial phrase was identified by our redaction filter. We cannot provide a full raw error body retrospectively.
What did you expect to happen?
Expected: the fixed official checksum artifact is accessible over standard verified HTTPS, or the maintainers can identify the supported access remediation.
Please correlate the Ray IDs/timestamps with the delivery logs and confirm whether the 403 was generated by an edge rule or the origin. We cannot infer the rejecting layer from CF-Ray alone. We are not asking to disable verification, upgrade the pinned build input, or use a third-party mirror.
Minimal reproduction
The failure occurs on a standalone GET of the URL above; no project or database is needed.
Actual downloader: Python urllib.request.build_opener(urllib.request.ProxyHandler({}), NoRedirect()), where NoRedirect is an HTTPRedirectHandler whose redirect_request returns None. It calls opener.open(exact_url, timeout=25), reads at most 4096 bytes, and records HTTPError.code and allowlisted headers.
Standard TLS verification; default urllib request identity; no credentials, custom User-Agent, redirect following, automatic retry loop, proxy substitution, or TLS bypass. The Python version was not recorded in the diagnostic.
Environment
Windows host invoking existing Ubuntu through WSL. Download executed using Ubuntu Python urllib outside the offline project sandbox; this was not a Node HTTP request.
Project toolchain: Node v24.19.0, pnpm 11.19.0, Prisma and @prisma/client 6.19.3. The lock and installed dependency identify @prisma/engines-version 7.1.1-3.c2990dca591cba766e3b7ef5d9e8a84796e47ab7. Requested target: debian-openssl-3.0.x.
No database is involved in this reproduction.
Additional context
An earlier same-path observation at 2026-09-10T03:31:13.240639+00:00 also returned 403, CF-Ray a38b5be29e63cba2-LAX. These were separately authorized bounded attempts, not an automatic retry loop.
We subsequently generated Prisma Client and built the application offline using an existing owner-confirmed cache with matching adjacent checksum records and matching engine version identifiers. This does not establish that official HTTP access has recovered. No dependency version or lock changes were required.
Related: #27700 (2025-07-18, closed, different commits). We do not assume it has the same cause. Searches for our exact commit plus 403 and September 2026 did not return a matching report; that is not proof no report exists.
The repository URL prisma/prisma redirected to prisma/orm. If this public engine-delivery issue belongs in another official tracker, please route it there.