TL;DR: Firebase Studio shuts down fully on 22 March 2027 (new workspaces disabled 22 June 2026). If your team’s small apps live there, migrate each one to a permanent home before the deadline — and pick a vendor whose only business is keeping small apps alive. This page maps Studio concepts to AgentCell cells step by step.
The timeline
| Date | What happens |
|---|---|
| 22 Jun 2026 | New Firebase Studio workspaces disabled |
| Now – Mar 2027 | Existing workspaces run; export window open |
| 22 Mar 2027 | Full shutdown |
Nine months’ notice is generous by industry standards — and it is still a forced migration of every app on the platform. Plan the move as a project, not a weekend task, if you hold more than a few apps.
Why this keeps happening (the independence argument)
Firebase Studio is not an isolated case; it is the pattern:
- Superblocks exited internal tools via acquisition (Nov 2025).
- Airplane.dev — well funded, technically differentiated, developer-native — was acquihired by Airtable in January 2024 and end-of-lifed by March.
- Heroku sits in “sustaining engineering” (maintenance) mode inside Salesforce.
A hyperscaler or platform discontinues a builder product the moment it stops fitting the roadmap. A company whose only business is small software will not. That is not sentiment — it is the purchasing argument for putting twenty internal tools on an independent vendor. Ask every alternative on your shortlist what happens to your apps if their parent pivots.
Migration mapping: Studio → AgentCell cell
| Firebase Studio | AgentCell equivalent |
|---|---|
| Project / workspace | Cell — one app, isolated, own URL |
| Google IAM access | Front door + share list — private → people → groups → org → public link |
| GCP consumption billing | Per-cell consumption (vCPU + requests), idle sleeps to zero |
| Preview URLs | Redeploy + instant rollback per cell |
| Backend / database | Per-cell datastore + object storage (design scope) |
The move, step by step
- Inventory. List every workspace: what it does, who opens it weekly, what data it touches. The metric that matters is shared with at least one other person — migrate shared tools first; archive the abandoned demos.
- Export the folder. Each app leaves as code. No proprietary runtime to untangle — that is the advantage of standard frameworks.
- Deploy.
agentcell deployfrom the folder. A frontend with abuildscript, or a folder of HTML, is detected and served as a static site with no config file. A server (Python FastAPI/Flask/Streamlit, Node Next/Express) needs aDockerfiletoday; detecting those is planned. - Re-share. Recreate the audience as a share list — specific people, a group, or the org. No auth code to port; colleagues sign in with their existing work account.
- Re-attach. Custom domains, env vars, and secrets are set at the boundary (
agentcell env set,agentcell domains), not pasted into code. - Verify. Check the per-cell access log: the right people opened it, nobody else did. Then delete the Studio workspace.
What doesn’t map 1:1 (honest limits)
- Google IAM depth. If tools rely on fine-grained GCP IAM roles (not just “who can open it”), that logic needs re-expressing as share-list membership plus optional per-user logic via the identity SDK.
- Deep GCP coupling. Apps bound to Firestore/BigQuery-specific APIs keep those backends; AgentCell hosts the app and reaches them over configured egress — it does not re-platform your data.
- Pricing. There is no per-app fee either way, but metering differs (GCP service meters vs per-cell consumption). Model the 20-cell/3-active shape — see scale-to-zero economics — before assuming parity.
- Self-host. AgentCell has no self-host story at launch. If your policy requires own-metal, say so in the beta form and we’ll tell you plainly whether the fit exists.
FAQ
Do we have to migrate all at once? No. Migrate in audience order: shared-daily tools first, monthly tools second, dormant demos last (or let them go — deploys alone are vanity).
Can an agent do the migration? That is the designed path: the agent holding the folder performs export, deploy, env/secret setup, and sharing as tool calls, in the session where the code already lives.
What should we ask other vendors? Three questions: what happens to our apps if you pivot (independence)? What does SSO for a 4-person audience cost (auth cliff)? What do twenty idle apps cost per month (idle economics)? Any vendor that can’t answer all three crisply is not a home for small software.
Migrating off Firebase Studio? Deploy now — tell us how many workspaces you hold and we’ll plan the move with you.