I’m seeing a repeatable difference between publishing from Firebase Studio and deploying to the same App Hosting backend from the Firebase CLI. When I publish from Firebase Studio, the app works normally. When I deploy from my local machine with firebase deploy --only apphosting, the same backend URL starts failing with Firestore permission-denied errors, even though the app works locally, the local production build (npm run build && npm run start) works, the Firebase project and rules look correct, and the broken deployed app is clearly talking to the correct Firebase project/database. I also confirmed that restoring apphosting.yaml to a minimal form still does not fix the CLI-published version, while a fresh Firebase Studio publish immediately works again. This makes it look like there is some important difference in the CLI publish path vs Firebase Studio publish path for App Hosting, even when targeting the same backend. Has anyone seen this, or is there a known difference in how Firebase Studio and CLI deploys package/configure App Hosting rollouts?
ok made progress. 3.1 Pro and CGPT5.4 did not help much. Finally found out accidentally it was some Captcha shit. I don’t even know how exactly I solved it other than putting some secret key on some cloud console hole. I need to sit down and document this shit.. because there is no way a human could navigate through the maze of Google and Firebase dashboards and come out sane. Zero intelligence involved here, just pure digging through curiously designed interfaces.
Hi, thanks for this feedback, we have a guide for migrating here: Firebase Studio sunset and project migration
was it the Gemini API key that you had to set?
If not I’d be very interested in any additional steps you had to take and we can look into it and improve the flow.
Setting the Gemini API key would have been trivial. Given that I always used Vercel for deployment before, and my experience publishing on Google has been through Firebase studio or aistudio, a lot of the back end stuff was missing in my mental model. So I had to familiarize myself with stuff I wish I did not have to think about. E.g. one thing I found out is that for publishing your app, you need to make sure you use apphosting.yaml but the one that was generated for me by 3.1 pro was incomplete (missed the Firebase Service Account key. Then I ran into issues regarding how secrets are propagated… one can save secrets directly through some path in the Google dashboard (but gave up), but soon found out that you could do that easily through some firebase CLI commands. Lots of little things like that. Then you had to figure out keys that available during build and runtime… and there was a key on Stripe that was supposed to last forever but mysteriously expired. Given all that mess, I sat down and studied how all these parts interact with each other, got aistudio to make me an exploratory interactive architectural diagram. That kind of made my mental model a bit more comfortable. For now am sticking with Gemini CLI, Local folder, Github, Firebase backend for my work practice.
apphosting.yaml was supposed to get created when you run
“firebase init apphosting”
as per Firebase Studio sunset and project migration
The secrets propagation should happen automatically as well when running the migration skill (@fbs-to-agy-export) in Antigravity.
I’m sorry this migration flow isn’t more straight forward though. When we have the migration to AI Studio live it should be easier.
Do you recommend that I should use Antigravity over Gemini CLI?
Hey, we have a guide to help make that decision here https://cloud.google.com/blog/topics/developers-practitioners/choosing-antigravity-or-gemini-cli
Thank you, very helpful.