# Known limitations (/docs/compute/limitations)

> For the complete Prisma documentation index, see [llms.txt](https://www.prisma.io/docs/llms.txt). A markdown version of any docs page is available by appending `.md` to its URL.

What Prisma Compute can and can't do.

Location: Compute > Known limitations

This page lists what Prisma Compute can and can't do.

## CLI [#cli]

* The quickest way to run the CLI is `npx prisma <command>` (or `bunx`/`pnpm dlx`), with Node.js 22.18 or newer on the 22 line, 24.11 or newer on the 24 line, or 26 or newer.
* The platform command groups are `auth`, `project` (including `project env`), `postgres`, `bucket`, `branch`, `git`, `service` (including `service version` and `service domain`), and `agent`, plus the root-level [`dev`](https://www.prisma.io/docs/cli/dev) and [`deploy`](https://www.prisma.io/docs/cli/deploy) verbs for Composer apps. The same binary also carries the [Prisma ORM data commands](https://www.prisma.io/docs/cli) (`contract`, `db`, `migration`). There is no `compute` namespace: Compute is managed through the resource groups above.
* Commands are targeted by parameters, not ambient state: the subject resource is the first positional argument, and there is no interactive picker. A missing target fails with a structured error (exit 2) before any network call.
* There is no committed compute config file. A Composer app describes itself, including each service's build, in its module. `.prisma/local.json` is gitignored and only stores your local link to the workspace and project. In CI, pass `--project` and the service name on each command; the CLI does not read a project or service from the environment.

## Projects and branches [#projects-and-branches]

* Project setup is explicit: `--yes` won't create or choose a project for you.
* The first branch in a project is production; the rest are preview by default.
* `branch list` inspects branches; it doesn't create remote state.
* Deleting a branch on GitHub can tear down the matching platform branch, but production and default branches are always left alone.

## Frameworks and runtimes [#frameworks-and-runtimes]

* A [Prisma Composer](https://www.prisma.io/docs/composer) app declares its build explicitly per service (the `node` and `nextjs` build adapters). Neither `deploy` nor the [deploy action](https://www.prisma.io/docs/compute/deploy-on-push) detects your framework or builds for you: you run the build before `deploy`, and the action runs your `build-command` verbatim.
* The [framework guides](https://www.prisma.io/docs/guides) cover Next.js, Nuxt, Astro, Hono, NestJS, TanStack Start, Elysia, and Bun, each deployed as a Composer app.

## Environment variables [#environment-variables]

* Values are write-only: once saved, they are never returned by any surface, and there is no command to pull them into a local `.env`.
* `project env list` returns keys and metadata only.
* Values resolve at deploy time; changing one does not mutate existing versions or trigger a redeploy.
* Production variables can't be branch-scoped.
* Keys must match `[A-Z_][A-Z0-9_]*`; values are non-empty, up to 8 KB.

## GitHub [#github]

* GitHub is the only supported provider, and a project connects to one repository.
* Pushes deploy only through a workflow in your repository, such as one that runs [prisma/cloud-deploy-action](https://github.com/prisma/cloud-deploy-action); see [Deploy on push](https://www.prisma.io/docs/compute/deploy-on-push). Any other CI can deploy with a service token and `deploy`.
* The connection reacts only to branch created and deleted events. There are no PR comments or PR status automation.

## Domains [#domains]

* Custom domains are production-only and CNAME-based: they attach to the default (production) branch, and the service needs a promoted version first.
* Up to 3 custom domains per service.
* There is no workspace-wide domain list in the CLI.

## Logs [#logs]

* `service logs <service>` reads a version's logs (`--version-id <id>` selects one); build output for a deploy is available in the Console.
* It returns `FEATURE_UNAVAILABLE` when the platform can't serve logs for the resolved version.
* Logs stream in time-bounded segments, so direct API clients should expect to reconnect.

## Runtime [#runtime]

* This release focuses on HTTP services. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](https://www.prisma.io/docs/compute/keeping-instances-awake). Compute has no built-in cron scheduler, persistent filesystem, or edge runtime. Scheduled jobs come from Composer's [`cron` building block](https://www.prisma.io/docs/composer/building-blocks#cron), which adds a scheduler service that never scales to zero, or from an external scheduler that calls your service.
* Your service has 60 seconds to start responding to a request. If it sends nothing in that time, the client gets `504 Gateway Time-out` and Compute cancels the request, which surfaces in your handler as the request's abort signal rather than an error. The deadline covers the wait for the first bytes, so a response that has started streaming is not cut off. Move longer work out of the request; see [Request timeout](https://www.prisma.io/docs/compute/request-timeout).
* WebSocket servers are not currently supported. `waitUntil` and `KeepAwakeGuard` only prevent an instance from scaling to zero; they do not change [connection-lifetime limits](https://www.prisma.io/docs/compute/request-timeout) or guarantee continuity through restarts or deployments.
* No multi-region deployments. Each service lives in one region, chosen at creation (`service create --region`): `us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, or `ap-southeast-1`. When you do not choose one, the service takes its project's region, and a project created without a region is in `us-east-1`. The exception is the first [`deploy`](https://www.prisma.io/docs/cli/deploy) of a Composer app: it creates the project only once you set a region, with `prismaCloud({ region })` or `PRISMA_REGION`, and stops with `no deploy region is configured` otherwise.

## Databases and migrations [#databases-and-migrations]

* These docs cover deployment and runtime config only: not schema migrations or data cloning. Databases are managed with the [`postgres` commands](https://www.prisma.io/docs/cli/postgres).
* Don't assume production data is copied into preview branches.
* Don't assume production migrations run automatically on deploy.
* Pass database URLs and other runtime config through [environment variables](https://www.prisma.io/docs/compute/environment-variables).

## Next steps [#next-steps]

* [FAQ](https://www.prisma.io/docs/compute/faq): quick answers to common questions.
* [Get started with the Prisma CLI](https://www.prisma.io/docs/compute/getting-started): your first deploy.

## Related pages

- [`Alchemy`](https://www.prisma.io/docs/compute/alchemy): Provision Prisma Postgres and deploy applications to Prisma Compute in one TypeScript stack.
- [`Deploy Button`](https://www.prisma.io/docs/compute/deploy-button): Add a Deploy with Prisma button that copies a public Composer repository and starts a Composer-managed deployment.
- [`Deployments`](https://www.prisma.io/docs/compute/deployments): How deploys create service versions on Prisma Compute, and how to inspect, promote, roll back, start, and stop them.
- [`Domains`](https://www.prisma.io/docs/compute/domains): Point a custom domain at a production app and the platform verifies DNS and provisions TLS for you.
- [`Environment variables`](https://www.prisma.io/docs/compute/environment-variables): Project configuration that gets injected into your deployments, scoped to production, preview, or a single branch.