Sudden increase in Firebase Storage Reason & Solution

I noticed that firebase storage usage is increasing rapidly. It consumed around 440MB storage space that am not used for userdata storage. Its clear that storage is accumulated somewhere else.

Analysing Storage Usage Tab you could find


It is clear that on that particular day there is a 440MB increase in storage and is used by us.artifacts.project Bucket. This is usually caused by cloud function usage. Inorder to remove this unwanted usage there is one solution


goto Select your project
Select the “artifacts” bucket
Under the “lifecycle” tab add a rule to auto-delete old temporary data here I put “delete after 1 day since update

After that, any additional storage usage will be removed after 1 day. It will take up to 3 days to reflect in the dashboard.


Optimization and costs reduction of Firebase

Go to Life Cycle settings for artifacts images, you can also consider the following for further optimization and costs reduction of your Firebase Functions deployment:

  1. Clean up your functions folder, don’t put unnecessary files in it, as we do not know if Google will only upload files by dependencies or by the whole functions folder.
  2. Remove unnecessary dependencies 
    from functions/package.jsonfunctions/node_modules and require statements from your JS files, e.g. functions/index.js.
  3. Compact and compress your function’s JS files by removing unnecessary comments, console loggings etc. You can achieve this with the help of grunt and uglify NPM packages. Again, we’re not sure if the Cloud Build (or any of the Google functions deployment system) will auto-compress the function’s images for us before storing them into the Container Registry or Cloud Storage
  4. Organize your functions properly by creating relevant function groups so that you can deploy only certain group(s) of function rather than simply firebase deploy --only functions.
  5. If necessary, write codes that automatically detect and resolve environmental differences, e.g. environment variables from local emulators to production/staging, because the Firebase emulators and production environments may not be 100% consistent. If you don’t do that, you may end up needing to deploy several times per day due to certain negligence — this will spike up your deployment cost.
  6. If necessary, change your deployment plan: from daily to weekly, or even from weekly to monthly, depending on your monthly budgets, criticality, and urgency.

Above will help to reduce firebase storage usage and thus your reduces firebase billing
– Firebase Storage rapid increase
– Firebase unnecessary usage of storage
– Firebase billing going high
– Firebase billing for storage

You may also like...