Share private HTML reports without building a hosting stack.

A notebook export, ETL summary, model evaluation, or finance dashboard often ends up as a single HTML file. Emailing it produces stale copies, public hosting is too open, and building an internal application adds deployment work that the report itself does not need.

• Attachments split one report into many uncontrolled copies
• A public bucket or static host exposes the URL without an identity check
• A full portal needs routing, authentication, hosting, and ongoing ownership

Upload the HTML file, choose a readable slug, select the audience, and share the viewer URL. internalpage checks the viewer's Google identity before serving the page, while the same slug can receive later report versions.

• Workspace-wide sharing for team reports
• Selected-email sharing for narrower review
• Version replacement without sending a new link every time

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

The right access scope follows the report's audience. A company-wide operating report can use workspace access, while a finance review or customer-specific artifact should use a narrower selected-email list.

• Workspace access: recurring reports intended for the whole internal team
• Selected emails: sensitive or cross-functional review with a known audience
• Separate page slugs: reports that need distinct access rules or retention decisions

Google SSO protects delivery to authorized viewers; it does not make secrets safe to embed in HTML. Remove tokens and credentials before publishing.

Private HTML report sharing works best when the output is generated elsewhere and teammates mainly need to read, review, or archive it in a browser.

• Weekly product, sales, or finance metrics exports
• LLM evaluation and model comparison reports
• Data quality, ETL, and experiment summaries
• Backoffice audits and incident review timelines

Treat the private page as the stable destination and the local HTML file as the generated input. Publish, verify access from a signed-out browser, share the URL, then publish to the same slug when the source changes.

• Verify the page title, charts, and assets after the first publish
• Test both an authorized and unauthorized Google account for sensitive reports
• Keep one stable slug for each recurring report series
• Use recent view logs as an operational signal, not as proof that the content was read

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

Use a full application host when viewers must edit data, run long-lived server processes, or depend on a private backend at runtime. internalpage is intentionally optimized for publishing finished browser-viewable artifacts.

• Database writes and complex form workflows need an application backend
• Live operational dashboards may need a runtime with data-source credentials
• Static snapshots remain useful when reproducibility and a stable review link matter more than live interaction