Deployment Checklist

Run through this list before and after every production publish. Pair it with docs/security-headers.md for header reference.

See also: docs/operations.md (monitoring, rate limiting, load testing) and docs/backup-restore-drill.md.

Live domain: https://helixsecure.co.uk Preview domain: https://id-preview--63235da5-c4ee-4c9c-bfcd-d9c11fc268b0.lovable.app

1. Pre-deploy

• bunx tsc --noEmit clean (the harness runs builds automatically — confirm no errors in the build panel).
• bun run test green — includes src/lib/__tests__/security-headers.test.ts covering both NODE_ENV=production and dev profiles.
• No new lint / DB linter warnings (Lovable Cloud → Database → Linter).
• cloud_status reports ACTIVE_HEALTHY for the target environment.
• All new migrations applied and reviewed (no destructive DROP without a backup plan).
• Secrets configured in Lovable Cloud for any new env vars (no VITE_ prefix on secrets).
• SENTRY_DSN is set in Project Settings → Secrets (see docs/sentry.md).
• Auth settings: HIBP enabled, email confirmation ON, redirect URLs include the live domain.

2. Environment

• NODE_ENV=production on the live deployment. This is what flips src/start.ts into the strict header profile (HSTS preload, COOP/CORP, upgrade-insecure-requests, no 'unsafe-eval'). Do not override it on the production target.
• NODE_ENV is not set to production in local dev — Vite HMR requires the relaxed CSP ('unsafe-eval', ws:, localhost).
• Preview deployments may run with NODE_ENV=production; confirm HMR is not expected there.

3. Publish

• Click Publish → Update in the Lovable editor (frontend changes require an explicit update; backend/edge changes deploy automatically).
• Wait for the publish to finish, then hard-reload the live domain.

4. Post-deploy verification

4a. Header check via curl

Run from any shell:

curl -sI https://helixsecure.co.uk/ \
  | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer|permissions|cross-origin'

Expect to see (production profile):

• strict-transport-security: max-age=31536000; includeSubDomains; preload
• content-security-policy: default-src 'self'; …; upgrade-insecure-requests
• x-frame-options: DENY
• x-content-type-options: nosniff
• referrer-policy: strict-origin-when-cross-origin
• permissions-policy: camera=(), microphone=(), geolocation=()
• cross-origin-opener-policy: same-origin
• cross-origin-resource-policy: same-origin

If strict-transport-security is missing, NODE_ENV is not production — stop and fix the environment before continuing.

4b. Per-route override spot-check

Sensitive routes ship tighter headers (see docs/security-headers.md). Verify at least one:

curl -sI https://helixsecure.co.uk/reset-password \
  | grep -iE 'cache-control|referrer-policy|content-security-policy'

Expect:

• cache-control: no-store, no-cache, must-revalidate
• referrer-policy: no-referrer
• content-security-policy containing script-src 'self' (no 'unsafe-inline'/'unsafe-eval').

Repeat for /login, /signup, /forgot-password, /verify-email — each should return cache-control: no-store and referrer-policy: no-referrer.

4c. External grading

• Run https://securityheaders.com/?q=https%3A%2F%2Fhelixsecure.co.uk%2F&followRedirects=on. Target grade: A or higher. Anything below A means a header regressed — diff against src/start.ts.
• Run https://www.ssllabs.com/ssltest/analyze.html?d=helixsecure.co.uk after any TLS / domain change. Target: A or higher.
• (Optional) https://csp-evaluator.withgoogle.com/ — paste the live CSP and confirm no new High findings.
• Watch csp_reports for the first ~30 min after publish — a burst of new entries means the deploy broke a CSP-allowed source. See docs/csp-reports.md for the SQL query and triage steps.

4d. Smoke tests (manual, ~2 min)

• Sign up with a new email, receive verification, log in.
• Reset password flow end-to-end.
• Create / edit a policy threshold; confirm history row appears.
• Owner-only: view + create a webhook.
• Open DevTools → Console: zero CSP violations on a clean session.

5. Rollback

If post-deploy checks fail:

1. Revert via Lovable's version history (Publish dialog → previous version).
2. Re-run section 4 against the rollback.
3. File a follow-up task with the failing header / route before re-publishing.

Quick reference