GitHub Pages: Static hosting

Explore GitHub Pages static hosting, repository-based publishing and custom domains, with clear limits on what requires a separate backend service.

Updated 8 September 2026

What GitHub Pages is used for

GitHub Pages publishes static HTML, CSS and JavaScript from a repository. It can serve a personal site, project documentation or another static website, using a GitHub-provided address or a custom domain. A build workflow can generate the files before publication.

A library maintainer could keep documentation beside the source code and review documentation changes through pull requests. Once published, visitors receive the generated pages without requiring the documentation generator to run for each request.

Static hosting and browser interactivity

Static hosting does not mean a page must be visually static. JavaScript can still run in the browser and call an external API. What GitHub Pages does not provide is a general server-side application runtime for processing each visit.

For example, a calculator can operate entirely in the browser, while a contact form that sends email needs an external submission service. Never put private service credentials in a JavaScript file merely because the source repository is private.

Builds, custom domains and project sites

GitHub Pages publishes a user or organization site, or a site associated with a repository. Jekyll is a built-in publishing option, and GitHub Actions can build and deploy output from other static generators. Custom domains and HTTPS let the result appear under the project’s own web address.

This is particularly useful for documentation, portfolios and project websites where a repository is the publishing source. The build can generate files from content, but the published Pages site does not itself execute a database-backed server application. External APIs can add functionality to the browser-facing site.

Planning a Pages site

Check how the site is built and which path it is published under. A project site may have a repository path prefix, which affects asset URLs and internal navigation. Test a direct visit to a nested page as well as navigation from the homepage.

If a project needs accounts, private data or application-generated responses, identify the separate backend before choosing the publishing workflow. Also review GitHub Pages’ usage policies and limits against the intended purpose of the site.

How DNSTrace.dev detects GitHub Pages

Detection correlates independent public signals. A single match is reported as strong evidence; agreement between a response header and the announcing network is reported as confirmed.

x-github-request-id — Per-request identifier issued by GitHub's serving layer.
server: GitHub.com — Present on Pages responses.
CNAME targets under github.io — The standard custom-domain mapping for a user, organisation or project site.
Published apex A records — GitHub documents four IPv4 addresses for apex domains, which is why an address match alone is weak evidence shared by every Pages site.

What a detection proves

The files were served by GitHub Pages.

What it does not prove

Which repository or account publishes the site, or whether a separate CDN sits in front. A proxy placed ahead of Pages can mask these headers entirely.

Common questions about GitHub Pages

Can GitHub Pages run PHP or a server-side API?

GitHub Pages serves static files. Browser JavaScript can call an API elsewhere, but Pages itself does not run a PHP application or a general request-time backend for the site.

Can GitHub Pages run server-side code?

No. Pages serves static files only. Any dynamic behaviour comes from client-side code or an external API.

Does an apex IP match prove GitHub Pages?

It is weak on its own because every apex Pages domain uses the same documented addresses. DNSTrace.dev wants a response header or a github.io target to confirm.

Frontend application platform