Implementation journal / Real-world deployment

How we deployed the
career portfolio website.

A practical, step-by-step record of the work across Bluehost, Microsoft Azure DNS, Cloudflare DNS, Cloudflare Pages, GitHub and local development—including the purpose of every change, its technical effect and how to verify it.

binitdatta.combinitdatta-careerbinitdatta/binitdattaHTTPS + canonical URL
Overview / Provider responsibilities

From domain name to public website

We separated domain ownership, DNS authority, source control and web hosting. That separation avoids paying for a conventional web server when the site only needs to serve static files.

BluehostDomain ownership & registrar delegation
Azure DNSPrevious authoritative DNS configuration
Cloudflare DNSCurrent authoritative records & proxy
Cloudflare PagesStatic content & global delivery
GitHubVersioned source and updates
Final documented architecture: Bluehost retains domain registration; Cloudflare nameservers are authoritative; the binitdatta-career Pages project serves the website; both binitdatta.com and www.binitdatta.com have TLS; www redirects to the non-www canonical domain.
Accuracy / Documentation provenance

What is confirmed—and what is not

The published repository's web-hosting.html documents the final Cloudflare configuration and the Azure-to-Cloudflare migration. Its README.md confirms the multi-page static site and local testing method. An account dashboard or historical Azure resource inventory would be needed to establish every earlier click and resource name.

Documented

Final production configuration

Nameservers, Pages project, proxied CNAMEs, custom hostnames, SSL status and HTTPS www redirect.

Historical context

Azure DNS → Cloudflare

The original guide records this change, but does not establish Azure zone resource-group names, exact record values or deletion dates.

Verify in account

Deployment method

The repository does not prove whether the Pages project currently uses Git integration, manual uploads or Wrangler.

Implementation integrity: Steps marked “verify” describe where to check or what to do next; they are not presented as confirmed actions taken in the original deployment. Avoid deleting legacy Azure DNS or changing records until all domain services (including email) have been checked.
Phase 01 / Domain registrar

Bluehost: retain ownership, delegate DNS

Documented

Manage binitdatta.com in Bluehost

Open the Bluehost domain management area and locate the registered domain. Bluehost is responsible for registration, renewals and submitting nameserver changes to the registry.

Purpose: Establish control of a human-readable public domain independently of the service that hosts the HTML files.
Documented final setting

Replace the previous Azure DNS nameservers with Cloudflare's assigned pair

In the domain's nameserver settings, select custom nameservers and enter the exact pair assigned by Cloudflare:

abby.ns.cloudflare.com
kanye.ns.cloudflare.com

Save the update. Nameserver changes must be made at the registrar—not by editing the HTML, and not solely by creating NS records inside the old Azure zone.

Purpose: Make Cloudflare the authoritative source for the domain's DNS records, while Bluehost continues to be the registrar.
Verify in account

Review renewal, contact information and domain-lock settings

Confirm that renewal billing and registrant contact email remain valid and that domain transfer protection is appropriately enabled. These settings are not visible in the repository.

Purpose: Prevent accidental expiration or unauthorized loss of the registered domain.
Phase 02 / Earlier architecture

Microsoft Azure DNS: the earlier DNS provider

Historical configuration

Previously host the authoritative DNS zone on Azure DNS

The existing website guide confirms that the Bluehost delegation previously pointed at Azure DNS before the switch to Cloudflare. Azure DNS zones hold DNS records and are assigned Azure nameservers; they do not, by themselves, serve HTML pages.

Purpose: Provide authoritative DNS hosting under Azure management for the domain's earlier configuration.
Verify in Azure

Review the historical DNS zone and its records

In Azure Portal, use DNS zones and search for binitdatta.com. Check the resource group, nameserver assignments, relevant A/CNAME/TXT/MX records and whether the zone still exists.

Purpose: Preserve knowledge of the previous architecture and discover any non-website records that must survive a DNS migration.
Do not assume completed

Assess whether the old Azure zone should be retained or retired

After Cloudflare becomes authoritative, an old Azure zone generally no longer answers public queries for the domain. Remove it only after verifying that there are no remaining dependencies, secondary DNS arrangements or audit-retention requirements.

Purpose: Avoid paying for unused resources without causing mail, verification or service-discovery outages.
Phase 03 / Authoritative DNS cutover

Cloudflare: onboard the domain and publish DNS

Documented architecture

Add binitdatta.com to Cloudflare

Open the Cloudflare dashboard, add the apex domain as a website/zone, choose the applicable plan and review imported or proposed DNS records.

Purpose: Provision Cloudflare authoritative DNS for the domain and obtain the nameservers to configure at Bluehost.
Documented records

Publish proxied CNAME records for the apex and www

The existing guide records these effective settings in the Cloudflare DNS zone:

TypeNameTargetProxy
CNAME@binitdatta-career.pages.devProxied
CNAMEwwwbinitdatta-career.pages.devProxied

Cloudflare supports an apex CNAME through flattening. A proxied record generally returns Cloudflare edge addresses to public A/AAAA resolvers rather than the Pages target hostname.

Purpose: Route visitors for both public hostnames to Cloudflare's network and associate them with the Pages deployment.
Documented delegation

Wait for Cloudflare to detect the Bluehost delegation

After updating Bluehost nameservers, review Cloudflare's zone status and verify that the zone is active. DNS caching means results may not change everywhere at the same instant.

dig NS binitdatta.com +short
dig +trace binitdatta.com NS
Purpose: Confirm the .com registry's delegation directs recursive resolvers to the Cloudflare authoritative nameservers.
Audit recommended

Reconcile every non-website DNS record

Before considering migration complete, compare historical Azure DNS records with Cloudflare records, especially MX, SPF, DKIM, DMARC, domain-verification TXT and any other subdomains. The repository establishes the website records but not a full mail/DNS inventory.

Purpose: Prevent interruptions to services unrelated to the visible career website.
Phase 04 / Static web hosting

Cloudflare Pages: publish the static portfolio

Project documented

Create and use the Pages project binitdatta-career

The current project hostname is binitdatta-career.pages.dev. Cloudflare Pages serves plain HTML, CSS, JavaScript and image assets without maintaining a conventional VM or application server.

Purpose: Provide low-maintenance, globally distributed hosting for the career website's static content.
Repository files

Deploy the complete site directory, preserving paths

The GitHub repository contains index.html, career.html, architecture.html, business-verticals.html, technology.html, books.html, articles.html, videos.html, contact.html, web-hosting.html, styles.css, script.js and the assets/images/ tree.

When creating a new Pages project, use either Git integration or the dashboard's direct-upload workflow as supported in your account. For a root-level static site, there is normally no build command and the output directory is the directory containing index.html. Check the existing project's deployment configuration before changing its method.

Purpose: Preserve relative links and image paths so every page and architecture illustration loads correctly.
Method not confirmed

Confirm whether the project uses Git integration or direct upload

In the binitdatta-career project, inspect the deployment source and deployment history. If connected to GitHub, repository pushes may trigger deployment automatically; if created using direct upload, push events alone do not deploy new files. For direct uploads, deploy the updated directory through the Pages upload flow or the applicable Wrangler command.

Purpose: Establish a repeatable release process rather than assuming that a successful git push also updates the live site.
Phase 05 / Public identity & encryption

Custom domains and HTTPS certificates

Documented active domains

Attach the apex and www hostnames to the Pages project

In Pages project settings, add both binitdatta.com and www.binitdatta.com as custom domains. The published guide states that both became Active.

Purpose: Tell Cloudflare which Pages project should handle HTTPS requests for each hostname.
SSL enabled

Validate SSL/TLS certificate activation

Check the Pages custom-domain status and TLS configuration. Both hostnames are documented with SSL enabled. A visitor's browser validates the certificate for the requested host before rendering the website.

Purpose: Enable encrypted, authenticated browser-to-edge connections and avoid certificate warnings.
Phase 06 / Consistent public URL

Redirect www to the canonical apex domain

Documented rule

Create a Cloudflare Single Redirect (permanent 301)

In the Cloudflare zone's redirect rules, configure the documented HTTPS-www matching pattern to redirect to the non-www domain. Preserve the URL path and, when appropriate, the query string.

Incoming: https://www.binitdatta.com/*
Action:   301 (permanent redirect)
Target:   https://binitdatta.com/${1}
Query:    preserve query string

The ${1} path placeholder applies to the documented wildcard-style rule; the exact syntax differs for Cloudflare expression-based redirect rules. Always verify the actual rule type in the dashboard. The existing guide specifically documents an HTTPS www rule, not proof of an identical HTTP www rule.

Purpose: Ensure visitors and search engines primarily see one consistent public hostname, while preserving deep links.
Test required

Check redirects, deep links and HTTP behavior

curl -I https://www.binitdatta.com/
curl -I https://www.binitdatta.com/architecture.html
curl -I https://binitdatta.com/
curl -I http://www.binitdatta.com/

Expect a redirect response for the HTTPS www form, with a Location on the apex domain. Check plain HTTP separately; HTTPS enforcement may introduce a separate hop.

Purpose: Detect bad redirect patterns, accidental loops, lost paths and inconsistent HTTPS behavior.
Phase 07 / Source version control

GitHub: store, audit and evolve the website

Public repository

Initialize Git and publish the source code

The website source is in github.com/binitdatta/binitdatta, on the main branch. The original local setup used this HTTPS remote URL:

git init
git add .
git commit -m "Initial career website"
git branch -M main
git remote add origin https://github.com/binitdatta/binitdatta.git
git push -u origin main

These commands document the workflow; if the repository already exists, do not rerun git init or git remote add origin blindly.

Purpose: Maintain an auditable history, recover previous versions, share a reusable template and collaborate safely.
Repository content

Maintain architecture images and implementation documentation

The repo includes PROMPTS_README.md, README.md and the portfolio's supporting images. Store this deployment guide alongside web-hosting.html and the other root HTML files.

Purpose: Preserve not only the deployed pages but also the rationale and implementation history behind the website.
Troubleshooting guidance

Diagnose an unsuccessful push without rewriting history

Use git status, git remote -v, git log -1 --oneline and git ls-remote --heads origin main to identify the failure. If the remote already contains an independent commit, fetch and inspect before merging or rebasing. Avoid force-pushing by default.

Purpose: Resolve authentication, connectivity or divergent-history errors while preserving the integrity of both local and remote commits.
Phase 08 / Acceptance testing

Verify each technical layer independently

LayerCheckDesired result
Registration / delegationdig NS binitdatta.com +shortCloudflare assigned nameservers
DNS resolutiondig A binitdatta.com +shortResolvable Cloudflare-proxied endpoint
Pages hostnameVisit https://binitdatta-career.pages.devStatic site responds
Custom domainVisit https://binitdatta.comPortfolio home loads without TLS warning
Canonical hostcurl -I https://www.binitdatta.com/301 to apex when rule matches
Asset integrityOpen developer tools → NetworkNo unexpected HTML/CSS/JS/image 404s
NavigationVisit each top-level HTML pageLinks and architecture images resolve
Deployment lifecycleInspect Pages deployment historyCurrent deployed revision matches intended files
The browser may cache a permanent 301 aggressively. When troubleshooting, compare a fresh private window, curl responses and Cloudflare deployment status before concluding the DNS change failed.
Phase 09 / Day-two workflow

How to update the site next time

Edit files locally and preview

Update the HTML/CSS/images in the project directory, then open the local site with a simple HTTP server.

python3 -m http.server 8000
# Open http://localhost:8000
Purpose: Catch broken links and styling errors before publication.

Commit and push to GitHub

git status
git add .
git commit -m "Update career portfolio"
git push origin main
Purpose: Record exactly what changed and retain the option to revert.

Publish to the existing Cloudflare Pages project

Git-integrated project: confirm the push triggered and completed the Pages deployment. Direct-upload project: use Cloudflare Pages to upload the refreshed site directory (or deploy using your established Wrangler workflow). Avoid accidentally creating a second Pages project.

Purpose: Update the actual production assets—not merely the GitHub repository.

Smoke test production and roll back if needed

Check the apex URL, www redirect, important pages and images. Review Cloudflare Pages deployment history to select a prior successful deployment if a change breaks the site.

Purpose: Confirm visitor experience and provide a recovery path.
Operations / Troubleshooting

What to check when something breaks

Check Bluehost nameserver settings and the parent delegation, Cloudflare zone status and authoritative DNS records. Use dig NS and dig +trace. Remember that old recursive cache entries can survive briefly.

Check whether the Pages project uses direct upload rather than Git integration. Review the project deployment history, production alias and build/output settings. Redeploy the full updated site if needed; a Git push alone does not update a direct-upload deployment.

Inspect both Pages custom-domain statuses and TLS provisioning, confirm DNS records and domain activation, and check restrictive CAA entries if present. Avoid making unrelated DNS changes while certificate issuance is pending.

Inspect the Cloudflare Single Redirect match and target, query preservation and any competing Bulk Redirect, Page Rule or website-level redirect. Test with curl -I and account for cached 301 responses.

Check case-sensitive paths, deployment root, filenames, relative image references and the presence of assets/images/architecture/ in the uploaded output directory. Compare the local site with Pages deployment assets.

Safe validation command bundle

# Domain DNS authority and DNS answers
dig NS binitdatta.com +short
dig +trace binitdatta.com NS
dig A binitdatta.com +short
dig A www.binitdatta.com +short

# HTTP behavior and certificate diagnostics
curl -I https://binitdatta.com/
curl -I https://www.binitdatta.com/
curl -IL https://www.binitdatta.com/architecture.html

# Local Git status and remote
 git status
 git remote -v
 git log -1 --oneline
 git ls-remote --heads origin main
References / Supporting material

Source documents and provider consoles

Security and privacy: This educational guide intentionally excludes account passwords, API tokens, private zone exports and registrar recovery information. It documents publicly visible hostnames and architectural settings, not confidential credentials. Screens and provider menu labels may change over time.