Deploy and Connect the Domain

Choose with the production workload in front of you. Check framework support, previews, forms, databases, security controls, traffic limits, support, and the cost of the plan you will actually use.

Vercel: a direct fit for Next.js and the platform used for the n-g.be example. Vercel documents Git-based previews, instant rollback, and automatic DDoS mitigation on every plan. Its Pro platform fee is currently $20 per month and includes $20 of usage credit; usage beyond that is billed.

Netlify: a practical option when integrated forms and database tooling reduce extra setup. Its current Personal plan is $9 per month with 1,000 monthly credits; Pro starts at $20. Credits pay for production deploys, compute, bandwidth, and requests. A production deploy costs 15 credits, so with nothing else running, 1,000 credits cover about 66 merges to main a month. Estimate your deploy rate and real traffic before choosing.

Netlify publicly lists a global CDN, firewall traffic rules, and basic rate limiting. This research did not find a blanket all-plan DDoS statement equivalent to Vercel's. If DDoS exposure drives the decision, confirm the protection and commercial limits directly for your plan.

Prices and allowances above were checked on 18 September 2026. Check the live plan limits before launch and before a planned traffic spike.

Connect the GitHub repository and set the host's production branch to main, or your approved equivalent. A merge to that branch should trigger the production deployment.

Protect the branch in GitHub. Require a pull request, the build, and important status checks before merge. For higher-risk projects, require an approval and successful preview deployment too.

The host should create a preview for each pull request. Review that URL before merge on desktop and mobile. Test navigation, forms, authentication, error states, metadata, and any route changed by the pull request.

Start from the Build the Website guide if the production build, content, or functional handoff is not ready yet.

Add the domain to the hosting project while the existing site still serves visitors. Follow the host's current dashboard instructions for the exact DNS values; do not copy an old A or CNAME value from another project.

Set production environment variables and confirm that preview values cannot write to production by accident. Test forms, authentication callbacks, storage, database connections, analytics, consent behaviour, and outbound email from the production deployment URL.

Choose one canonical hostname. Redirect the other version, such as the apex domain or www, to it. Check active subdomains separately because the main domain redirect does not prove they work.

Give unknown slugs a useful not-found page: search, the main sections, and a link home. It must still return a 404 status; redirecting every unknown URL to the homepage creates soft 404s that search engines treat as errors. Use 301 only for pages that moved, and 410 for content removed on purpose.

Identify who controls the DNS account before scheduling the move. The registrar, DNS provider, website host, and email provider may be different accounts.

Record or export the current DNS zone. Mark which records will change and which must stay untouched, especially MX, SPF, DKIM, DMARC, verification, and service subdomains.

Lower relevant TTLs at least 24-48 hours before the migration, or earlier when the existing TTL is longer. A shorter TTL reduces how long resolvers may keep the previous answer; it does not make every cache update instantly.

Write the rollback trigger, owner, and action. Keep the old deployment available, retain the previous DNS values, and decide how long the observation window lasts before old hosting is removed.

A static site can usually change hosts without planned downtime. A site that accepts accounts, orders, bookings, or other writes needs a separate data plan.

If downtime is unavoidable, show a maintenance page and close sign-ups or other writes first. After the site stops accepting changes, take the final snapshot, record source counts, migrate, then compare destination counts before reopening.

Host rollback only changes the deployed code. It does not automatically reverse a database migration or restore writes made after the cutover. Keep the data rollback plan separate and testable.

Change only the records in the approved plan. Do not delete unrelated records simply because the new host does not display them.

Check the apex domain, www, every active subdomain, HTTPS certificate, canonical redirect, and not-found page. Test from another network or resolver because your own device may still have a cached answer.

Run the business journeys again on the real domain: navigation, forms, sign-in, account creation when open, database writes, downloads, payments when applicable, analytics, consent, and transactional email.

Watch deployment logs, function errors, form submissions, database health, and third-party callbacks throughout the agreed observation window. Check the plan dashboard before a campaign or traffic spike can consume its allowance.

Vercel can reassign production to a previous deployment, while Netlify can publish a previous atomic deploy. Use the host's current rollback control and verify who has permission to run it.

Rollback when an agreed trigger is reached, not when the team starts debating during an incident. Examples include failed sign-in, lost writes, broken checkout, widespread 5xx errors, or an invalid TLS certificate.

Close the launch only after the site remains stable through the observation window, data counts still match, critical journeys pass, and the next normal push-to-production process is clear.

Once the domain and deployment path are stable, install GTM, GA4 and Clarity behind consent, or return to the Publish stage.