Firebase Hosting and Cloud Storage: Where Your Files Live

Firebase gives you two places to keep files, with names similar enough that people reach for the wrong one. The distinction is simple once stated:

Rule of thumb: if the file exists on your laptop before you deploy, it belongs in Hosting. If it arrives from a phone at three in the morning, it belongs in Storage.

Firebase Hosting

Hosting serves your website from a global CDN with HTTPS switched on by default. You do not configure a certificate, a server, or a cache.

Deploying is two commands:

npm install -g firebase-tools
firebase login

firebase init hosting   # asks which folder holds your built site
firebase deploy

That is the whole workflow. The folder you point it at — dist, build, out, whatever your framework produces — is uploaded and served worldwide.

Preview channels are the underused feature

One command gives you a temporary URL with your changes on it, live, without touching production:

firebase hosting:channel:deploy pr-142 --expires 7d

The URL expires by itself. This is genuinely useful for showing work to someone before it ships, and it costs nothing extra.

Static sites versus server-rendered ones

Classic Firebase Hosting serves static files. If your framework produces HTML at build time — Vite, Create React App, a static Next.js export, plain HTML — it fits perfectly.

If your app renders on the server for every request, static hosting alone cannot run it. There are two routes:

• Firebase App Hosting, a newer product built for framework apps that need a server, including Next.js and Angular.
• Hosting with a rewrite to a Cloud Function, the older approach: static files from the CDN, dynamic routes forwarded to a function.

Cloud Storage for Firebase

Storage is where user files go. It sits on top of Google Cloud Storage, so the files are in a real GCS bucket you can also reach with Google Cloud tooling.

Uploading from a browser or app:

import { getStorage, ref, uploadBytes, getDownloadURL } from "firebase/storage";

const storage = getStorage();

// Scope the path by user id so security rules can check ownership.
const fileRef = ref(storage, `avatars/${userId}/profile.jpg`);

await uploadBytes(fileRef, file);
const url = await getDownloadURL(fileRef);

Note the path. Putting the user's ID in it is what makes the security rule below possible — you cannot write a rule about ownership if the path does not encode who owns the file.

Storage security rules

Storage has its own rules, separate from Firestore's. They are the only thing standing between your bucket and the internet.

rules_version = "2";
service firebase.storage {
  match /b/{bucket}/o {

    match /avatars/{userId}/{fileName} {
      // Anyone signed in can look at an avatar.
      allow read: if request.auth != null;

      // Only the owner can upload, and only images under 5MB.
      allow write: if request.auth != null
                   && request.auth.uid == userId
                   && request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches("image/.*");
    }
  }
}

Download URLs are permanent links

getDownloadURL() returns a URL containing a token. That URL works for anyone who has it, regardless of your security rules, until you revoke the token.

This is convenient and occasionally a leak. If a file must stay private, do not pass its download URL around — have the client read it through the SDK, where rules are enforced every time.

What each costs

Both bill for stored bytes and transferred bytes, with a monthly free allowance. Storage also counts operations — uploads, downloads, deletes.

The expensive pattern is serving large media to many people. A popular video streamed from Cloud Storage is pure egress, and egress is the line item that grows. At that point a dedicated media CDN is usually cheaper.