Project: Deploy a Static Website with a Custom Domain

Build the mental model

A static website is the simplest thing you can put into production: HTML, CSS, and JavaScript files that render the same way for every visitor, with no server-side code computing a response per request.

Hosting categories — why plain static hosting fits a files-only project
Git-based deployment — push to main, a fresh deploy follows automatically
Domains and DNS — pointing a custom name at the hosting platform
HTTPS/TLS — encryption that gets provisioned automatically, not by hand

Everything starts with a small project in a git repository. A static hosting platform connects to that repository once, and after that every push to main triggers a fresh deploy of exactly the files in that commit — no manual upload step, ever.

Three companies, one pipeline

The registrar (where you bought the domain), the DNS provider (who hosts your DNS records), and the hosting provider (who serves your files) can all be different companies, connected only by a handful of DNS records you configure once.

The final piece is HTTPS: most static hosts provision a TLS certificate automatically as soon as DNS resolves correctly, turning encryption in transit into a checkbox rather than a manual task.

text

DEPLOY A STATIC SITE WITH A CUSTOM DOMAIN
-----------------------------------------
[GIT REPO]
    |
    | git push to main
    v
[STATIC HOST] <---- CNAME/ALIAS record ---- [DNS PROVIDER]
    |  (builds site, serves via CDN)                ^
    |                                                |
    | auto-provisions TLS cert                       | nameservers
    v                                                | point here
[HTTPS CERTIFICATE]                            [REGISTRAR]
    |                                       (owns the domain name)
    v
[LIVE SITE]
https://yourdomain.com

Connect it to a real scenario

Put the site in a git repository

All static files, no server code. Push to GitHub or a similar host.

Connect a static hosting platform

Most platforms auto-detect a plain HTML project; a framework-based site needs a build command and output directory. First deploy lands on the platform's default subdomain.

Buy a domain and add a DNS record

A registrar sells the domain. At your DNS provider, add the CNAME or ALIAS/ANAME record the hosting platform's dashboard specifies.

Add the domain in the host and wait

DNS propagation can take minutes to about 48 hours, depending on the provider and prior record TTLs.

Confirm automatic HTTPS

Once DNS verifies you own the domain, the platform issues and renews the TLS certificate itself.

From here, every future update is just a git push — the entire pipeline replays automatically.

Static hosting needs no server management — just files behind a CDN
Registrar, DNS provider, and hosting provider can all be different companies
DNS propagation plus automatic HTTPS means the last mile is mostly waiting, not configuring

Try the working example

javascript

function classifyProject(files) {
  const serverOnlyExt = new Set([".php", ".py", ".rb", ".jsp", ".asp", ".aspx", ".pl", ".cgi", ".go"]);
  const flaggedFiles = [];

  for (const file of files) {
    const dot = file.lastIndexOf(".");
    const ext = dot === -1 ? "" : file.slice(dot).toLowerCase();
    if (serverOnlyExt.has(ext)) {
      flaggedFiles.push(file);
    }
  }

  return {
    staticHostable: flaggedFiles.length === 0,
    flaggedFiles,
  };
}

const blogFiles = ["index.html", "styles.css", "script.js", "images/logo.png"];
const mixedFiles = ["index.html", "styles.css", "api/users.php", "admin/login.php"];

console.log("Blog project:", classifyProject(blogFiles));
console.log("Mixed project:", classifyProject(mixedFiles));

You should see

Blog project: { staticHostable: true, flaggedFiles: [] }
Mixed project: {
  staticHostable: false,
  flaggedFiles: [ 'api/users.php', 'admin/login.php' ]
}

5-minute try-it

Take a small static project you already have (or create a 3-file HTML/CSS/JS one). Push it to a git repository, deploy it to a static host of your choice, and — even without owning a real domain — write out the exact DNS record (type, name, value) you would add at a DNS provider to point a domain like myproject.com at that deploy.

One important caution

Pointing the DNS record at the wrong target (e.g. a CNAME to the platform's marketing domain instead of the specific deploy target it documents) — the site never resolves even though the deploy succeeded.

Forgetting that a root/apex domain often can't take a plain CNAME record, and needing an ALIAS/ANAME record or the DNS provider's specific workaround instead.

Cloudflare Pages — Custom domains — Cloud & Deployment