GSGitSnapShareHome

The private-repository publishing problem

You have an HTML file in a private repository. Someone outside your team needs to look at it in a browser. That should take ten seconds; in practice it takes a workaround.

Why GitHub itself does not solve this

GitHub Pages is the obvious first stop, and it publishes a whole repository as a website. For private repositories, Pages is only available on paid plans (GitHub Pro, Team or Enterprise). The free path is to make the repository public — which is exactly what you were trying to avoid.

Pages also has an all-or-nothing shape. It publishes a branch or a folder, not a hand-picked set of files. Even on a paid plan, publishing one report from a repository that also contains source code, credentials in example files, internal notes or customer data means thinking carefully about what else ends up on the internet.

Why the file itself will not travel

A rendered HTML artifact is rarely a single file. A test report links a CSS file and a few icons. A coverage report links one page per source file. A notebook exported to HTML embeds scripts. An architecture diagram pulls in an SVG. Downloading the HTML from the GitHub UI and opening it locally usually produces an unstyled, half-broken page, because the relative links no longer resolve.

GitHub also refuses to render HTML from a repository as a web page. Viewing a blob shows the markup with syntax highlighting, and the raw URL is served with a content type that forces a download rather than rendering. This is a deliberate anti-abuse choice on GitHub's side, not a bug.

The workarounds people try

  • Zip it and email it. Works once. Then the recipient has a stale copy on their laptop, mail gateways strip HTML archives, and you have no idea which version anyone is looking at.
  • Add the reviewer as a collaborator. Now an outside reviewer has read access to the entire repository and needs a GitHub account. For a client, an auditor or a non-technical stakeholder this is both too much access and too much friction.
  • Make a second public repository. A copy-paste pipeline that drifts out of sync immediately, and one careless commit away from leaking the thing you wanted to keep private.
  • Spin up a static host. Netlify, Vercel, Cloudflare Pages and an S3 bucket all work, but each means a new account, a build configuration, DNS or bucket policies, and a deploy pipeline for a file you wanted to show one person this afternoon.
  • Screenshot it. Loses interactivity, tables, filtering and links — and for a coverage or profiling report the interactivity was the point.

What is actually needed

The requirement is narrow: publish only the files you name, keep the repository private, produce a URL a browser can open with no account, keep relative links between the published files working, and be able to switch the link off later.

That is the entire scope of GitSnap. It is not a hosting platform, a CDN or a CI system — it is the missing ten-second path between a private repository and a person with a browser.