Deployment and tenancy

Supported distribution modes

Mode	Isolation	Best fit	Upgrade path
Shared SaaS	One application and database; every private row is tenant-scoped and authorization re-resolves membership per request	Pilots and standard campus plans	Move tenant data to dedicated infrastructure
Dedicated	Same signed application artifact with university-specific database, private object store, domain, secrets, and release ring	Enterprise contracts and stricter security review	Customer-managed hosting
Self-hosted	Docker image plus customer-controlled Postgres and S3-compatible storage	Institutions requiring infrastructure control	Customer operates backups, patching, monitoring, and identity integration

Collective.deploymentMode records the contracted mode; it does not create infrastructure by itself. Deployment automation must supply separate database, storage, DNS, and secrets for dedicated installations.

Shared SaaS launch

Configure DATABASE_URL, DIRECT_URL, Neon Auth, PLATFORM_BASE_DOMAIN, PLATFORM_ADMIN_EMAILS, Resend, and private object storage.
Run npm run db:deploy.
Sign in with an allowlisted platform-admin address and open /platform/universities.
Create the university. Guest access is hard-defaulted off and an expiring owner invitation is generated.
Add and verify any custom hostname. Only verified hostnames resolve a tenant.
Confirm /api/ready, then complete the checklist below.

Dedicated launch

Build one immutable image from a reviewed commit, deploy it with a dedicated Postgres database and private bucket, then provision from a reviewed copy of deployment/university.manifest.example.json:

docker build -t registry.example/notera:RELEASE .
docker run --rm --env-file university.env registry.example/notera:RELEASE npx prisma migrate deploy
npm run university:provision -- deployment/university.manifest.json

Use a unique NEON_AUTH_COOKIE_SECRET, storage credentials, email configuration, and observability destination per installation. Never copy production data into a lower environment.

Self-hosted launch

docker compose up --build starts the application, Postgres, and S3-compatible object storage. The sample compose file is a functional starting point, not a production topology. Campus IT must add TLS termination, managed secrets, encrypted backups, bucket lifecycle/versioning, centralized logs, alerting, image scanning, and tested restore procedures.

The current identity adapter uses Neon Auth. A fully disconnected installation requires an institution-specific identity adapter to be implemented and tested; the SAML/OIDC metadata model alone does not replace the runtime identity provider.

Release and rollback

Run migrations as a one-shot job before new application replicas receive traffic.
Deploy immutable, digest-pinned images. Record image digest and migration in the change ticket.
Use /api/health for liveness and /api/ready for dependencies and configuration.
Back up the database before migrations. Roll back application code only when the schema migration is backward compatible; otherwise restore into a new database and validate before DNS cutover.
Run npm run retention:preview before enabling the scheduled retention job.

Next: implementation checklist