Deployments

Every Prisma.Compute update creates a new deployment and walks it through a fail-closed sequence: upload the artifact, start the candidate, verify its preview health endpoint, promote it, confirm the app reports it as latest, verify the stable endpoint — and only then touch the previous deployment.

Health checks and promotion

healthCheck.path gates promotion. A candidate that never answers is destroyed and the previous deployment keeps serving — a failed deploy never takes the app down:

const app = yield* Prisma.Compute("api", {
  project,
  path: "./app",
  port: 3000,
  healthCheck: { path: "/api/health" },
});

When promotion succeeds but the stable endpoint fails verification, alchemy rolls the app back to the previous deployment and destroys the failed candidate. Terminally failed deployments are never restarted or selected as rollback targets.

Old-generation cleanup

By default the previous deployment is kept (stopped) after a successful promotion. destroyOldDeployment: true deletes it once the replacement is fully promoted and healthy:

const app = yield* Prisma.Compute("api", {
  project,
  path: "./app",
  destroyOldDeployment: true,
});

If cleanup fails (e.g. a transient API error), the pending cleanup is persisted and retried on the next deploy — nothing is orphaned.

Env-only redeploys

skipCodeUpload: true creates the next deployment from the previous code artifact — useful when only environment variables changed and rebuilding/uploading would be wasted work:

const app = yield* Prisma.Compute("api", {
  project,
  path: "./app",
  skipCodeUpload: true,
  env: { FEATURE_FLAG: "on" },
});

No-op convergence

Deploys are hash-driven: when the built artifact and configuration are unchanged, reconcile reuses the same healthy deployment instead of creating a new generation — repeat deploys converge to exactly one active deployment.

Where next

• Apps — builds, Effect-native services, and local dev.

Reference:

• Compute API reference
• Deployment API reference