Prolifto
Developer guide

Deployment

Deploy the admin, storefront, and docs with production configuration.

Prolifto deploys as separate Next.js applications. The admin app is the system of record and must be deployed before the storefront.

Applications to deploy

AppRoot directoryNotes
Adminapps/adminAPI, auth, Inngest endpoint, database access
Storefrontapps/storefrontCustomer site; calls the admin API
Docsapps/docsStatic content + generated API reference
Desktopapps/desktopOptional Electron build for the admin

Each app builds with its own next build. The storefront and docs do not need database access to build, but the admin does.

Environment

Set production values in the hosting provider, not in files:

  • DATABASE_URL, BETTER_AUTH_SECRET, NEXT_PUBLIC_APP_URL, NEXT_PUBLIC_FRONTEND_URL.
  • SMTP, Turnstile, storage, Stripe/Polar, AI, SMS, WhatsApp, VAPID, and Inngest credentials as needed.
  • NEXT_PUBLIC_* values are embedded at build time; redeploy after changing them.
  • Keep BETTER_AUTH_SECRET identical across admin and storefront.
  • Use verified sender addresses for SMTP_FROM.

See Environment variables.

Database

Production migrations are guarded:

pnpm db:prod:check
pnpm db:prod:backup
pnpm db:prod:migrate
pnpm db:prod:check
  • db:prod:check is read-only and lists pending migrations.
  • db:prod:backup writes a verified dump to backups/prod/ (git-ignored).
  • db:prod:migrate requires typing MIGRATE; --dry-run prints the command.
  • Never run pnpm db:push against production.
  • Scripts use vercel env run -e production; set PROLIFTO_VERCEL_PROJECT if the project name is not prolifto.

Run migrations before deploying code that depends on them. For zero-downtime changes, use expand/contract migrations (add columns first, backfill, then remove old columns in a later release).

Inngest

  • Deploy the admin app with the Inngest endpoint available.
  • Set INNGEST_EVENT_KEY and INNGEST_SIGNING_KEY.
  • Register the production app with Inngest and verify functions appear.
  • Check the first production run of email, PDF, and order jobs.

Storage and email

  • Point STORAGE_PROVIDER and its credentials at the production provider.
  • Mirror the public URL base in the storefront for images and CSP.
  • Use a real SMTP provider and a verified sender.
  • Verify invoice and receipt PDF generation in production.

Domains and auth

  • Set the admin and storefront public URLs.
  • Configure the storefront root domain and allowed hosts if you use subdomains.
  • Add custom domains in the store, create the TXT record, and verify.
  • Confirm Better Auth cookies and redirects use the production URLs.
  • Configure Google OAuth redirect URIs for the storefront.

Deploying the docs

The docs site builds from committed content and apps/docs/openapi.json.

  1. Start the admin locally.
  2. Run pnpm docs:sync-api to refresh the spec and generated pages.
  3. Review and commit the changes.
  4. Deploy apps/docs as its own project.
  5. Set NEXT_PUBLIC_DOCS_URL and OPENAPI_PUBLIC_SERVER_URL.

The API reference is committed, so the docs build does not need a running admin app.

Post-deploy checks

  • Open the admin and sign in.
  • Check /api/{orgSlug}/health returns ok.
  • Open the storefront and load a product.
  • Place a test COD order and verify it appears in the admin.
  • Send a test email and confirm delivery.
  • Open a generated API reference page.
  • Check the Inngest dashboard for failed runs.

Rollback

  • Roll back the application deployment first.
  • Roll back a migration only with a tested reverse migration and a backup.
  • Keep the previous storage provider reachable until media is migrated.
  • Rotate secrets if a deployment exposed them.

On this page