Setting the file. One moment.
Subchapter 3.4
references/frameworks.mdMarkdown12 KBView on GitHub
Use this reference when deciding whether and how an app can deploy to Prisma Compute.
Treat @prisma/cli app deploy as the deployment surface. Treat create-prisma as a new-project scaffold that can generate useful defaults and, for some templates, a compute:deploy script.
Compute deploy supports these framework keys:
nextjs
nuxt
astro
hono
nestjs
tanstack-start
custom
bunAuto-detection:
next.config.* or next dependencynuxt.config.* or nuxt dependencyastro.config.* or astro dependencyhono dependencynest-cli.json or @nestjs/core dependency@tanstack/react-start or @tanstack/solid-startframework: "custom" plus build.outputDirectory and build.entrypoint in prisma.compute.ts--entry <path> or --framework bunIf detection is ambiguous, set framework in prisma.compute.ts or pass a supported --framework value. If the app is a source-level plain server, use framework: "bun" plus entry, or pass --framework bun --entry <path>, after verifying the server entrypoint. If the app already produces a runnable Node artifact, use framework: "custom" with build.outputDirectory and build.entrypoint.
| App shape | Deploy command shape | Auto-detected | Required output/entry | Notes |
|---|---|---|---|---|
| Next.js | --framework nextjs | Yes | standalone server.js output | Requires output: "standalone" |
| Nuxt | --framework nuxt | Yes | .output/server/index.mjs | Framework strategy supplies build defaults; a config build block is optional |
| Astro | --framework astro | Yes | standalone Node server artifact | Framework strategy supplies build defaults; a config build block is optional |
| Hono | --framework hono | Yes | Bun entry from main, module, --entry, or src/index.ts | Usually fixed port 8080 in generated config/scripts |
| NestJS | --framework nestjs | Yes | NestJS server artifact | Omit host or bind to 0.0.0.0; a config build block is optional |
| TanStack Start | --framework tanstack-start | Yes | .output/server/index.mjs | Requires Nitro node output |
| Custom artifact | config-backed framework: "custom" | No | configured build.outputDirectory and build.entrypoint | Use for prebuilt/custom-built Node artifacts |
| Bun / plain server | --framework bun --entry <path> | With explicit entry | server entrypoint | Use for Elysia and custom HTTP servers |
| Elysia | --framework bun --entry src/index.ts | No dedicated deploy key | Bun entrypoint | Preserve port/host handling |
| SvelteKit | No deploy framework key | No | Node adapter/prebuilt artifact | Do not deploy vite preview |
| Turborepo | Deploy concrete app targets | No | app-specific entry/output | Prefer prisma.compute.ts with apps |
app build --build-type uses the framework build type. Build types include auto, nextjs, nuxt, astro, nestjs, tanstack-start, custom, and bun.
app run --build-type is local-dev oriented and supports auto, bun, and nextjs. It streams the local dev server and is not proof that the deployed app is reachable through public ingress.
prisma.compute.ts can set framework, entrypoint, HTTP port, env inputs, app root, region, and build settings. A config build block is accepted for every supported framework; all build types are config-backed (nextjs, nuxt, astro, nestjs, tanstack-start, custom, bun; hono builds through the bun strategy). For Nuxt, Astro, and NestJS the framework strategy supplies the default build command and output, so a build block is optional and normally unnecessary, but it overrides those defaults when present. Only custom requires one.
Config snippets below assume:
import { defineComputeConfig } from "@prisma/compute-sdk/config";Compute needs a server process:
@prisma/cli app deploy defaults to the framework’s default HTTP port (3000 for most frameworks, 4321 for Astro) unless --http-port is passed.localhost or 127.0.0.1 for a deployed server; use 0.0.0.0, server.host: true, or the framework equivalent.vite preview.--env, project env, branch env, or external automation.Check host and port together. A listener on the right port but bound to loopback can appear ready while public ingress cannot reach it.
Deploy shape:
bunx @prisma/cli@latest app deploy --framework nextjs --env .envnext.config.ts must include standalone output:
import type { NextConfig } from "next"
const nextConfig: NextConfig = {
output: "standalone",
}
export default nextConfigDo not pass --entry with nextjs; the CLI derives the runtime entrypoint from framework build output.
Do not set HOSTNAME=localhost or HOSTNAME=127.0.0.1 in deploy env. If the standalone server host is overridden, use 0.0.0.0.
Deploy shape:
bunx @prisma/cli@latest app deploy \
--framework hono \
--http-port 8080 \
--env .envConfig shape:
export default defineComputeConfig({
app: {
framework: "hono",
entry: "src/index.ts",
httpPort: 8080,
env: ".env",
},
});Project expectations:
package.json has main or module pointing at the entrypoint, or deploy passes --entry src/index.ts@hono/node-serverprocess.env.PORT and defaults to the same port used by --http-porthostname to localhost or 127.0.0.1; if hostname is set explicitly, use 0.0.0.0Example runtime shape:
const rawPort = (process.env.PORT ?? "").trim()
const parsedPort = rawPort.length > 0 ? Number(rawPort) : Number.NaN
const port = Number.isInteger(parsedPort) ? parsedPort : 8080
serve({ fetch: app.fetch, port })Deploy shape:
bunx @prisma/cli@latest app deploy --framework nestjs --env .envConfig shape:
export default defineComputeConfig({
app: {
framework: "nestjs",
env: ".env",
},
});Project expectations:
nest-cli.json or the @nestjs/core dependency; pass --framework nestjs when neither signal is presentsrc/main.ts or the compiled runtime must start an HTTP serverprocess.env.PORT and default to the same port used by --http-portapp.listen(port) or pass "0.0.0.0"; do not pass "localhost" or "127.0.0.1"app build --build-type nestjs for a Compute artifact check; app run --build-type nestjs is not supported, so use the Nest dev server locallyExample runtime shape:
const port = Number(process.env.PORT ?? "3000")
await app.listen(port)Deploy shape:
bunx @prisma/cli@latest app deploy --framework tanstack-start --env .envExpected vite.config.ts shape:
import { defineConfig } from "vite"
import viteReact from "@vitejs/plugin-react"
import { tanstackStart } from "@tanstack/react-start/plugin/vite"
import { nitro } from "nitro/vite"
export default defineConfig({
plugins: [tanstackStart(), nitro(), viteReact()],
})Preserve these details:
nitro in dependenciesimport { nitro } from "nitro/vite"nitro() in the Vite plugin listtanstackStart()The build command is vite build. The build must produce .output/server/index.mjs, and the production start shape is:
{
"scripts": {
"build": "vite build",
"start": "node .output/server/index.mjs"
}
}Do not deploy TanStack Start as a Bun entrypoint such as src/router.tsx. If .output/server/index.mjs is missing, fix the TanStack/Nitro build path.
Make sure Nitro does not bind only to localhost in deployment. If host env/config is customized, use the framework’s all-interface host setting rather than localhost.
Deploy shape:
bunx @prisma/cli@latest app deploy --framework nuxt --env .envConfig shape:
export default defineComputeConfig({
app: {
framework: "nuxt",
env: ".env",
},
});Nuxt uses Nitro output at .output/server/index.mjs. Keep the Nitro preset compatible with a Node server runtime.
Deploy shape:
bunx @prisma/cli@latest app deploy --framework astro --env .envConfig shape:
export default defineComputeConfig({
app: {
framework: "astro",
httpPort: 4321,
env: ".env",
},
});Astro Compute-style server output usually needs:
import { defineConfig } from "astro/config"
import node from "@astrojs/node"
export default defineConfig({
output: "server",
adapter: node({ mode: "standalone" }),
server: { host: true },
})Use the Bun deploy key for app shapes without a dedicated --framework value:
bunx @prisma/cli@latest app deploy \
--framework bun \
--entry src/index.ts \
--http-port 8080 \
--env .envapp deploy also treats --entry <path> without --framework as a Bun app deploy.
Requirements:
--entry unless package.json main or module points at the runtime entrypointprocess.env.PORT or align --http-port with the fixed listener portElysia example:
const port = Number(process.env.PORT ?? "8080")
app.listen({ port, hostname: "0.0.0.0" })Use framework: "custom" when the app is already built, or when a custom command produces a runnable Node artifact that Compute should stage as-is:
export default defineComputeConfig({
app: {
framework: "custom",
build: {
command: "npm run build",
outputDirectory: "build",
entrypoint: "handler.js",
},
httpPort: 3000,
env: ".env",
},
});Requirements:
build.outputDirectory and build.entrypointbuild.entrypoint relative to build.outputDirectorycommand: null only when the output directory already contains the deployable artifact@prisma/cli app deploy --framework has no svelte framework key. Do not claim SvelteKit is directly deployable with that name.
For frameworks without a dedicated deploy key, use one of these paths:
framework: "custom", or through a supported prebuilt/SDK flow--framework bun --entry <path>SvelteKit should use a Node adapter or another production server artifact. Do not use vite preview as the deployed runtime.
Deploy concrete app packages, not the monorepo root by default. Prefer prisma.compute.ts at the repo root with one apps entry per deploy target.
Checklist:
apps/apiExample config:
export default defineComputeConfig({
apps: {
web: { root: "apps/web", framework: "nextjs" },
api: {
root: "apps/api",
framework: "bun",
entry: "src/index.ts",
httpPort: 3000,
env: "packages/db/.env",
},
},
});Deploy one target:
bunx @prisma/cli@latest app deploy api --branch feature/foo --jsonFlag-only shape after confirming output paths:
bun run build
bunx @prisma/cli@latest app deploy \
--framework bun \
--entry apps/api/dist/src/index.js \
--http-port 3000 \
--env packages/db/.envVerify the actual output path before using this command.