Websites

Prisma.Website builds your frontend with its own framework and deploys it to Prisma Compute. The shared @alchemy.run/frontend-frameworks Node targets produce the server and assets; Prisma runs that output on Bun, uploaded as a tar.gz artifact. There is no Docker build, registry, or container image to manage.

Even fully static sites run a static-file server on Compute. These resources do not publish an assets-only deployment to a global CDN.

Omit project and the live deployment creates a Prisma.Project with createDatabase: false. Pass an existing project to put the site next to other apps or a database. alchemy dev runs the framework’s native dev server instead; the Website creates no Prisma project, database, app, or domain in that mode.

What’s supported

Framework	Resource	Guide
React / Vue / Solid SPA	Vite	Vite
TanStack Start (React & Solid)	TanStackStart	TanStack Start
React Router	ReactRouter	React Router
SolidStart	SolidStart	SolidStart
Astro SSR & static	Astro	Astro
Next.js	Nextjs	Next.js
vinext	Vinext	vinext
Nuxt	Nuxt	Nuxt
SvelteKit	SvelteKit	SvelteKit
Waku	Waku	Waku
OctaneJS	Octane	Octane
Foldkit	Foldkit	Foldkit
Vocs	Vocs	Vocs
Hugo, Zola, or any static generator	StaticSite	Static sites

How to choose

Use the resource named after your framework. It understands the framework’s config, output layout, build, and dev server. Config files load natively; deploy-specific overrides belong in option bags such as astro, nuxt, kit, or vite.

Use Vite for client-only SPAs and multi-page HTML apps. SSR frameworks that use Vite still need their own resources. Use StaticSite for a shell command that emits a directory of files.

Shared props are rootDir, memo, env, assets, dev, domain, and project. Framework-specific configuration belongs in the named option bags, not in a Dockerfile or Compute build command.

The framework guides explain the adapter requirements: Astro and SvelteKit get injected adapters; Nuxt and SolidStart use the managed Nitro Node preset; Octane requires the shared node() marker adapter. Next.js runs a normal Next server on Bun, not OpenNext.

Runtime dependencies are traced from the installed application into the archive; Prisma does not run a package installation after upload. Native addons must be built for Prisma’s Linux runtime. A deployment from macOS does not cross-compile native dependencies, so use a compatible Linux build environment for applications that require them.

Install

Set up Prisma credentials for live deployments. Install the build integration in your frontend project:

bun add -d @alchemy.run/frontend-frameworks @vercel/nft

Keep the framework’s own dependencies and config. The integration is loaded from your project at build time; @vercel/nft traces the runtime dependencies for Prisma’s artifact. Both are build-time dependencies. In a monorepo, make the integration available to the frontend project and the tracing peer available to the deployment workspace. Each framework guide includes equivalent npm, pnpm, and yarn commands.

Declare a Website

alchemy.run.ts

import * as Prisma from "alchemy/Prisma";

export const Website = Prisma.Website.Vite("Website", {
  rootDir: "./app",
});

rootDir defaults to ".". Builds are memoized from input content; memo controls which changes trigger a rebuild.

Add it to the Stack

alchemy.run.ts

import * as Alchemy from "alchemy";
import * as Effect from "effect/Effect";

export default Alchemy.Stack(
  "MyWebsite",
  { providers: Prisma.providers(), state: Alchemy.localState() },
  Effect.gen(function* () {
    const site = yield* Website;
    return { url: site.url };
  }),
);

The result is { url, compute, project, domain }. site.url is the Compute endpoint on deploy and the local dev-server address during alchemy dev; the three backing resources are undefined during native dev. domain is also undefined when no custom hostname is requested. Alchemy.localState() keeps state on this machine; keep that state available for subsequent deploys and teardown.

Share a project

Declare a project Effect when several sites should share one:

export const Site = Prisma.Project("Site", { createDatabase: false });

Pass that Effect to the Website; it is resolved only on the live path:

export const Website = Prisma.Website.Vite("Website", { project: Site });

You can also pass an existing project ID. The Website does not create or own a project supplied by ID.

Environment variables

Top-level env is applied before build and dev, and passed to Compute for the live runtime. It is process environment, not Worker bindings. Server code reads process.env; browser inlining follows the framework’s rules (VITE_*, NEXT_PUBLIC_*, or PUBLIC_*). Never put secrets in client-visible keys.

const site = yield* Prisma.Website.Vite("Web", {
  env: { VITE_API_URL: api.url },
});

A Website’s automatically created project has no database. For a project with its default database, Prisma supplies DATABASE_URL and DATABASE_URL_POOLED to Compute; leave those system-managed keys out of env. For an independently managed database, use a Connection and pass its outputs explicitly.

Local development

bun alchemy dev

Framework resources run their native dev servers with HMR. dev options configure the local server; the Website does not create cloud resources. StaticSite can run a supplied dev.command, or build and serve files locally. Sibling resources in the Stack retain their own lifecycle.

Opt a Website into live deployment during dev explicitly:

export const Website = Prisma.Website.Vite("Website").pipe(
  Alchemy.remote(),
);

Custom domains

const site = yield* Prisma.Website.Astro("Web", {
  domain: "app.example.com",
});

domain creates a Prisma.CustomDomain and changes site.url to https://app.example.com. Prisma requires the app to be attached to the project’s current default branch.

Domain provisioning is asynchronous. site.domain is the created CustomDomain resource. Configure its dnsRecords with your DNS provider and inspect status, foundryStatus, and failureReason before sending production traffic. Alchemy does not automatically create DNS records. Changing an existing domain’s hostname or app is rejected; add a second domain, verify DNS and TLS, cut traffic over, then remove the old one. See Compute custom domains.

Where next

• Vite — client builds, SPA routing, and env inlining.
• Astro — SSR and fully static sites.
• Static sites — build commands and 404 handling.
• Compute apps — lower-level builds and Effect-native services.
• Deployments — upload, health checks, and promotion.
• Postgres and Connections.
• Vite example.