Firebase Hosting alternatives for private reports
Firebase Hosting is a good static CDN: atomic deploys, instant rollback,
preview channels, firebase deploy in one line. If you are shipping a web
app, none of what follows is an argument against it.
The mismatch appears when the thing you are deploying is a report — one HTML file, produced by a job, that three named people should be able to read and nobody else.
Where the model fights you
- There is no per-page access control. Hosting serves files to whoever has the URL. Gating one path means putting a Cloud Function or Cloud Run service in front of it that verifies an ID token and streams the bytes. That is an application, with a cold start, a bill and a bug surface.
- Preview channels are a timer, not a permission. Expiring URLs are obscurity with an end date. Nothing records who opened one.
- A deploy overwrites the path. Rollbacks exist at the site level; "what did the numbers say two runs ago, and what changed" does not.
- No review layer. The report is a static file. Feedback happens elsewhere, in a thread that has to re-describe the chart in words.
- A project per surface. Nightly artifacts do not want a hosting site each; they want addresses.
The shortlist
1. Comma — visibility as a field, not an architecture
Publishing a report is one POST, and access control is a string on it:
curl -X POST https://commareports.com/api/v1/reports \
-H "Authorization: Bearer $COMMA_API_TOKEN" \
-H "Content-Type: application/json" \
-d "$(jq -n --arg h "$(cat dist/report.html)" \
'{title:"Nightly QA", html:$h, visibility:"domain"}')"
visibility takes private, team, domain (anyone on your email domain),
registered, or link. No function to deploy, no token verification to write,
no cold start in front of a static file.
Everything else a report wants comes with it: revisions appended at a
stable id, so the URL in your runbook never changes; anchored comments so a
reader's objection sits on the row it is about; a sandboxed iframe
(allow-scripts, no allow-same-origin) so interactive charts stay
interactive without touching anyone's session.
Not for: hosting an app, serving an SPA, custom domains per project, edge rewrites. Firebase is better at all of those and this page is not pretending otherwise.
Pricing: Free — unlimited reports, viewers, commenters and revisions.
2. Cloudflare Pages + Access — free static hosting with real SSO
The closest like-for-like if you want to keep operating your own hosting: Access puts an identity provider in front of the whole project without writing a proxy. You still maintain the project and the policy. See Cloudflare Access alternatives.
3. Google Cloud Storage + IAP — same building blocks, more assembly
A bucket behind Identity-Aware Proxy is the GCP-native version of gated static content. It is real access control and a genuinely fiddly setup for one file. The S3 equivalent is covered in S3 static hosting alternatives.
4. Google Drive — identity you already have, wrong renderer
Drive's sharing model is exactly right. Its handling of an HTML file is exactly wrong: it downloads or previews rather than rendering the page. See Google Docs, for HTML.
At a glance
| Option | Gate one report | Setup cost | Versions | Comments |
|---|---|---|---|---|
| Comma | A field on the POST | None | Yes | Yes |
| Firebase Hosting | Cloud Function you write | Medium | Deploys | No |
| CF Pages + Access | Access policy | Medium | Deploys | No |
| GCS + IAP | IAM | High | Object versions | No |
| Google Drive | Native sharing | None | Yes | Not on rendered HTML |
Checked September 2026.
How to choose
- Deploying an application? Stay on Firebase.
- A public static site with a custom domain? Firebase or Cloudflare Pages, whichever your team already runs.
- A private artifact that a few named people read and reply to? Publish it somewhere access control is one field.