# How to Export and Deploy Firebase Studio App Before Shutdown > Export your Firebase Studio app before the 2027 shutdown, move it to GitHub, deploy safely with Kuberns, and reconnect the Firebase services it needs. - **Author**: harsh-kanani - **Published**: 2026-10-07 - **Modified**: 2026-10-07 - **Category**: Deployment Guides - **URL**: https://kuberns.com/blogs/move-firebase-studio-app-before-shutdown/ --- Firebase Studio is shutting down on March 22, 2027. If your application still exists only inside a Studio workspace, export it before the deadline, place the source in a GitHub repository you control, and deploy it through a hosting workflow that does not depend on Firebase Studio. A practical independent path is to export the application source, store it in a GitHub repository you control, and deploy that repository separately. The application can still use its existing Firebase project for authentication, data, files, and backend services. This guide shows how to preserve the complete project, export it from Firebase Studio, prepare it for production, deploy it with [Kuberns](https://kuberns.com/), and reconnect the Firebase services it already uses. **TL;DR:** - Export every Firebase Studio workspace you need before March 22, 2027. - Preserve the source, configuration, rules, indexes, environment-variable inventory, and deployment details. - Keep secrets and private credentials out of GitHub. - Use GitHub as the source of truth for the exported application. - Deploy the repository independently with Kuberns. - Keep Firestore, Firebase Authentication, Storage, or other Firebase services connected when the application depends on them. - Test authentication and the custom domain before switching production traffic. ## What Happens If You Do Not Move Your Firebase Studio App? Google's [official Firebase Studio migration guide](https://firebase.google.com/docs/studio/migrating-project) states that Firebase Studio will shut down on March 22, 2027. New workspace creation and new-user registration were disabled on June 22, 2026, while existing workspaces remain available until the shutdown date. If you do not export or migrate the workspace, Google says its remaining data will be permanently deleted after shutdown. That can leave you without the Studio copy of your source, agent context, local workspace configuration, or a reliable way to reproduce the application. The risk is not that every Firebase product disappears. The risk is waiting until the development workspace is unavailable and only then discovering that the latest code, environment-variable inventory, build instructions, or ownership details were never preserved elsewhere. Community discussions show developers asking whether the announcement means [Firebase itself is shutting down](https://www.reddit.com/r/Firebase/comments/1rysgyk/firebase_studio_is_shutting_down_what_you_need_to/). The practical response is to preserve the application now, verify that the export works, and establish a new source-controlled deployment path before the deadline. > **Related guide:** If the exported project only works in its local or preview environment, use the [backend-from-localhost deployment guide](https://kuberns.com/blogs/deploy-backend-from-localhost/) to identify production ports, URLs, secrets, and runtime requirements. ## What Should You Preserve Before Firebase Studio Closes? Do not treat a folder of source files as a complete backup. A deployable application also depends on configuration, external resources, domain settings, and production values that may not be visible in the code. Preserve this inventory for each workspace: - Complete application source and current Git history, if available - `package.json`, lockfiles, and framework configuration - `firebase.json` and App Hosting configuration - Firebase project ID and public client configuration - Environment-variable names and the location of their production values - Firestore Security Rules and indexes - Storage Rules - Cloud Functions source and deployment configuration - Authentication providers and authorized domains - OAuth redirect and callback URLs - Custom-domain DNS records - Build command, start command, runtime version, and application port - Current production URL and webhook endpoints - Important agent prompts, decisions, and development notes Google notes that agent chat history is not included in the standard exported ZIP. If a conversation contains requirements or decisions that are not documented elsewhere, preserve the relevant information separately. The migration guide identifies the workspace chat data under `/home/user/.idx/ai`. | Safe to store in GitHub | Keep out of GitHub | |---|---| | Source code and dependency files | `.env` files containing real values | | Firebase configuration that is intended for client use | Private API keys and backend secrets | | Rules, indexes, and configuration templates | Service-account private keys | | `.env.example` with names and safe placeholders | Database passwords and access tokens | | Build and deployment documentation | Production credentials | Firebase web configuration is not automatically a secret. Security still depends on Firebase Authentication, authorization, and correctly written Security Rules. Server credentials and private service-account material must remain server-side. > **Related guide:** Use the [production environment-variable guide](https://kuberns.com/blogs/environment-variables-in-production/) to separate safe configuration from secrets before moving the exported project. ## The Best Way to Move Your Firebase Studio App For developers asking where to host a Firebase Studio project after shutdown, a direct independent path is: ```text Firebase Studio export ↓ GitHub repository you control ↓ Kuberns deployment ↓ Existing Firebase services, when needed ``` GitHub becomes the source of truth, so your application is no longer tied to one development interface. You can use another editor or AI coding assistant without changing the deployment destination every time your development workflow changes. Kuberns fits this independent path. It is an Agentic AI platform for deployment that connects to the repository, detects the application stack and runtime requirements, and prepares the deployment configuration for review. It does not automatically move Firestore data or import Firebase Authentication users. The deployed application can continue connecting to the existing Firebase project when those services are required. Google also documents migration to Google AI Studio and Google Antigravity. Those are reasonable choices when you specifically want their development environments. GitHub plus Kuberns is the stronger fit when your goal is to control the source repository and establish a deployment workflow independent of Firebase Studio. **Export the application concisely:** - **GitHub sync:** Use it when the latest workspace changes are already synchronized. Confirm the branch, repository owner, and most recent commit. - **Zip and Download:** Open **Move now**, choose **Zip and Download**, and save the archive outside the workspace. Check blocked browser pop-ups if the download does not start. - **Firebase CLI:** Run `npx firebase-tools@latest studio:export PATH`. Google says this export is optimized for Next.js, Flutter, and Angular, so other project types may need cleanup. After exporting, place the verified source in GitHub, clone it into a clean directory, and run its production build. Do not assume that an archive or synchronized repository is complete until it works outside the Studio workspace. If the workspace is shared, confirm ownership before moving it. Google states that only the workspace creator can use **Move now**, and a manually exported shared workspace may still refer to Firebase resources owned by the original creator. > **Related guide:** Once the export is in GitHub, follow the [GitHub auto-deployment guide](https://kuberns.com/blogs/how-to-auto-deploy-your-apps-from-github-in-one-click/) to understand how later repository changes can reach production through the same workflow. ## Prepare the Exported Application for Independent Deployment An application that works in a Firebase Studio preview is not automatically ready for a different production environment. Run it from the exported repository and identify every dependency on Studio, emulators, or local services. Confirm the following: - The production build completes from a clean checkout. - The repository includes the correct dependency and lock files. - The production start command is known. - Server code listens on the platform-provided port and an external interface. - Frontend and backend URLs do not point to `localhost`. - Firebase emulators are disabled in production. - The application points to the intended production Firebase project. - Required environment-variable names are documented. - Server secrets are not included in the browser bundle. - Firestore and Storage Rules are suitable for production access. - Any Cloud Functions or extensions that remain on Firebase are documented. - The application does not expect permanent storage on its local filesystem. | Local or Studio assumption | Production requirement | |---|---| | Preview process starts automatically | Explicit production build and start commands | | Firebase emulator is available | Production Firebase project configuration | | Secret exists in the workspace | Secret configured at the deployment destination | | Frontend calls `localhost` | Public HTTPS API or service URL | | Studio owns the latest files | GitHub branch owns the deployable source | > **Related guide:** If the export includes an API or server process, the [backend deployment guide](https://kuberns.com/blogs/deploy-backend-from-localhost/) explains production start commands, ports, public URLs, and frontend connectivity. ## Deploy a Firebase Studio App on Kuberns With Agentic AI Once the exported project builds successfully and the repository is current, the deployment itself can remain simple. Kuberns becomes the deployment layer, while Firebase can remain the backend for the services the application still needs. ![Kuberns Agentic AI platform for deploying an exported Firebase Studio application](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png) **Step 1: Export the Firebase Studio app to GitHub:** Export or synchronize the latest application source, then put it in a repository owned by you or your organization. Confirm that the intended production branch contains the newest code, dependency files, Firebase configuration, rules, indexes, and build instructions. Keep `.env` files and private credentials out of the repository. **Step 2: Connect the repository to Kuberns:** Open the [Kuberns dashboard](https://dashboard.kuberns.com/), sign in with GitHub, and authorize the repository that contains the exported application. Select the repository and branch that should become the production source. ![Connect the exported Firebase Studio repository to Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-registration.png) *Select the verified repository and production branch before Kuberns begins analyzing the application.* **Step 3: Review the stack detected by the deployment agent:** Kuberns analyzes the repository to identify the framework, application root, dependency files, build command, start command, port behavior, and required variable names. This reduces manual setup, but you should still review the result against the application you exported. Correct any command or root directory that does not match the repository. ![Kuberns deployment agent detecting and preparing the Firebase Studio application](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/agent-deployment-process.png) *Review the detected framework, build process, runtime, and required configuration before starting deployment.* **Step 4: Add the production configuration:** Enter the environment values required by the application, including server-side API keys or credentials that were previously stored in Firebase Studio. Confirm that the Firebase project ID belongs to the intended production project and that no production setting still points to an emulator, preview URL, or `localhost`. Do not copy the old `.env` file blindly. Separate public Firebase client configuration from private server credentials, replace development URLs, and rotate any secret that was previously exposed. **Step 5: Deploy and inspect the application:** Start the deployment after reviewing the configuration. Follow the build output while dependencies install and the production build runs. If the process fails, use the first meaningful error to identify whether the problem is a missing dependency, environment variable, build command, start command, or Firebase connection. ![Kuberns dashboard showing the deployed Firebase Studio application and its logs](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/all-in-one-dashboard.png) *Use the application dashboard to inspect deployment status, build output, runtime logs, and the generated URL.* **Step 6: Verify the live application and connect its domain:** Open the generated HTTPS URL and test the workflows that rely on Firebase. Create and sign in to a test account, read and write permitted Firestore data, test file uploads, and verify any server routes or Cloud Functions the application calls. Connect the production domain only after these checks succeed. After the first successful deployment, GitHub becomes the stable handoff between development and production. You can keep using a supported editor or coding assistant without rebuilding the deployment workflow around that tool. > **Related guide:** Review [how Kuberns secures production applications](https://kuberns.com/blogs/kuberns-application-security/) before adding production secrets, access controls, and customer data to the deployment. ## Keep Firestore and Firebase Authentication Connected Moving the application runtime does not move or delete the Firebase project. Your exported app can continue using Firebase Authentication, Firestore, Realtime Database, Cloud Storage, Cloud Functions, and extensions when its configuration and permissions remain valid. This is an important safety boundary. One Firebase community question asks whether changing hosting resources could [delete the application's database](https://www.reddit.com/r/Firebase/comments/1qx76ac/duda_con_app_hosting/). Hosting, Studio workspaces, and Firebase data resources are separate. You should still record the project ID, confirm ownership, and take appropriate backups before changing production infrastructure. **Reconnect Firebase Authentication:** - Add the new Kuberns domain to Firebase Authentication's authorized domains. - Update Google Sign-In and other identity-provider redirect URLs. - Update email-action URLs used for password resets and email verification. - Confirm that secure cookies and sessions work over HTTPS. - Test account creation, login, logout, and password reset. - Verify that users remain in the original Firebase project. Google's migration documentation specifically calls out authorizing the new domain for Google Sign-In. A working page on the new URL does not prove that its authentication callbacks are correct. **Verify Firestore and Storage:** - Read an existing record that the test account is allowed to access. - Create and remove disposable test data. - Confirm that Firestore Security Rules still enforce the intended access. - Upload and retrieve a disposable test file. - Verify that the app is not calling emulator endpoints. - Review Firebase logs and Kuberns runtime logs for denied or malformed requests. - Confirm that no private service credential is exposed in browser code. If the exported project includes a server that uses the Firebase Admin SDK, configure its credentials as server-side secrets. Do not place a private service-account key in client code or commit it to the repository. > **Related guide:** The [production environment-variable guide](https://kuberns.com/blogs/environment-variables-in-production/) shows how to configure application values without exposing server credentials in code or GitHub. ## Move the Custom Domain Safely Do not point the production domain to the new deployment before the temporary Kuberns URL works. Domain changes can affect sign-in callbacks, email links, webhooks, cookies, and integrations even when the page itself loads. Use this sequence: 1. Deploy the exported application to its temporary Kuberns URL. 2. Test authentication, data access, uploads, API routes, and critical user journeys. 3. Record the existing DNS values and lower DNS TTL in advance when appropriate. 4. Add and verify the domain in Kuberns. 5. Update Firebase Authentication and external OAuth providers for the production domain. 6. Change DNS only after the new deployment is ready. 7. Keep the previous deployment available during verification when possible. 8. Retest HTTPS, callbacks, email actions, webhook endpoints, and redirects. DNS propagation and third-party callback changes can take time, so this article does not promise a zero-downtime cutover. > **Related guide:** Follow the [custom-domain setup guide](https://kuberns.com/blogs/add-custom-domain-to-your-deployed-app/) after the temporary Kuberns URL and Firebase-connected workflows have been verified. ## What Does Your Workflow Look Like After Firebase Studio? The post-Studio workflow separates four responsibilities: ```text Code editor or AI coding assistant ↓ GitHub repository ↓ Kuberns deployment ↓ Firebase Auth / Firestore / Storage ``` The editor helps you change the application. GitHub keeps the deployable source and its history. Kuberns deploys the selected repository and exposes build and runtime evidence. Firebase continues serving the backend products the application uses. This separation prevents the next editor change from becoming another hosting migration. You can adopt a different coding assistant later while the repository and deployment path remain stable. > **Related guide:** Use the [GitHub auto-deployment guide](https://kuberns.com/blogs/how-to-auto-deploy-your-apps-from-github-in-one-click/) to keep future production deployments connected to the selected repository branch. ## Export Before the Firebase Studio Shutdown You do not need to rebuild an application simply because Firebase Studio is closing. Export the source, preserve its configuration, move it into a repository you control, and create a deployment workflow that no longer depends on the Studio workspace. Kuberns provides an independent deployment path for the exported repository. The application can run through Kuberns while Firebase Authentication, Firestore, Storage, and other Firebase services continue serving it. Complete the export early enough to test the build, environment values, authentication, data access, and domain cutover before March 22, 2027. Deploy an exported Firebase Studio application with Kuberns ## Frequently Asked Questions ### Is Firebase shutting down in 2027? No. Firebase Studio is scheduled to shut down on March 22, 2027. Firebase services such as Firestore, Firebase Authentication, Cloud Functions, and App Hosting are not shutting down as part of the Studio closure. ### What happens to Firebase Studio workspaces after March 22, 2027? Google states that Firebase Studio will shut down and remaining workspace data will be permanently deleted after March 22, 2027. Export or migrate every workspace you need before that date. ### Will my Firestore data be deleted when Firebase Studio closes? No. Firebase Studio workspace data and Firestore data belong to different resources. The Studio shutdown does not delete Firestore databases, but you should verify the Firebase project ID and security configuration used by the exported application. ### Will Firebase Authentication continue working? Firebase Authentication continues operating, but an externally deployed application may require its new domain and OAuth callback URLs to be authorized before sign-in works correctly. ### How can I export a Firebase Studio app? Google documents GitHub synchronization, **Zip and Download**, a command-palette download option, and the Firebase CLI `studio:export` command. Verify that the export contains the latest source and required configuration before relying on it. ### Does a Firebase Studio export include environment variables? Do not assume that production environment values or secrets will move automatically. Create a variable inventory, keep secrets out of GitHub, and configure the required values at the new deployment destination. ### Can I deploy a Firebase Studio app outside Firebase Studio? Yes. Google documents exporting a project for another development or hosting platform. The exported application still needs a successful production build and the correct runtime, environment, authentication, and domain configuration. ### Can Kuberns deploy an exported Firebase Studio app? Kuberns can deploy a supported application from its GitHub repository after the framework, build process, runtime requirements, and environment configuration are confirmed. ### Can an app on Kuberns continue using Firestore? Yes. Moving the application runtime does not require moving Firestore. Configure the exported app to use the existing Firebase project and verify its authentication, authorization, and Security Rules. ### Why does Firebase Authentication fail on the new domain? The new application domain may not be authorized in Firebase Authentication or the identity provider. Add the domain, update relevant callback and email-action URLs, and retest login, logout, account creation, and password reset. ### What should I do if Zip and Download does not work? Check whether the browser blocked the download pop-up and remove unnecessary large folders from the workspace. If the issue continues, use an up-to-date GitHub copy or Google's Firebase CLI export command. --- - [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/) - [All articles](https://kuberns.com/blogs/)