Custom domain for Cloudflare Pages

• A Cloudflare account with a Pages project that already deploys (the free plan is enough).
• A public GitHub repository with a LICENSE — OpenRepos serves open source projects only.
• The OpenRepos badge in your README: CI checks it on every new claim.

Pick a free name with the domain picker, then add it to register.json under the domain you chose:

"openrepos.org": {
  "awesome-project": {
    "repo": "https://github.com/octocat/awesome-project",
    "target": "awesome-project.pages.dev"
  }
}

Use the production hostname of your Pages project as the target (<project>.pages.dev), not a preview or branch alias.

Add the badge to your README and open the pull request; CI validates naming, ownership and the badge. After merge, OpenRepos creates a DNS-only CNAME from your subdomain to <project>.pages.dev.

In the Cloudflare dashboard go to Workers & Pages, select your Pages project, open Custom domains and choose Set up a domain. Enter your OpenRepos subdomain (for example awesome-project.openrepos.org) and confirm.

Cloudflare will show CNAME instructions because the domain lives outside your account. You do not need to add anything: OpenRepos already created that exact CNAME, so the verification usually passes within minutes.

Prefer the API? Attach the domain with POST /accounts/{account_id}/pages/projects/{project}/domains with { "name": "awesome-project.openrepos.org" }.

The domain moves from Verifying to Active. Cloudflare issues the TLS certificate automatically once the domain is active — you do not manage certificates or redirects yourself.

Until the domain is attached and active, the subdomain returns 522. This is expected: Cloudflare documents that a CNAME pointing at pages.dev without the domain being associated in the Pages dashboard fails exactly this way.

• 522 persists after attaching the domain — check the domain status in Custom domains: it must be Active, and the target must match your production pages.dev hostname. Re-check with dig awesome-project.openrepos.org CNAME.
• The subdomain shows the OpenRepos page instead of your site — the claim has not been merged yet, or DNS has not propagated. Explicit CNAMEs take precedence over the wildcard redirect as soon as they exist.
• Verification stuck in "Verifying" — the domain might be behind Cloudflare Access, a redirect rule or a Worker on your side, or the zone's CAA records may block certificate issuance. Remove such blocks; if it still fails, open an issue in the register repository so we can check the OpenRepos zone.
• Changed DNS away from Pages and back — the custom domain goes inactive and errors return until it becomes active again. Keep the record pointing at <project>.pages.dev.

Using GitHub Pages instead? Follow the GitHub Pages guide. See all guides, or compare free subdomain services.