Setting the file. One moment.
Subchapter 3.10
references/runtime-requirements.mdMarkdown5 KBView on GitHub
What a service must do to run on Prisma Compute, and the platform limits it must design around.
CRITICAL
A deploy can converge cleanly and still serve nothing: a loopback listener is unreachable, a slow handler gets a 504 from the ingress, and a sleeping instance stops background work. None of these show up as deploy errors.
bun build --target=bun or another bundler that inlines all dependencies. A build that leaves packages as imports needs dependencies: "external" on node() (Composer 0.29.0 and later).Temporal. A service that reads Prisma ORM DateTime columns as Temporal values compiles, deploys, then fails on the first read. Import a polyfill at the server entry or use string column types.service.port() (default 3000). The runtime also exports it as PORT.0.0.0.0. Compute routes external HTTP to the VM; a localhost or 127.0.0.1 listener looks started but is unreachable.Bun.serve({ port: service.port(), hostname: "0.0.0.0", fetch: handler });The ingress gives a request 60 seconds to start responding. If nothing comes back, the client gets 504 Gateway Time-out (a short openresty HTML body) and Compute cancels the request. Your handler sees only its abort signal (req.signal); no error is logged.
200 or 202 before processing.AbortSignal.timeout) under 60 seconds so your own error handling runs first.waitUntil, or persist a job and process it in steps from a separate trigger. Compute does not run scheduled jobs; the trigger is an external scheduler or the Composer cron module.prisma-composer-core-concepts skill warns that the ingress buffers streamed responses. Send the first bytes early and test a streaming route on a stage before relying on it.Idle instances scale to zero: the platform snapshots memory and resumes from it on the next request. Requests are unaffected, but setTimeout, setInterval, and floating promises can stall mid-flight. Do not build schedulers on setInterval inside a service.
@prisma/compute keeps an instance awake on a best-effort basis:
import { KeepAwakeGuard, waitUntil } from "@prisma/compute";
waitUntil(processJob(job), { signal: AbortSignal.timeout(10 * 60_000) });
async function processBatch() {
using guard = new KeepAwakeGuard({ signal: AbortSignal.timeout(30_000) });
await doWork();
}signal caps how long the instance stays awake; it does not cancel the work.finally with guard.release() where using is unavailable.Scale to zero closes idle database connections. A long-lived client that treats a dropped connection as fatal crash-loops through 502s. Keep pools small and reconnect-friendly, and log instead of exiting:
const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 });
process.on("uncaughtException", (err) => console.error("uncaughtException", err));
process.on("unhandledRejection", (err) => console.error("unhandledRejection", err));A call into a sleeping service can get ECONNRESET during the cold start; retry it. The generated Composer RPC client already does.
us-east-1, us-west-1, eu-west-3, eu-central-1, ap-northeast-1, or ap-southeast-1./rpc/<method> of a Composer contract returns 401 to anything except the services wired to it. That is the service-key check, not a broken deploy.app.post("/webhook", async (c) => {
await processForTwoMinutes(await c.req.json());
return c.text("done");
});The caller gets a 504 after 60 seconds, and the instance can sleep while the work continues.
app.post("/webhook", async (c) => {
const job = await c.req.json();
waitUntil(processForTwoMinutes(job), { signal: AbortSignal.timeout(5 * 60_000) });
return c.body(null, 202);
});