The short version
GitHub Pages serves static files that live in a repository. Vercel runs an application platform that happens to serve static files extremely well. If your output is a folder of HTML that is finished, Pages is the smaller answer. If your output has a runtime — server rendering, API routes, image transformation, edge middleware — Vercel is the one that has those.
Hosting model
Pages binds hosting to source control: a branch or a folder within it is the site, and publishing is pushing. That is a real advantage when the site is documentation next to the code it documents. Vercel binds hosting to a project abstraction with its own settings, environments and deployment records — heavier, and correspondingly more capable.
Build and deploy
Pages will run a build for you through the platform's own CI, but the mental model stays "commit produces site". Vercel's model is "deployment", which is a first-class object you can inspect, promote, roll back and preview per branch. If you have ever needed to point at exactly which build is live, you have needed the second model.
Dynamic capability
This is the honest dividing line. Pages is static file serving; anything dynamic has to happen in the browser or on somebody else's server. Vercel runs your code on request. Every other difference between them is a preference — this one is a capability.
Custom domains and certificates
Both attach custom domains with managed certificates, and both want a DNS record you control. The operational difference shows up in how many domains and environments you end up juggling: one project with a preview domain per branch is a different administrative object from one repository with one site.
Access control
The part that trips people up. Static hosting is public by construction, and both platforms treat private access as an account-plan feature rather than a per-link property. If the thing you are publishing should be visible to exactly one person, neither model is aimed at you — you end up either paying for an organisation tier or putting a proxy in front.
Pricing shape
Deliberately no numbers here; both change them, and a stale price in a comparison page is worse than no price. The shapes are what matter: Pages is bundled into a source-hosting plan and priced per seat, Vercel is a platform plan with usage on top. Read both pricing pages the day you decide.
Side by side
| GitHub Pages | Vercel | |
|---|---|---|
| Unit of work | A repository | A project |
| Publish action | Push a commit | Trigger a deployment |
| Runtime code | None | Yes — functions, middleware, SSR |
| Preview per branch | Not really | Yes, by default |
| Private access | Tied to the org plan | Tied to the account plan |
| Good at | Docs beside their source | Applications with a lifecycle |
When neither shape fits
Both assume a project that outlives its setup. When the thing you are publishing is a single file an agent wrote twenty minutes ago, for one reader, that assumption is the whole cost. The third shape is a publish primitive: one call, an unguessable URL, an expiry, and no project to clean up afterwards.
curl -X POST https://read.botook.ai/sites \
-H "Authorization: Bearer otr_live_YOUR_KEY" \
-F file=@index.htmlCan I use both?
Commonly the right answer: the documentation site on Pages beside its repository, the application on Vercel, and one-off artifacts on neither.
Which is faster to set up for a plain static site?
Pages, if the files are already in a repository — publishing is a push. Vercel is faster if they are not, because it will take a folder directly.
Can either serve a page privately to one person?
Not per link. Both express privacy at the plan or organisation level. A link whose token is the credential is a different product shape.
Do I need a build step at all?
Only if your source is not already HTML. Agent output usually is — one self-contained file with its CSS and JavaScript inline, which needs no bundler.