Launch the site

GoalLink to this section

Deploy Northline with persistent content, working forms and a repeatable release process. Use a staging deployment to rehearse the production settings.

1. Prepare runtime servicesLink to this section

Provision the database selected in src/payload/database.ts. Switching from SQLite to PostgreSQL changes the adapter; it does not move existing content. Use an explicit data migration if local content must move.

Persist uploads and back up both media and the database. A container's temporary filesystem is not a media backup. Keep registry credentials available to the build without committing them.

APP_ENVIRONMENT=production
NEXT_PUBLIC_SERVER_URL=https://example.com
DATABASE_URI=postgresql://user:password@database-host/database

Replace these values and set real Payload, Systhema and email secrets. The URI example assumes you selected the PostgreSQL adapter. Configure that selection with systhema setup database before deployment.

2. Validate the applicationLink to this section

Run from the consumer project:

pnpm sync
pnpm exec tsc --noEmit
pnpm lint
pnpm format
systhema doctor
pnpm build

Resolve failures before deploying. A type check cannot catch every server/client boundary or a misspelled token-driven name at render time.

3. Build when the database is privateLink to this section

If the builder cannot resolve the private database hostname, disable prerendering for the build:

SYSTHEMA_PRERENDER=off pnpm build

generateSysthemaStaticParams then returns no params without starting Payload when the managed catch-all supplies its Payload instance as a getter. Runtime requests still need database access. The first request renders a page and later requests use the route cache; publishing still revalidates content.

Do not patch the managed catch-all to return an empty array. Use the environment flag. Custom code-owned routes that query the database during their own build need their own review.

4. Deploy and migrate in the correct laneLink to this section

The host installs dependencies, syncs generated artifacts and runs the production build. For a direct terminal launch, use the starter's script:

pnpm start

For Railway, configure the direct Next.js start command and pre-deploy migrations described in Deploying.

If this release changes the database schema, apply the project's reviewed migration sequence before exposing new code. Do not accept a schema drop prompt against production by guessing which objects match. See Database migrations and the upgrade recipe.

5. Verify the public deploymentLink to this section

Check the home page and every navigation target while signed out. Test the mobile menu, focus order, reduced motion and content at small and large viewports. Upload an image in Admin and confirm it survives a redeploy.

Submit the enquiry form on the actual production domain. Check email delivery, captcha host settings and the redirect or confirmation. Inspect robots, sitemap, canonical and social metadata.

Run systhema doctor in an environment that can access the configured services. Read each failure; doctor complements the deployment checks, it does not certify the site's content.

Check your workLink to this section

• Production and staging have separate, correct environment values.
• Database and uploaded media survive restarts and have tested backups.
• The production build and health checks pass.
• Published edits become visible without a redeploy.
• Enquiries and password-reset email work on the public domain.

Next: Hand over the site. Keep the going-live checklist with the release record.