How to share private GitHub repo docs without giving repo access

You keep your project documentation in a private GitHub (or GitLab) repo, and someone outside the team — a client, a contractor, a stakeholder — needs to read it. The instinct is to add them as a collaborator. Don't. There's a safer, faster way that exposes only the docs and nothing else.

Why "just add them as a collaborator" is the wrong move

GitHub access is repo-level. Add an outside person as a collaborator and they can see:

• all your source code,
• the full commit history,
• every other doc and internal file in the repo.

There's no native "read only this one folder" for outside collaborators. So a collaborator invite over-grants access, usually triggers a security review, and gives a non-technical person a developer UI they can't navigate anyway. Wrong tool for the job.

The options that don't expose the repo

Option 1 — Deploy a static site from the docs

Build a site (Docusaurus, MkDocs, etc.) from the markdown and host it. The reader sees only the rendered docs, not the repo. The cost: you build, deploy, host, and maintain it, plus add auth yourself if the docs shouldn't be fully public, plus bolt on comments (Giscus needs a GitHub login). Real engineering work for a moving target.

Option 2 — Put a read-only viewer over the repo (fastest)

Connect a hosted viewer to the private repo. It renders the markdown and authenticates readers separately from GitHub. You pick which folders are exposed, exclude internal files, and invite people by email with a role. They never get repo access.

This is the lowest-effort, safest path, and it stays current automatically on every git push.

How to do it with a viewer (step by step)

Using Miradorly as the example:

1. Connect the repo — install the GitHub/GitLab app, select the markdown folders to expose.
2. **Add a .docignore** — exclude anything internal so it's never rendered, indexed, or returned over MCP:

# .docignore — never leaves the team
CLAUDE.md
**/secrets/**
internal/
drafts/
*.internal.md

1. Invite the reader by email with a viewer (read) or commenter (read + comment) role, scoped to their project only.
2. Keep writing in your editor. Push commits; the viewer re-renders. The reader always sees the latest, scoped to exactly what you allowed.

Access compared

A note on AI access

If the reader also wants their AI agent to query the docs, a role-aware MCP lets them — scoped to the same permissions, with .docignore files excluded. That's something neither a collaborator invite nor a plain static site gives you. More in role-aware MCP for docs.

Bottom line

Sharing private repo docs is a scoping problem, and GitHub's collaborator model can't scope to a folder for outside people. Render the docs outside the repo — a viewer overlay is the fastest, safest way — invite by email, exclude internal files with .docignore, and nobody ever sees your repo.