Public/Private Boundary for Rocky Portals

Every public Rocky page needs a clean boundary from private workspaces, customer details, internal logs, and operator-only actions. The boundary is both technical and editorial.

Public-safe content

• Product explanations, public docs, and general workflow patterns.
• Sanitized examples with fake names and fake paths.
• Official documentation links.
• Public assets intentionally packaged for the site.
• High-level deployment or QA checklists.

Keep private

• Customer records, order details, and raw webhook payloads.
• API keys, tokens, cookies, session IDs, and one-time links.
• Private Dropbox paths, home directories, and internal repo names.
• Unreleased strategy documents unless explicitly approved for publication.
• Screenshots that reveal real accounts, inboxes, or dashboards.

Release checklist

• Search new content for private path patterns and credential-shaped strings.
• Confirm Docker and Cloud Build contexts allowlist only public data files.
• Verify anonymous routes do not expose private navigation or admin state.
• Check robots and sitemap behavior matches publication intent.
• Review generated images and screenshots before deployment.

Pitfalls

• Copying the whole data/ directory into a public container.
• Publishing realistic terminal examples with real usernames or project paths.
• Letting analytics or translation widgets observe keyed private pages.
• Assuming noindex is a security boundary.

Verification steps

• Fetch the public route without authentication.
• Inspect rendered HTML for private terms and accidental links.
• Test direct asset URLs for intended public files only.
• Confirm the sitemap includes only public, indexable pages.