32 results found

1. The ability disable default domains
   26 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Private (restricted access) Firebase Hosting websites
   23 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Remove 36 Hosting sites per project limitation
   16 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Manage minInstances setting of pinned functions of previous releases

   Pinned functions of previous releases keep their minInstances setting. E.g. after deploying 10 times with a minInstances setting of 1, there will be 10 idling instances but only the newest revision handles all the traffic. Yet the remaining 9 instances' idle time is billed as well because the function is still addressable through the revision tag.

   This also affects the maxInstances setting: With a maxInstances setting of 10, the newest Cloud Run revision which handles 100% of the traffic won't be able to scale anymore.

   As far as I know, the only way to handle this right now is to manually delete the Cloud Run revisions or to manually remove the revision tag. Both methods unfortunately break the rollback functionality and are complicated (if even impossible?) to integrate into CD pipelines.

   I would appreciate the possibility of automatically scaling down pinned v2 function revisions that don't handle any traffic to a minInstances setting of 0.

   Pinned functions of previous releases keep their minInstances setting. E.g. after deploying 10 times with a minInstances setting of 1, there will be 10 idling instances but only the newest revision handles all the traffic. Yet the remaining 9 instances' idle time is billed as well because the function is still addressable through the revision tag.

   This also affects the maxInstances setting: With a maxInstances setting of 10, the newest Cloud Run revision which handles 100% of the traffic won't be able to scale anymore.

   As far as I know, the only way to handle this right now is to… more

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Provide the ability to download Firebase Hosting versions
   13 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Password-protected preview domains

   Squarespace has a featured for "site-wide password protection" which is useful for staging unlaunched websites for stakeholders to review. This would help guard against any potential leaks.

   Figma also has a feature similar to this.

   We currently have to create a custom express.js server with an authentication middleware, but this is undesirable for several reasons:

   • We'd have to re-create all of firebase hosting's serving features (i18n fallbacks, redirects, pretty urls, etc.)
   • We can't easily test endpoints that are proxied to Functions/GCR
   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Pass all cookies to Cloud Functions or Cloud Run

   Right now only a _session Cookie is passed.
   https://firebase.google.com/docs/hosting/manage-cache#usingcookies

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Wildcard certificates for custom domains
   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. CDN Invalidation API

   Add an official API to support cache invalidation via resource URL, header, or tag.

   The rate limit to such an API should be high enough to support what people already do with the non-official API to invalidate by URL.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Hosting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Allow URLs to be accessible fully, or by invitation, or by password protection, like Notion and Figma

    Allow natively what we can do in Notion / Figma (sharing a prototype), by sharing a page with the followings options:
    1/ allow a page to be fully accessible (that's already possible, so the default)
    2/ allow a page to be viewed only if we provide another User a link.
    3/ allow a page to be viewed if 2/ + password protected

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Hosting CDN cache stale-while-revalidate

    Time-to-first-byte from Firebase Functions is usually slow (more than 500ms) even without cold start, sometimes (with cold starts) TTFB becomes absolutely unacceptable for projects where performance is important. SSRed HTML is also not Brotli compressed as static files.
    This is a really big problem to deploy SSR web apps to Firebase IMO, and cache SWR at the CDN layer (edge) would solve it perfectly.

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. NextJS Hosting (SSR) support
    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Restrict Unauthenticated PURGE requests

    At the moment Hosting is using Varnish cache which developers do not have access so they can't configure it, this leaves a small window for people to continuously Purge the page and increase the developer's usage

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. API or CLI cmd for "Connect custom domain for Hosting"
    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. The ability to turn on/off the decoding of encoded data url in firebase.json

    When I hosted a frontend client (React JS) and backend (NodeJS) server in hosting and functions combination, there were some scenarios where in I needed to send data (to server) which contained slash (so encoded them).

    This was where the problem rose, the encoded component was automatically decoded by the firebase hosting itself and sent the wrong url to the underlying server.

    Therefore firebase should give us the ability to turn on/off the decoding of encoded data url in firebase.json

    my current firebase.json file -

    {
    "functions": [
    {
    "source": "functions",
    "codebase": "default",
    "ignore": [
    "nodemodules",
    ".git",
    "firebase-debug.log",
    "firebase-debug..log"
    ]
    }
    ],
    "hosting": {
    "public": "/functions/public",
    "ignore": [
    "firebase.json",
    "/.",
    "**/nodemodules/"
    ],
    "rewrites": [
    {
    "source": "",
    "function": "app"
    }
    ]
    }
    }

    When I hosted a frontend client (React JS) and backend (NodeJS) server in hosting and functions combination, there were some scenarios where in I needed to send data (to server) which contained slash (so encoded them).

    This was where the problem rose, the encoded component was automatically decoded by the firebase hosting itself and sent the wrong url to the underlying server.

    Therefore firebase should give us the ability to turn on/off the decoding of encoded data url in firebase.json

    my current firebase.json file -

    {
    "functions": [
    {
    "source": "functions",
    "codebase": "default",
    "ignore": [
    "nodemodules",
    ".git",
    "firebase-debug.log",
    "firebase-debug.… more

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Get rid of the egress data transfer fee for Firebase Hosting

    All is described in the title. I no longer see any benefits to using Firebase Hosting when you have competition like Cloudflare pages that charges zero for egress traffic.

    By reworking Firebase hosting egress fees, it could attract more users looking for a hosting solution and then convert them to a paid product linked with hosting like Firestore, Functions, etc.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Support yarn and/or pnpm for frameworks

    Currently frameworks only used npm

    This can cause issues if using yarn or pnpm, and npm does not read the lockfile and you can end up with different versions of dependencies in production

    Deployments with frameworks should detect the package manager used

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. Allow some customers to migrate to dedicated cert
    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Support deployment of Nuxt 3 projects to Hosting

    Currently, support for Web Frameworks (Beta) only supports Next.js and Angular: https://firebase.google.com/docs/hosting/frameworks/frameworks-overview. Nuxt is labeled as 'Soon' at https://github.com/FirebaseExtended/firebase-framework-tools

    I just wanted to cast my vote for Nuxt 3 support and try out the new portal :) Thanks!

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Trusted headers for client IP address via Firebase Hosting

    Context: from a backend running on Cloud Run/Cloud Functions, how to determine client IP address, when you need to TRUST it for IP-address based access restrictions.

    You can normally find the real client IP as the first entry in the X-Forwarded-For header, but you cannot trust it.

    If you are using Cloud Run (or Cloud Functions gen 2), then as far as I can tell the Cloud Run orchestrator always sits as a proxy in front of your container. This means you can trust the last entry in X-Forwarded-For as this is the client IP seen by Cloud Run itself. The last address is the only address you can trust. Any preceeding addresses in the list could have been provided/spoofed by the requester themselves or any untrusted proxy along the way.

    If you are proxying the the Cloud Run container (or Cloud Function) behind Firebase hosting, then the last address in the list is the Fastly CDN proxy, not the original client address. You might be tempted to use the second-to-last address (or the Fastly-Client-IP header), but you cannot trust this.

    If the requester learns the direct address of your Cloud Run container (e.g. <your-service>.a.run.app) then they can make the request directly, and spoof either of those headers, telling you whatever address they want to.

    In short, there needs to be some coordination between Cloud Run and Firebase Hosting for Cloud Run to provide some "trusted header". When a request reaches Cloud Run via Firebase Hosting the two need to authenticate themselves so that Cloud Run can provide the real client IP as seen by Firebase Hosting, only if the request actually came from legitimate Firebase Hosting.

    Without this, Firebase Hosting cannot be used as a proxy when IP-address based authentication is required.

    Context: from a backend running on Cloud Run/Cloud Functions, how to determine client IP address, when you need to TRUST it for IP-address based access restrictions.

    You can normally find the real client IP as the first entry in the X-Forwarded-For header, but you cannot trust it.

    If you are using Cloud Run (or Cloud Functions gen 2), then as far as I can tell the Cloud Run orchestrator always sits as a proxy in front of your container. This means you can trust the last entry in X-Forwarded-For as this is the client IP seen by Cloud Run itself.… more

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close