ORACIS
Start a project
Two engineers review a database schema diagram on a monitor.

Firebase Studio developer help · Next.js, Firestore, App Hosting

Fix your Firebase Studio app, and move it before the shutdown.

Google is closing Firebase Studio on 22 March 2027, and the workspace data goes with it. A senior engineer moves your app to a home you control, checks that its data is locked down, and fixes what the move exposes.

Photography is illustrative.

Front end
Next.js from the App Prototyping agent, with Gemini through Genkit
Back end
Firebase: Cloud Firestore and Firebase Authentication
Hosting
Firebase App Hosting, which keeps running after the shutdown
Workspace
Closes 22 March 2027; no new workspaces since 22 June 2026

Who this is for

For founders and teams with an app in Firebase Studio and a deadline.

Google announced in March 2026 that Firebase Studio is being sunset. New workspaces have been disabled since 22 June 2026, and on 22 March 2027 the service shuts down and its remaining data is permanently deleted. Your deployed app, Firestore, Firebase Authentication and App Hosting keep running. What goes is the workspace: the code that lives only there, and the agent's chat history, which is not included in the export.

Google offers three ways out: Google AI Studio, Google Antigravity, or any environment you choose, keeping the existing App Hosting backend so the URL stays the same. Moving is also the right moment to check what the prototype never had to get right, starting with the database rules.

Failure modes

What breaks in Firebase Studio apps, and in the move.

These are what we look for first. Some are about the shutdown; most are about Firebase settings that a prototype could ignore and a real product cannot.

  1. Code that exists only in the workspace

    What you see
    The only copy of the app's source is in a Firebase Studio workspace.
    What is actually wrong
    After 22 March 2027 the workspace's data is deleted and cannot be recovered. The agent's chat history sits in /home/user/.idx/ai and is not part of the ZIP export.
    How we fix it
    Export the code to a Git repository you own, keep the chat history if it records decisions you need, and confirm the exported app builds and deploys on its own.

  2. Firestore rules left open

    What you see
    Firebase warns about insecure rules, or nothing warns at all.
    What is actually wrong
    Firestore's test mode allows anyone to read and overwrite your data, and Firebase's own documentation says that with open rules, anyone who guesses your project ID can steal, modify or delete it. The prototyping agent writes and deploys rules when it adds Firestore; they still need checking against what each collection holds.
    How we fix it
    Rules written collection by collection against who should see each document, tested with the Firebase emulator, including the cases that must be denied.

  3. The Gemini key in the wrong place

    What you see
    Unexpected Gemini usage, or a key visible in the repository.
    What is actually wrong
    Firebase Studio stores the Gemini API key in a workspace .env file. Google says it must never be in code or config. Firebase API keys are not secret by design, but restricting them is still critical, and App Check protects the APIs behind them.
    How we fix it
    The Gemini key moved to a server-side secret, every API key restricted, and App Check turned on where the app calls Firebase services.

  4. Secrets that reach the browser bundle

    What you see
    A key shows up in the browser, or a build works locally and fails on App Hosting.
    What is actually wrong
    App Hosting reads variables and secrets from apphosting.yaml or the console, and console values override the file. Each can be limited to build or runtime. In Next.js, anything starting NEXT_PUBLIC_ is sent to the browser.
    How we fix it
    One documented source for each variable, secrets in Cloud Secret Manager used only on the server, and the built bundle checked.

  5. A URL that changes in the move

    What you see
    After moving, the app has a new address and sign-in breaks.
    What is actually wrong
    Deploying to a new App Hosting backend gives a new URL. Google's migration guide keeps the URL by linking the exported project to the existing "studio" backend.
    How we fix it
    The move done against the existing backend, and sign-in and every external link tested on the final address.

  6. Two kinds of rollback, and data neither one restores

    What you see
    You rolled back and the problem is still there.
    What is actually wrong
    The prototyping agent rolls back changes in the workspace, and App Hosting can roll back to an earlier build. Neither changes the documents already written to Firestore.
    How we fix it
    Backups and a restore we have tested, and data changes made through reviewed scripts rather than by hand.

Before you hire anyone

What to try yourself first in Firebase Studio.

  1. Export the code today. Download the workspace as a ZIP, or use the Firebase CLI's studio:export, and put it in a Git repository you own.
  2. Choose where it goes. In the Firebase Studio workspace, Move now prepares the project for Google AI Studio; Google Antigravity takes the ZIP or the CLI export (npx firebase-tools@latest studio:export) and runs a migration agent; any other environment works with the ZIP.
  3. Keep the URL. If you move to your own environment, run firebase init apphosting and link it to the existing "studio" backend, as Google's migration guide describes.
  4. Check your Firestore rules. In the Firebase console, look for rules that allow every read or write. If you find one, fix it before anything else.
  5. Find the Gemini key. Make sure it is not in code or config, and restrict every API key the project uses.
  6. Roll back a bad release. If a deploy breaks the app, App Hosting can roll back to an earlier build while you fix the cause.

How we work

How we work on a Firebase Studio app.

After the move, the code lives in a Git repository you own and the Firebase project stays in your Google account. We work in that repository, in branches merged by pull request, with a deploy pipeline you control.

If you would rather keep building with an AI agent, Google's own destinations are AI Studio and Antigravity, and we leave the project in a state either can pick up.

  1. A free 20-minute call

    You show us the Firebase Studio app and tell us what is going wrong. We say what we expect to find, and whether a paid check is worth it yet.

  2. Quick Security Check or App Readiness Review

    A senior engineer reads the code and tests the running app: data access, keys, sign-in, payments, deployment.

    You get Every finding in writing with its severity and fix; the review adds a keep, change or replace call for each part and a fixed quote.

  3. Fixed-price fixes

    Security & Data Hardening from $7,500, or Production Launch from $15,000, in your repository, with a test beside each fix.

  4. Handover

    Production kept apart from development, a deploy you can roll back, and notes so you, the tool or any developer can carry on.

Prices

Where to start, and what it costs.

  1. App triage call

    Free

    20 minutes

  2. Quick Security Check

    $495

    Delivered in 48 hours. The fee is credited toward the App Readiness Review.

  3. App Readiness Review

    $1,500 flat

    5 business days. The fee is credited toward any fix booked within 30 days.

Fixes are priced after the check or review, at one fixed price before anything starts. The full price list and how fees are credited.

Proof

Who does the work.

A US software engineering firm. The founding team has taken a product off an AI app builder before (built, not yet in paid use) and runs a production telehealth platform on Supabase. We are an independent firm, not a Firebase Studio partner or agency. Across the systems the team built and runs:

  • 20,900+ automated tests across the systems the founding team built and runs
  • 16,800+ CI runs automated builds and test runs on GitHub Actions
  • 940+ merged pull requests across the same codebases

Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted

Questions buyers ask

Firebase Studio questions, answered.

Will my live app stop working on 22 March 2027?

According to Google, no: deployed apps, Firestore, Firebase Authentication and App Hosting keep running. What closes is the Firebase Studio workspace, and the data left in it is permanently deleted.

Where should I move it?

Google AI Studio, Google Antigravity, or your own environment with the existing App Hosting backend. We recommend one after looking at how you want to keep building.

Can you check my Firestore rules?

Yes. That is part of the Quick Security Check: we test the rules from the outside, as a stranger and as another user, and tell you in writing what is exposed.

Will you rewrite everything?

Rarely. The review marks each part keep, change or replace, with the reason, before any work is priced.

Are you affiliated with Google or Firebase?

No. Oracis is an independent US software engineering firm. We fix, finish and move apps built with Firebase Studio, alongside apps from Lovable, Replit, v0 and other tools.

What does it cost to fix a Firebase Studio app?

The first call is free. The Quick Security Check is $495 and its fee is credited toward the App Readiness Review, which is $1,500 flat and credited toward any fix booked within 30 days. Security & Data Hardening is from $7,500 and Production Launch from $15,000, each at one fixed price set after the review. We never bill hourly on work nobody has sized. The full price list.

Send us the Firebase Studio app.

The project, where the code lives today, and when you want it moved.

Get your app checked