Configure Hosting behavior

With Firebase Hosting , you can configure customized hosting behavior for requests to your site.

What can you configure for Hosting ?

• Specify which files in your local project directory you want to deploy to Firebase Hosting . Learn how.

• Serve a customized 404/Not Found page. Learn how.

• Set up redirects for pages that you've moved or deleted. Learn how.

• Set up rewrites for any of these purposes:

  • Show the same content for multiple URLs. Learn how.

  • Serve a function or access a Cloud Run container from a Hosting URL. Learn how: function or container .

  • Create a custom domain Dynamic Link . Learn how.

• Add headers to pass along additional information about a request or a response, such as how browsers should handle the page and its content (authentication, caching, encoding, etc.). Learn how.

• Set up internationalization (i18n) rewrites to serve specific content based on a user's language preference and/or country. Learn how (different page).

Where do you define your Hosting configuration?

You define your Firebase Hosting configuration in your firebase.json file. Firebase automatically creates your firebase.json file at the root of your project directory when you run the firebase init command.

You can find a full firebase.json configuration example (covering only Firebase Hosting ) at the bottom of this page. Note that a firebase.json file can also contain configurations for other Firebase services .

You can check the deployed firebase.json content using the Hosting REST API .

Priority order of Hosting responses

The different Firebase Hosting configuration options described on this page can sometimes overlap. If there is a conflict, Hosting determines its response using the following priority order:

1. Reserved namespaces that begin with a /__/* path segment
2. Configured redirects
3. Exact-match static content
4. Configured rewrites
5. Custom 404 page
6. Default 404 page

If you're using i18n rewrites , the exact-match and 404 handling priority order are expanded in scope to accommodate your "i18n content".

Specify which files to deploy

The default attributes — public and ignore — included in the default firebase.json file define which files in your project directory should be deployed to your Firebase project.

The default hosting configuration in a firebase.json file looks like this:

 "hosting": {
  "public": "public",  // the only required attribute for Hosting 
"ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ]
} 

public

Required
The public attribute specifies which directory to deploy to Firebase Hosting . The default value is a directory named public , but you can specify any directory's path, as long as it exists in your project directory.

The following is the default specified name of the directory to deploy:

 "hosting": {
  "public": "public"

  // ...
} 

You can change the default value to the directory that you want to deploy:

 "hosting": {
  "public": "dist/app"

  // ...
} 

ignore

Optional
The ignore attribute specifies the files to ignore on deploy. It can take globs the same way that Git handles .gitignore .

The following are the default values for the files to ignore:

 "hosting": {
  // ...

  "ignore": [
    "firebase.json",  // the Firebase configuration file (the file described on this page)
    "**/.*",  // files with a leading period should be hidden from the system
    "**/node_modules/**"  // contains dependencies used to create your site but not run it
  ]
} 

Customize a 404/Not Found page

Optional
You can serve a custom 404 Not Found error when a user tries to access a page that doesn't exist.

Create a new file in your project's public directory , name it 404.html , then add your custom 404 Not Found content to the file.

Firebase Hosting will display the content of this custom 404.html page if a browser triggers a 404 Not Found error on your domain or subdomain.

Configure redirects

Optional
Use a URL redirect to prevent broken links if you've moved a page or to shorten URLs. For example, you could redirect a browser from example.com/team to example.com/about.html .

Specify URL redirects by creating a redirects attribute that contains an array of objects (called "redirect rules"). In each rule, specify a URL pattern that, if matched to the request URL path, triggers Hosting to respond with a redirect to the specified destination URL.

Here's the basic structure for a redirects attribute. This example redirects requests to /foo by making a new request to /bar .

  "hosting" 
 : 
  
 { 
  
 // ... 
  
 // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**") 
  
 "redirects" 
 : 
  
 [ 
  
 { 
  
 "source" 
 : 
  
 "/foo" 
 , 
  
 "destination" 
 : 
  
 "/bar" 
 , 
  
 "type" 
 : 
  
 301 
  
 } 
  
 ] 
 } 
 

View a more detailed example for a redirects attribute

  "hosting" 
 : 
  
 { 
  
 // ... 
  
 // Add the "redirects" attribute within "hosting" 
  
 "redirects" 
 : 
  
 [ 
  
 { 
  
 // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**") 
  
 "source" 
 : 
  
 "/foo" 
 , 
  
 "destination" 
 : 
  
 "/bar" 
 , 
  
 "type" 
 : 
  
 301 
  
 }, 
  
 { 
  
 // Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**" 
  
 "source" 
 : 
  
 "/foo{,/**}" 
  
 "destination" 
 : 
  
 "/bar" 
  
 "type" 
 : 
  
 301 
  
 }, 
  
 { 
  
 // Returns a temporary redirect for all requests to files or directories in the "firebase" directory 
  
 "source" 
 : 
  
 "/firebase/**" 
 , 
  
 "destination" 
 : 
  
 "https://firebase.google.com/" 
 , 
  
 "type" 
 : 
  
 302 
  
 }, 
  
 { 
  
 // A regular expression-based redirect equivalent to the above behavior 
  
 "regex" 
 : 
  
 "/firebase/.*" 
 , 
  
 "destination" 
 : 
  
 "https://firebase.google.com/" 
 , 
  
 "type" 
 : 
  
 302 
  
 } 
  
 ] 
 }