← all posts

2026-06-21 · 6 min read · migration, dns, hosting

Migrating logansmith.us off Wix to GitHub Pages (without breaking email)

My personal site lived on a paid builder for years. It was fine — but it was also $204/year for what is essentially a handful of static pages. I'm a security engineer with a GitHub habit and a homelab; paying subscription pricing to host flat HTML started to feel silly. So I moved it to GitHub Pages for $0, kept my domain exactly where it was, and — most importantly — never dropped a single email along the way.

Here's the playbook, including the gotchas that bit me.

The key insight: hosting and email are separate

The thing that makes a migration like this safe is realizing your domain does three independent jobs:

Website hosting is controlled by a couple of DNS records (A for the apex, CNAME for www). Email is controlled by completely different records (MX, SPF/TXT, DKIM). As long as you only touch the first set, email keeps working as if nothing happened. That was my hard rule for the whole project.

Step 1 — Build and publish first, point DNS last

The cardinal rule of a cutover: never repoint the domain at an empty destination. I built the new static site, pushed it to a public repo, and enabled GitHub Pages so it was already live at the *.github.io URL. Only once I'd confirmed it rendered did I touch DNS.

Step 2 — Connect the custom domain

In the repo, GitHub Pages lets you set a custom domain, which writes a CNAME file into the repo. For an apex domain like logansmith.us, GitHub publishes a set of A records to point at:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

And www becomes a CNAME to <username>.github.io. Crucially, this all stays at my existing DNS host — no nameserver migration, so the email records never move.

Step 3 — Change exactly two records

At the DNS host I changed the apex A record(s) to the GitHub IPs and the www CNAME to my GitHub Pages target. I left everything else — the MX records, the SPF TXT, and the mail-provider verification records — completely alone. A quick way to prove email is safe before and after:

dig +short logansmith.us MX
dig +short logansmith.us A

If the MX answer is identical before and after your change, your mail path is untouched.

The gotchas

Browser/OS DNS caching. Right after the change, my browser still showed the old site. That's not a failure — recursive resolvers and your own machine cache the old records until the TTL expires. Querying an authoritative nameserver directly (or a public resolver like 1.1.1.1) shows the truth immediately.

HTTPS certificate timing. GitHub only requests a TLS certificate after your DNS resolves to them. So for a little while you'll see a certificate-name mismatch. If it seems stuck (because an earlier attempt failed while DNS still pointed elsewhere), the reliable fix is to remove the custom domain in the Pages settings and re-add it — that re-triggers a fresh certificate request now that DNS checks out.

HSTS surprises. If your old host set HSTS, your browser will refuse plain HTTP and demand a valid cert — which makes that cert-provisioning window look scarier than it is. It clears itself the moment the certificate lands.

The result

If you've been paying builder pricing to host static pages, this is one of the highest-leverage afternoons you can spend. Just remember the one rule: touch the website records, never the mail records.

← back to all posts