Cloudflare Access protects apps. internalpage shares private pages.

Choose Cloudflare Access when you already have an application, origin, and hostname that need an identity-aware proxy. Choose internalpage when the deliverable is a finished HTML file, Markdown document, or OpenAPI spec and you want a private rendered link without operating a separate hosting stack.

• Existing app or staging environment: Cloudflare Access
• Generated report or document artifact: internalpage
• Device posture and network policy: Cloudflare Access
• Upload, render, and replace one private page: internalpage

Cloudflare Access acts as an identity-aware proxy in front of applications and can enforce richer Zero Trust policies. It is the stronger choice for ongoing services, staging environments, and apps that already have hostnames, routing, and deployment ownership.

• Protect self-hosted web applications
• Apply organization-wide Zero Trust policy
• Combine identity, device, and network posture controls
• Best fit when your team is already operating the application and its DNS/security boundary

internalpage is built for browser-viewable outputs: generated HTML reports, Markdown docs, OpenAPI specs, diagrams, and other internal pages that should open as rendered private links without standing up a new app.

• Upload or automate page creation directly
• Render Markdown into a readable private document
• Render OpenAPI specs with ReDoc, Swagger UI, or Scalar in read-only mode
• Use Google Workspace access without managing an app deployment
• Keep a stable viewer URL while replacing the latest version

Cloudflare Access protects an origin that your team deploys and maintains. internalpage includes the artifact publishing and rendering workflow, so the source file can be the unit you operate instead of a web server or object-storage site.

• Cloudflare Access: origin hosting, application deployment, DNS/routing, and Access policy
• internalpage: the HTML, Markdown, or OpenAPI source plus its audience and slug
• Both: identity configuration and a deliberate review of who should have access
• Neither: permission to place credentials or secrets inside client-delivered HTML

internalpage custom domains are designed around a workspace-owned subdomain and a DNS CNAME target. Your team can keep the domain at its current DNS provider; the setup does not require changing the domain's nameservers to Cloudflare.

• Use a familiar URL such as docs.company.com/security-policy
• Point one subdomain to customers.internalpage.com
• Keep the default view.internalpage.com URL as a fallback
• Use the same private viewer access checks on both URLs

Start with the thing your team actually owns. If it is a running service, protect the service. If it is a generated file, publish the file. Teams can use both products without overlap: Access for apps and internalpage for the reports and references those apps, scripts, and agents produce.

• App, staging site, admin UI: Cloudflare Access
• HTML report, rendered Markdown, private OpenAPI docs: internalpage
• Custom domain for private pages without moving authoritative DNS: internalpage
• Device posture or broader Zero Trust policy: Cloudflare Access
• High-security enterprise use: perform a deeper security and compliance review for either choice