A Firebase project can host multiple sites — a marketing page, an app dashboard, a docs site, all under one project ID. Which makes this command far more dangerous than it looks:
firebase deploy --only hosting
With no site target, that deploys your current build to every hosting site in the project simultaneously. If you’re standing in the marketing-site repo, you just shipped the marketing site’s files to the app, the docs, and everything else sharing the project. On a project with several production sites, one habitual unscoped deploy is a multi-site outage.
The safe form is always scoped:
firebase deploy --only hosting:<site-id>
This works when firebase.json declares a "site" field, or when you’ve set up a named target: firebase target:apply hosting <target-name> <site-id>, then deploy with --only hosting:<target-name>.
The rules I now treat as non-negotiable:
- Every deploy script —
package.json, Makefile, CI config, README instructions — includes the site target. The unscoped form never gets written down anywhere someone might copy it. - Before an ad-hoc deploy on an unfamiliar project, look up the sites first (
firebase hosting:sites:list) and pass the target explicitly. - If the right site can’t be determined unambiguously, stop and confirm rather than fall back to the unscoped command.
What makes this trap nasty is that the unscoped command is the one every tutorial teaches, and on a single-site project it behaves perfectly for years — right up until someone adds a second site to the project and your muscle memory becomes a weapon.