GitHub Pages is for public static sites. internalpage is for private team artifacts.

GitHub Pages integrates repository content and GitHub Actions with public website hosting. It is a strong fit for project documentation, portfolios, open-source sites, and other material intended to be reachable as a public web page.

• Repository-driven publishing and review
• Custom workflow support through GitHub Actions
• Custom domains for public websites
• A natural fit when search engines and outside visitors should reach the content

internalpage starts from a different requirement: a finished HTML, Markdown, or OpenAPI file needs a stable browser link, but page content should be returned only after the viewer passes the configured Google access check.

• Google Workspace or selected-email access
• Publish from a local file, script, or CI job
• Read-only rendering for Markdown and OpenAPI
• Custom domains that keep the private viewer policy

A difficult-to-guess public path only reduces discovery; anyone who obtains it can still request the page. Sensitive reports need an identity decision before content is served, plus a test that unauthorized accounts cannot receive it.

• Do not rely on robots.txt, a secret slug, or disabled navigation for confidentiality
• Assume public-host URLs can be forwarded, logged, and discovered
• Keep credentials out of the artifact even when it is access-controlled

GitHub Pages is a website deployment target: build or collect the site, package the Pages artifact, and deploy it. internalpage is an artifact publishing target: point the CLI at one supported file and a slug, then repeat the command to replace that page.

• Use GitHub Pages when the repository defines the public site
• Use internalpage when the generated file is the deliverable
• Use either from CI, but store private publishing credentials as secrets

npx @internalpage/cli publish ./report.html --slug weekly-report

internalpage is optimized for finished, browser-viewable artifacts. GitHub Pages or another application host is better when you need a multi-route site, a large asset tree, a public frontend build, or complex client-side deployment behavior.

• Use a full host for multi-page applications and large static bundles
• Use an application platform for server-side state and database writes
• Use internalpage for reports, references, runbooks, and review pages

Start with the audience and runtime, not the deployment brand. If the content should be public and maintained as a website, GitHub Pages is usually the simpler fit. If it should remain a private read-only team artifact, internalpage removes the need to add a separate access layer.

• Public, indexable website: GitHub Pages
• Private Google-protected report: internalpage
• Existing private app with its own origin: an identity proxy may fit better
• Backend or interactive state: use an application host