GitSnap vs the alternatives
Most of these tools are good at what they were built for. The question is which one fits 'show these three files to this person, now, without making my repo public'.
Side by side
| Option | Where it shines | Where it gets in the way |
|---|---|---|
| GitHub Pages | First-party, custom domains, unlimited pages, ideal for a project website or docs site. | Private repositories require a paid plan. Publishes a whole branch or folder rather than named files, and needs a build/deploy step. |
| GitHub Gist | Instant, free, good for a snippet or a single file others should read as text. | Does not render HTML as a web page, no multi-file assets with working relative links, and secret gists are shareable by anyone who has the URL with no per-viewer control. |
| Netlify / Vercel / Cloudflare Pages | Full static hosting with CI, previews, redirects and custom domains — the right tool for a real site or app. | Another account and build configuration, and they publish the built output of a project. Overkill for showing one report to one reviewer, and access control on free tiers is limited. |
| S3 / Cloud Storage bucket | Cheap, durable, scriptable, fine for large artifacts. | Bucket policies, content types and signed URLs are easy to get subtly wrong; there is no repository link, no per-file selection UI and no viewer log without extra work. |
| Adding a collaborator | No new tools; reviewers see the source of truth. | Grants access to the entire repository, requires a GitHub account, and HTML still is not rendered as a page. |
| Email a zip file | Works everywhere, needs no service. | Stale copies, size limits, mail gateways that strip HTML archives, no way to revoke, no idea which version anyone opened. |
| GitSnap | Free publishing of named files from a private repository, no build step, working multi-file HTML, entry file, per-email or per-domain access rules, view log and an instant off switch. | Not a hosting platform: no custom domains per link, no CI pipeline, no server-side code, and snapshots update when you say so rather than on every push. |
When GitSnap is the wrong choice
If you are publishing a public marketing site, a docs portal with a custom domain, or anything that needs a build pipeline and server-side rendering, use a real static host. GitSnap is for sharing artifacts out of a private repository, not for running a website.
When GitSnap is the right choice
When the repository must stay private, the recipient must not need a GitHub account, only some files may be exposed, the content is already rendered HTML or assets, and you want to be able to revoke the link in one click.