Thanks @taeold 👍🏻 for creating this new issue

@taeold In general, I would have expected to configure all config via params...

For us, this is a blocking feature, as we no longer can supply the service account with the prefix:
serviceAccount@, which depending on the project, would either resolve to serviceAccount@prod-project... or serviceAccount@stage-project...

@taeold do you have some visibility about this issue ?

@fgruchala Sorry for the silence. We are actively working on getting service account parametrizable and going through internal process to get the API approved. Will keep you all posted.

@taeold @Berlioz do you have any information ?

WIP #5234

WIP #5234

Huge thanks

Any news here? I'm also unable to parameterize serviceAccount within runWith ...

@taeold is something similar planned for the function region?

@Hibrix-net @fgruchala I faced the same challenge.

For now, I resorted to using the GCLOUD_PROJECT env var to construct the actual service account name at deployment time. Of course, this is only a possible solutions if the service accounts have the same name.

import { defineString } from 'firebase-functions/params';
import { setGlobalOptions } from 'firebase-functions/v2/options';

const gcpCloudRegionParam = defineString("DSQ_GCP_CLOUD_REGION")

setGlobalOptions({
    region: [gcpCloudRegionParam],
    serviceAccount: `cloud-run-functions@${process.env.GCLOUD_PROJECT}.iam.gserviceaccount.com`
})

Do you know if this is fixed now? I remember a PR from @taeold about it in the past, if I'm not mistaken.

@IchordeDionysos not fixed. I just tried a few days ago and it didn't work.

@stfsy but you can supply an Expression no? 🤔
https://github.com/firebase/firebase-functions/blob/master/src/v2/providers/https.ts#L141

Are you using functions v1 or v2?

@IchordeDionysos yeah but an expression is not a param, I guess.

I wrote a blog post about the issue yesterday: https://medium.com/@stfsy/different-service-accounts-for-firebase-functions-per-stage-e667db4059e4. Gist is the serviceAccount parameter does not get resolved, but merely copied as is:

Thus, when passing a param instead of a string value, the param expression will be used and not the value that could be.

You can see in branch that was created for the PR this line was added to actually resolve the value of the serviceAccount param

I added this line to the current firebase-tools version and it works pretty fine. The whole refactoring that was started for the serviceAccount param is not really necessary to fix this issue in my opinion.

I am using v2 functions.

23-Mar-2025

This still does not work.

   {
     "functions": {
       "source": "functions",
       "serviceAccount": "your-firebase-service-account@your-project-id.iam.gserviceaccount.com"
     }
   }

I am running into an issue where "firebase deploy --only functions:my_func (example) deploys to the Cloud function's default service account, and not the service account shown on the Firebase Console. I do not know why this happens, but the fact that the override as above does not work means, I am stuck with this issue. Note that I have several non-org accounts and for those projects the service account of the Firebase Console is used right.