# Deploy Prisma ORM (/docs/orm/v6/prisma-client/deployment/deploy-prisma)

Location: ORM > v6 > Prisma Client > Deployment > Deploy Prisma ORM

Projects using Prisma Client can be deployed to many different cloud platforms. Given the variety of cloud platforms and different names, it's noteworthy to mention the different deployment paradigms, as they affect the way you deploy an application using Prisma Client.

> [!NOTE]
> Use Prisma ORM without Rust binaries
> 
> If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
> 
> ```prisma
> generator client {
>   provider   = "prisma-client-js" // or "prisma-client"
>   engineType = "client"
> }
> ```
> 
> Prisma ORM without Rust binaries has been [Generally Available](/orm/v6/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
> 
> Note that you need to use a [driver adapter](/orm/v6/overview/databases/database-drivers#driver-adapters) in this case.
> 
> When using this architecture:
> 
> * No Rust query engine binary is downloaded or shipped.
> * The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
> 
> This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/v6/prisma-client/setup-and-configuration/no-rust-engine).
> 
> Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).

Deployment paradigms [#deployment-paradigms]

Each paradigm has different tradeoffs that affect the performance, scalability, and operational costs of your application.

Moreover, the user traffic pattern of your application is also an important factor to consider. For example, any application with consistent user traffic may be better suited for a [continuously running paradigm](#traditional-servers), whereas an application with sudden spikes may be better suited to [serverless](#serverless-functions).

Traditional servers [#traditional-servers]

Your application is [traditionally deployed](/orm/v6/prisma-client/deployment/traditional) if a Node.js process is continuously running and handles multiple requests at the same time. Your application could be deployed to a Platform-as-a-Service (PaaS) like [Heroku](/orm/v6/prisma-client/deployment/traditional/deploy-to-heroku), [Koyeb](/orm/v6/prisma-client/deployment/traditional/deploy-to-koyeb), or [Render](/orm/v6/prisma-client/deployment/traditional/deploy-to-render); as a Docker container to Kubernetes; or as a Node.js process on a virtual machine or bare metal server.

See also: [Connection management in long-running processes](/orm/v6/prisma-client/setup-and-configuration/databases-connections#long-running-processes)

Serverless Functions [#serverless-functions]

Your application is [serverless](/orm/v6/prisma-client/deployment/serverless) if the Node.js processes of your application (or subsets of it broken into functions) are started as requests come in, and each function only handles one request at a time. Your application would most likely be deployed to a Function-as-a-Service (FaaS) offering, such as [AWS Lambda](/orm/v6/prisma-client/deployment/serverless/deploy-to-aws-lambda) or [Azure Functions](/orm/v6/prisma-client/deployment/serverless/deploy-to-azure-functions)

Serverless environments have the concept of warm starts, which means that for subsequent invocations of the same function, it may use an already existing container that has the allocated processes, memory, file system (`/tmp` is writable on AWS Lambda), and even DB connection still available.

Typically, any piece of code [outside the handler](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) remains initialized.

See also: [Connection management in serverless environments](/orm/v6/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas)

Edge Functions [#edge-functions]

Your application is [edge deployed](/orm/v6/prisma-client/deployment/edge) if your application is [serverless](#serverless-functions) and the functions are distributed across one or more regions close to the user.

Typically, edge environments also have a different runtime than a traditional or serverless environment, leading to common APIs being unavailable.

## Related pages

- [`Caveats when deploying to AWS platforms`](https://www.prisma.io/docs/orm/v6/prisma-client/deployment/caveats-when-deploying-to-aws-platforms): Known caveats when deploying to an AWS platform
- [`Deploy migrations from a local environment`](https://www.prisma.io/docs/orm/v6/prisma-client/deployment/deploy-migrations-from-a-local-environment): Learn how to deploy Node.js and TypeScript applications that are using Prisma Client locally.
- [`Deploy to a different OS`](https://www.prisma.io/docs/orm/v6/prisma-client/deployment/deploy-to-a-different-os): Learn how to deploy Node.js and TypeScript applications that are using Prisma Client to a different operating system.
- [`Deploying database changes with Prisma Migrate`](https://www.prisma.io/docs/orm/v6/prisma-client/deployment/deploy-database-changes-with-prisma-migrate): Learn how to deploy database changes with Prisma Migrate.
- [`Edge functions`](https://www.prisma.io/docs/orm/v6/prisma-client/deployment/edge): Learn how to deploy your Prisma ORM-backed apps to edge functions like Cloudflare Workers or Vercel Edge Functions