Best Practices for Multi-Environment Setup (DEV/PROD) in Firebase Studio?

General
, ,
1

Hi everyone,

I’m currently working with Firebase Studio, and while the tool is very promising for rapid development, I’m struggling with how to properly set up multiple environments, particularly Development (DEV) and Production (PROD).

There seem to be conflicting or incomplete suggestions across the documentation, in-tool chatbots, and external resources. Some of the approaches I’ve seen include:

  • Using .env.<project> files
  • Managing secrets via apphosting.yaml and the Secret Manager
  • Leveraging NIX-style config switches
  • Others suggest manually managing environments via Firebase projects and build pipelines outside the Studio

However, within Firebase Studio itself, I feel like there’s very limited control. For instance:

  • The “Publish” functionality gives no clear indication of which environment is being deployed to.
  • I couldn’t choose the region for hosting or functions — it just deployed without asking.
  • It’s unclear how to prevent accidentally overwriting production during development.

My question is:

How do you properly structure and manage a multi-environment architecture (at minimum, DEV and PROD) when using Firebase Studio from the beginning?

Some sub-questions:

  • Is there official support for environment separation in Firebase Studio workflows?
  • What’s the recommended way to manage secrets per environment?
  • Can Studio projects be linked to specific Firebase projects per environment?
  • How can one test changes in DEV and explicitly promote to PROD?

Any real-world examples, docs, or workflows would be greatly appreciated. I want to ensure I’m not misusing the tool or missing some critical setup steps early on.

Thanks a lot in advance!

3 Likes
2

Any hints on this one? I tried many approaches, but the “published” version (via the button in the studio UI) always points to the same firestore DB than the local one.

3

There is probably a more official answer- but I have been doing a lot of prototyping in Firebase Studio and the best approach I have found is to lean heavy in on GitHub and I wrote my own cloud build trigger scripts. But something like this would be much better supported as a native feature-- almost like a profile or an environment setup. You would define what “PROD” and what “TEST” actually means in terms of deployment and project names and be able to switch profiles.

4

Thanks, I have fallen back to exactly that approach: triggered deployment based on git commit event (or even manual).
on the secret manager, I recommend to use CLI to grant access to each secret because it will apply the correct service accounts (that was one root cause of my problems)