Deployment, Domains, DNS, and Maintenance

Deployment moves a verified application version into an online environment. A domain provides a memorable address. DNS connects that name to a service. HTTPS protects the connection. After launch, the application still needs monitoring, updates, backups, and recovery.

1. Separate Local, Preview, and Production

Local runs on a developer computer. Preview deploys a branch or pull request for review. Staging can mirror production for controlled testing when needed. Production serves real users.

Separate databases, credentials, domains, and variables between environments. A preview must not silently read or modify production data. Label environments in provider dashboards so operators can identify the target.

2. Complete the Pre-Deployment Gate

Before deployment, confirm:

• requirements and acceptance criteria are complete;
• the diff was reviewed;
• lint, typecheck, tests, and production build pass;
• environment variables are documented without secrets;
• migrations have an order and rollback plan;
• error, loading, empty, unauthorised, and mobile states were checked;
• debug endpoints and test credentials are absent;
• the repository is pushed to the intended remote.

Deployment does not replace quality checks. A successful build does not prove that auth, data isolation, payments, email, or user journeys work.

3. Connect a Repository to Vercel

Create a Vercel account, connect a Git provider, and import the repository. Check the framework preset, root directory, install command, build command, output settings, and runtime version. Follow repository configuration rather than guessing from a generic tutorial.

Add environment variables through project settings. Assign values separately to Development, Preview, and Production. Never place secrets in vercel.json, a public README, or source code.

4. Manage the Production Database and Migrations

Production uses managed data infrastructure defined by the Technical Foundation. Create a database separate from local and preview. Apply minimum privilege to application credentials.

Run migrations through an auditable process. For risky migrations, prepare a backup, restore verification, a maintenance window when needed, and a compatible deployment sequence. A code rollback cannot recover data already removed by a schema change.

5. First Deployment and Smoke Test

After preview is available, test its URL before promoting to production. A minimum smoke test covers:

• landing and critical routes open;
• sign-in, sign-out, and account recovery work when available;
• safe create, read, update, and delete actions work within scope;
• negative permission cases reject access;
• assets, fonts, metadata, robots, and sitemap are available;
• logs do not expose secrets;
• layout works on desktop and smartphone;
• refreshing a nested route does not return 404.

Record the commit SHA and deployment URL so the result remains traceable.

6. Preview versus Production

Use preview for visual review, acceptance testing, and integration before production. Do not assume a preview is private because its URL is difficult to guess. Enable protection for sensitive material.

Promote only an approved commit. After production deployment, repeat smoke tests against the production domain and inspect logs, errors, and database connectivity.

7. Buy and Connect a Domain

Buy a domain through the deployment provider or a third-party registrar. Use an organisation-owned account for a business domain. Enable multi-factor authentication, recovery contacts, and auto-renewal.

Add the domain to the project first, then apply the DNS records shown by the provider. Common records include A/AAAA for an apex, CNAME for a subdomain, or nameserver delegation. Actual values vary, so do not copy records from an old screenshot.

Do not delete MX, SPF, DKIM, or DMARC records when changing the website if the domain also handles email.

8. DNS, HTTPS, and Callback URLs

DNS changes need time to propagate, and old caches may remain. Check the apex and www, canonical redirects, and the HTTPS certificate. Do not disable HTTPS to bypass temporary configuration problems.

After a domain changes, update the application URL, OAuth callbacks, email links, CORS allowlists, webhooks, cookie domains, analytics, canonical metadata, and sitemap when applicable. Test sign-in from a new session instead of relying on old browser cookies.

9. Rollback and Basic Incident Response

When production fails, stop additional changes, record the time and deployment, then determine whether code, configuration, database, DNS, or the provider caused the issue. Roll back to a healthy deployment when the schema remains compatible.

Do not make many random changes at once. Restore service, preserve evidence, then perform root-cause analysis. Rotate credentials if a secret may have been exposed.

10. Maintenance After Launch

Each week, inspect errors, failed jobs, backups, security alerts, important dependencies, domains, SSL, and resource usage. Each month, review user access, credentials, recovery contacts, provider costs, restore readiness, and stale pages.

New features return through branch, preview, review, test, and production. Never edit production directly because even a small change can affect auth, data, caching, or SEO.

11. Production Ready Checklist

• The production commit is identifiable.
• Variables and secrets belong to the correct environment.
• The production database is separate and backed up.
• Migrations completed and were verified.
• Domain, DNS, HTTPS, redirects, and callbacks are correct.
• Critical smoke tests pass.
• Monitoring and logs are available without exposing sensitive data.
• Rollback and incident ownership are clear.