A team proposes moving an application onto GitHub Pages. What can GitHub Pages fundamentally not do, and how would you decide whether that rules it out?
answer
- no request-time compute
- public bundle, public secret
- no server config surface
- private repo does not mean private site
- a 404.html fallback still returns 404
basics
~20 sGitHub Pages serves static files and runs no code at request time: no API endpoints, no server-side rendering, no database, no server-held secrets, no configurable response headers or redirects, and no access control on the published site. That fits docs and marketing sites, not applications.
solid answer
~60 sPages is a static file host with a CDN in front of it, and everything it cannot do follows from that one fact. There is no request-time execution, so no API routes, no server-side rendering, no form handling and no database. Any credential shipped in the bundle is public, so a key in the JavaScript is a leaked key. You cannot set response headers — no custom `Content-Security-Policy`, no HSTS tuning — or configure server-side redirects and rewrites; a single-page app has to use a `404.html` fallback, which still returns HTTP 404. Published sites are publicly reachable, so the repository being private does not make the site private outside GitHub Enterprise Cloud's Pages access control. There are also documented size and bandwidth limits, and GitHub's terms exclude running a commercial transactional service on it. I would keep documentation, SDK reference, design-system showcases and marketing sites on Pages, and move anything that needs auth, request-time data or header control to a real static host with edge functions, or split the API onto a backend the site calls.
go deeper
Know the one-line rule: Pages serves static files only, with no backend, no database and no code running when a request arrives. Anything in the published bundle is visible to everyone.
Explain the concrete consequences — no API routes or request-time rendering, no build-time secret injection, no response-header or redirect configuration — and name the SPA 404.html fallback plus why its status code matters.
Diagnose proposals against the constraint: spot the leaked build-time key, the private-repo-means-private-site assumption, and the CSP requirement Pages cannot meet, then propose the split where static assets stay and dynamic work moves behind an API.
Own the hosting standard. Give teams a short disqualifying checklist — per-viewer responses, header control, non-public audience, volume limits — so the Pages-versus-real-host decision is made once and consistently, and state the migration path before anyone outgrows it.
## One property, many consequences GitHub Pages serves a directory of files over a CDN. It has no request-time compute layer at all. Nearly every question about what Pages "supports" resolves by asking whether the feature needs a server to think when a request arrives; if it does, the answer is no. ## What that removes **No dynamic responses.** No API endpoints, no server-side rendering per request, no form POST handler, no session, no database. A framework that offers a static-export mode can be deployed; the same framework's server features cannot. A contact form must post to a third-party service or your own API elsewhere. **No server-side secrets.** Anything the browser can use, an attacker can read: the bundle is public by definition. "Store the API key in a repository secret and inject it at build time" does not help, because the injected value ends up in the shipped JavaScript. Only credentials that are safe to publish — a publishable analytics key, a scoped read-only token designed for browsers — belong in a Pages site. **No header or routing configuration.** There is no `.htaccess`, no `nginx.conf`, no `_headers`/`_redirects` file honoured. You cannot add a `Content-Security-Policy`, tighten `Strict-Transport-Security`, set cache-control per path, or configure a 301 from an old URL to a new one. The two workarounds are both client-side and both lossy: meta-refresh or JavaScript for redirects, and a `404.html` fallback for SPA routing — which serves your app for unknown paths but still returns a 404 status, so crawlers and uptime checks see failures. **No access control on the site.** A Pages site published from a private repository is still served publicly on the internet; visibility of the *repository* and visibility of the *site* are different things. Restricting who can view a Pages site is an Enterprise Cloud feature (Pages access control for private and internal repositories), not something available on the free tier. Putting internal runbooks on a Pages site of a private repo is a real and recurring data-exposure mistake. **Documented limits.** GitHub publishes soft limits on published site size, monthly bandwidth and — for branch-source builds — builds per hour, and its terms of service exclude running an online business or transactional commerce on Pages. These are rarely the binding constraint for a docs site and occasionally are for a heavy media site; check the current documented numbers rather than quoting a remembered figure. ## The decision framework The useful way to answer this in an interview is not a feature list but a set of disqualifying questions: 1. **Does any response depend on who is asking?** Auth, personalisation, tenancy — if yes, Pages is out for that surface. 2. **Does content change more often than you are willing to rebuild?** Pages redeploys the whole site; if data changes per minute, you need client-side fetches to an API, and then the API needs a home anyway. 3. **Do you need control over response headers?** A CSP requirement, a security review, a strict cache policy — Pages cannot satisfy it. 4. **Must the site be non-public?** Only Enterprise Cloud answers yes. 5. **Is the traffic or asset volume beyond the documented soft limits?** If all five are comfortably "no", Pages is genuinely excellent: zero infrastructure, zero cost on public repositories, deploys that are just a push, TLS provisioned for you, and hosting that lives in the same place as the code and its review process. Documentation, SDK reference, design-system showcases, changelogs, status pages, conference microsites and open-source project pages all sit squarely there. ## What you move to when it does not fit The honest framing is that the alternatives are the same shape plus a compute edge. Static hosts with edge functions and header configuration cover the CSP, redirect and light-dynamic cases. A container or serverless backend covers real APIs, with the static site still served by a CDN and calling it. The architectural pattern is unchanged — static assets on a CDN, dynamic work behind an API — so "outgrowing Pages" usually means adding a backend, not rewriting the front end. ## The trap in the question Candidates often try to argue their way around the constraint: build-time data fetching for a dashboard, a hidden URL as access control, an obfuscated key in the bundle. Each of these trades a hard property for a hope. The senior move is to name the boundary precisely — static files, no request-time compute, public by default — and then place each surface of the product on the correct side of it.
- A single-page app on Pages 404s on deep links after a refresh. What is the standard workaround and what does it cost?Ship a `404.html` that boots the same app, so unknown paths still render the right view once JavaScript runs. It costs correctness at the HTTP layer: the response status is still 404, so crawlers, uptime monitors and some CDNs treat every deep link as an error, and there is no way to change that without a server.
- The team wants to inject an API key at build time from a repository secret. Is that safe on Pages?No. The build output is the published site, so the injected value ships to every visitor in plain JavaScript. Only credentials designed to be public — a publishable analytics or search key with server-side scoping — are acceptable. A real secret needs a backend that holds it and an endpoint the site calls.
- Is a Pages site published from a private repository private?No. Repository visibility and site visibility are separate; the site is served publicly on the internet. Restricting viewers requires GitHub Enterprise Cloud's Pages access control for private and internal repositories. Assuming otherwise is how internal documentation ends up indexed.
- Security review demands a strict Content-Security-Policy header. Can Pages deliver it?Not as a header — there is no server configuration surface, so you cannot set CSP, HSTS or cache-control per path. A `<meta http-equiv="Content-Security-Policy">` tag covers part of the policy but not directives that must arrive as headers. If the requirement is firm, host the static site somewhere with edge header configuration.
saying these in an interview costs you the question
- Believing a private repository makes its Pages site private
- Injecting a real API key at build time and calling it hidden
- Expecting .htaccess, _redirects or custom headers to work
- Confusing static export with server-side rendering support
- Treating a 404.html SPA fallback as a proper redirect