<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://www.androos.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://www.androos.io/" rel="alternate" type="text/html" /><updated>2026-08-13T00:30:44+02:00</updated><id>https://www.androos.io/feed.xml</id><title type="html">androos.io</title><subtitle>Homelab, self-hosting, and developer tooling.</subtitle><author><name>Neil Andrews</name></author><entry><title type="html">Pointing a domain at GitHub Pages through Cloudflare</title><link href="https://www.androos.io/2026/08/pointing-a-domain-at-github-pages/" rel="alternate" type="text/html" title="Pointing a domain at GitHub Pages through Cloudflare" /><published>2026-08-13T00:00:00+02:00</published><updated>2026-08-13T00:00:00+02:00</updated><id>https://www.androos.io/2026/08/pointing-a-domain-at-github-pages</id><content type="html" xml:base="https://www.androos.io/2026/08/pointing-a-domain-at-github-pages/"><![CDATA[<p>Standing up a GitHub Pages site on a custom domain is mostly mechanical: create
a repo named <code class="language-plaintext highlighter-rouge">&lt;user&gt;.github.io</code>, push something to <code class="language-plaintext highlighter-rouge">main</code>, and add a <code class="language-plaintext highlighter-rouge">CNAME</code>
file naming the domain. GitHub picks the domain up from that file on every
build, which also means deleting the file silently unsets the custom domain.</p>

<p>The DNS side is where it gets interesting if your nameservers are Cloudflare.</p>

<h2 id="the-records">The records</h2>

<p>A <code class="language-plaintext highlighter-rouge">CNAME</code> on <code class="language-plaintext highlighter-rouge">www</code> pointing at <code class="language-plaintext highlighter-rouge">&lt;user&gt;.github.io</code>, plus four <code class="language-plaintext highlighter-rouge">A</code> records on the
apex if you want the bare domain to redirect:</p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
</code></pre></div></div>

<h2 id="the-part-that-bites">The part that bites</h2>

<p>Leave every one of those records <strong>unproxied</strong>, the grey cloud rather than the
orange one, until GitHub finishes issuing the TLS certificate.</p>

<p>GitHub provisions certificates through an ACME challenge served over plain
HTTP at the domain. With Cloudflare proxying in front, that challenge never
reaches GitHub’s infrastructure, so issuance never completes and the <em>Enforce
HTTPS</em> checkbox stays greyed out indefinitely. There is no error message
pointing at the proxy. The setting just sits there disabled.</p>

<p>Once the certificate lands, you can turn the proxy back on, provided SSL/TLS
mode is set to Full (strict).</p>

<h2 id="apex-records-and-mail">Apex records and mail</h2>

<p>If the apex already carries MX records, use <code class="language-plaintext highlighter-rouge">A</code> records there rather than a
<code class="language-plaintext highlighter-rouge">CNAME</code>. Cloudflare’s CNAME flattening does make an apex CNAME technically
work alongside MX, but there is no reason to introduce that interaction when
four <code class="language-plaintext highlighter-rouge">A</code> records do the job with no special behavior involved.</p>]]></content><author><name>Neil Andrews</name></author><category term="dns" /><category term="github-pages" /><category term="cloudflare" /><summary type="html"><![CDATA[Standing up a GitHub Pages site on a custom domain is mostly mechanical: create a repo named &lt;user&gt;.github.io, push something to main, and add a CNAME file naming the domain. GitHub picks the domain up from that file on every build, which also means deleting the file silently unsets the custom domain.]]></summary></entry></feed>