Publish internal pages from developer workflows.
What you can do
Publish a page source
Create a private page from HTML, Markdown, or an OpenAPI spec and share the viewer URL with your team.
Protect static HTML with Google SSO
Turn a local HTML report into a private Google-protected page link.
Render Markdown and OpenAPI
Use GitHub-like Markdown rendering or a read-only OpenAPI reference with ReDoc, Swagger UI, or Scalar.
Publish OpenAPI docs from CI
Update the spec behind a private API reference without changing its URL or renderer setting.
Update the same page
Run the same publish command again while keeping the same private URL.
Use your own subdomain
Serve viewer links from a workspace-owned custom domain while keeping the default internalpage URL as a fallback.
Publish from AI agents
Let local agents publish generated reports, specs, and runbooks through the CLI.
Use it in CI
Attach generated reports to pull requests, deploy checks, and release workflows.
Keep tokens scoped
Use personal API tokens for creator attribution and revoke them when workflows change.
Core model
internalpage is built around a small loop:
- Create a personal API token in your workspace.
- Publish an HTML, Markdown, or OpenAPI file with the CLI or API.
- Share the generated viewer URL.
- Run
publish --slugagain when your source changes.
Start here
- Quickstart: publish your first page.
- Protect static HTML with Google SSO: publish a private static HTML report.
- Publish OpenAPI docs from CI: keep internal API references up to date.
- CLI reference: install and run
@internalpage/cli. - AI agents: publish generated artifacts from local agents.
- Page file types: publish HTML, Markdown, and OpenAPI files.
- Custom domains: connect a workspace-owned subdomain for viewer links.
- API reference: authenticate and call the Pages API.
- Use cases: common developer workflows.