Platform target

Firebase Hosting

Firebase Hosting deploys Nift's normal public/ directory to its CDN. The target creates a minimal firebase.json; Firebase project selection and credentials remain explicit Firebase CLI concerns.

Create and build

nift init --target=firebase
nift build --all
nift status

What Nift creates

{
  "hosting": {
    "public": "public",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"]
  }
}

public is Firebase Hosting's deployment-directory setting. The file is user-owned after initialization; extend it for routing, headers and multi-site behavior rather than editing generated output.

Associate a Firebase project

firebase login
firebase use --add
firebase projects:list

The Firebase CLI normally records project aliases in .firebaserc. Review that file before committing it, especially in repositories that deploy staging and production projects.

Preview before production

nift build --all

# Local Hosting emulator
firebase emulators:start --only hosting

# Shareable preview channel
firebase hosting:channel:deploy docs-review

# Live deployment after review
firebase deploy --only hosting

Preview-channel URLs use real Firebase project resources unless separately emulated or isolated. A preview frontend can still call production APIs if its configuration points there, so treat backend/environment selection as a separate safety decision.

Routing and 404s

Firebase Hosting supports redirects, rewrites and a custom 404.html in the deployed directory. An ordinary multi-page Nift site usually needs no catch-all rewrite. If a particular route is a client-side application, scope the rewrite to that route rather than hiding every missing file behind index.html.

{
  "hosting": {
    "public": "public",
    "redirects": [
      { "source": "/old-docs/**", "destination": "/docs/index.html", "type": 301 }
    ]
  }
}

Headers and cache policy

{
  "hosting": {
    "public": "public",
    "headers": [
      {
        "source": "**/*.html",
        "headers": [
          { "key": "Cache-Control", "value": "public, max-age=0, must-revalidate" }
        ]
      },
      {
        "source": "/assets/**",
        "headers": [
          { "key": "X-Content-Type-Options", "value": "nosniff" }
        ]
      }
    ]
  }
}

Add a long immutable cache lifetime only when asset filenames are content-hashed. Stable filenames require revalidation or a bounded lifetime. Dynamic rewrites have different default cache behavior from static files; set policy only after deciding which responses may safely be shared.

Dynamic endpoints

Hosting rewrites can send matching requests to Cloud Functions or Cloud Run. That creates dynamic endpoints beside the Nift frontend without turning Nift templates into runtime code. Authentication, secrets and request validation belong to the target service.

Custom domains and TLS

Add the domain from the selected Hosting site's console, prove ownership, apply the requested DNS records and wait for certificate provisioning. Remove conflicting legacy A, AAAA or CNAME records when Firebase identifies them. Use the advanced setup path for a domain already serving production traffic when you need to establish ownership and TLS before directing traffic.

Troubleshooting

Official references: Hosting configuration, preview and deployment, cache behavior, and custom domains.