# Firebase Studio Is Shutting Down — Where to Put Your Small Apps

> Google disabled new Firebase Studio workspaces in June 2026 and shuts it down fully in March 2027. How to land each small app somewhere permanent, with sharing intact.

Published: 2026-09-19  
Canonical: https://agentcell.dev/resources/migrate-firebase-studio  
Markdown: https://agentcell.dev/resources/migrate-firebase-studio.md

> **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

1. **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.
2. **Export the folder.** Each app leaves as code. No proprietary runtime to untangle — that is the advantage of standard frameworks.
3. **Deploy.** `agentcell deploy` from the folder. A frontend with a `build` script, 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 a `Dockerfile` today; detecting those is planned.
4. **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.
5. **Re-attach.** Custom domains, env vars, and secrets are set at the boundary (`agentcell env set`, `agentcell domains`), not pasted into code.
6. **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](/resources/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](/docs/deploy/) — tell us how many workspaces you hold and we'll plan the move with you.*