Quem pesquisa “Firebase Studio” hoje ainda encontra tutoriais animados: crie um app descrevendo o que quer, publique com um clique, tudo no navegador. O que esses textos não dizem é que a ferramenta tem data para acabar. O Google anunciou o encerramento em março de 2026, fechou a porta para novos usuários em junho e marcou o desligamento para 22 de março de 2027.
Este guia explica o que é o Firebase Studio, o que acontece em cada data e, principalmente, o que a empresa que já tem um app lá precisa fazer: quem pode migrar, para onde levar o projeto, o que fica para trás no caminho e como não trocar o endereço do app sem querer. Tudo a partir da documentação oficial do Firebase, conferida em 28 de outubro de 2026.
O que é o Firebase Studio?
Segundo a página oficial do produto, o Firebase Studio é um ambiente de desenvolvimento na nuvem, com agentes de IA, para criar e publicar aplicações completas: API, back-end, front-end e app móvel. Ele roda no navegador, sobre uma máquina virtual do Google Cloud, e reúne o antigo Project IDX com agentes especializados e a assistência do Gemini.
Na prática, ele atendia dois públicos com a mesma ferramenta. De um lado, quem não programa e queria sair de uma ideia para um app funcionando conversando com a IA. De outro, desenvolvedores que queriam um editor de código completo sem instalar nada na máquina, com modelos prontos para Next.js, React, Angular, Flutter, Python e outras linguagens.
Um detalhe da própria documentação ajuda a entender o encerramento: o Firebase Studio sempre esteve em Preview, sem acordo de nível de serviço nem política de descontinuação. Em outras palavras, o Google avisava desde o começo que o produto podia mudar ou sair do ar.
Como funciona o Firebase Studio por dentro?
O Firebase Studio tem dois modos de trabalho, e saber qual deles a sua equipe usou define o caminho de migração mais adiante.
1. Modo por prompt: o App Prototyping agent
O agente de prototipagem, também chamado de Prototyper, cria um app web a partir de texto, imagem ou desenho. Se o app precisa de banco de dados ou login, o agente configura sozinho o Cloud Firestore e o Firebase Authentication. Dali, o app é publicado no Firebase App Hosting, com um endereço terminado em hosted.app ou com domínio próprio.
2. Modo código: o editor completo
O segundo modo é um editor baseado no Code OSS, o mesmo projeto aberto que está na base do VS Code, com terminal, extensões, emuladores do Firebase e o Gemini ajudando a escrever, testar e corrigir código. Dá para importar um repositório, partir de um modelo pronto ou trazer um design do Figma.
Os dois modos conversam: é comum começar no prompt e depois passar para o código para ajustar uma regra de negócio. Esse vaivém é justamente o que complica a migração, porque um projeto nascido no Prototyper pode ter ganhado tanto código que já não cabe no caminho “só prompt”.
O Firebase Studio vai ser descontinuado? Quais são as datas?
Sim. O encerramento está na página oficial de encerramento e migração do Firebase Studio, e o Google justifica a decisão como uma simplificação: o que aprendeu no Firebase Studio passa para duas ferramentas principais, o Google AI Studio e o Google Antigravity.
A palavra que pesa é permanentemente. Não existe período de carência descrito na documentação nem lixeira de onde pedir o projeto de volta. Até o desligamento, o Google diz que continua entregando correções críticas de segurança e atualizações do modelo Gemini, então os projetos atuais seguem estáveis enquanto a equipe se organiza.
O que acontece com o app publicado depois do fim do Firebase Studio?
Aqui está a boa notícia, e também a confusão mais comum. O encerramento vale para o ambiente de desenvolvimento, não para o app. A documentação diz que os apps já publicados no Firebase continuam rodando depois da data, e que bancos de dados, Cloud Firestore, Authentication e App Hosting não são afetados.
O problema é o dia seguinte. O app continua no ar, mas o lugar onde ele era editado deixa de existir. Se ninguém tiver tirado o código de lá, a empresa fica com um sistema rodando que ninguém consegue mais alterar pelo caminho de sempre: nem para corrigir um erro, nem para mudar um texto, nem para atualizar uma dependência.
| Continua depois de 22/03/2027 | Some em 22/03/2027 | |
|---|---|---|
| App publicado no Firebase | Sim, segue rodando | — |
| Cloud Firestore e dados dos usuários | Sim, sem mudança | — |
| Firebase Authentication | Sim, sem mudança | — |
| Firebase App Hosting | Sim, o back-end continua | — |
| Workspace, código e arquivos não migrados | — | Apagados sem recuperação |
| Histórico de conversa com o agente | Só se for baixado à parte | Apagado junto com o workspace |
Elaborado pela Alliance Comunicação a partir da documentação oficial do Firebase Studio (atualizada em 20/10/2026).
O Firebase Studio é gratuito? E o plano Blaze?
O acesso ao ambiente é gratuito. O que mudava era o número de workspaces por pessoa, conforme o perfil no Google Developer Program. Desde 22 de junho de 2026, a própria página de preços e limites do Firebase Studio avisa que essas cotas deixaram de valer para novos cadastros, porque não há mais cadastro novo.
Para quem vai migrar, a parte que importa é a segunda. Se o app foi publicado no App Hosting, o projeto do Firebase já tem uma conta de faturamento ligada e está no Blaze. Essa conta continua cobrando o uso do app depois do fim do Firebase Studio. Antes de migrar, vale descobrir em nome de quem ela está e qual cartão paga, porque é comum o projeto ter nascido na conta pessoal de quem fez o protótipo.
Qual a alternativa ao Firebase Studio?
O próprio Google aponta dois destinos e um terceiro caminho por conta própria. A escolha depende de como o app foi feito, não de preferência de marca.
- Google AI Studio, no navegador, recomendado para quem criou o app com o agente de prototipagem e quer continuar trabalhando por prompt. O Google diz que integrou o Cloud Firestore e o Firebase Authentication ao AI Studio.
- Google Antigravity, um ambiente instalado na máquina, com agentes autônomos, recomendado para quem usava o modo código, partiu de um modelo ou repositório, ou começou no Prototyper e acrescentou muita coisa. Ele aceita modelos além do Gemini, como Claude e GPT-OSS, segundo a documentação. O custo do Antigravity é outro assunto, que tratamos no guia sobre quanto custa o Google Antigravity e o crédito extra.
- Outro ambiente ou host, para quem prefere baixar o código e cuidar da publicação por conta própria, dentro ou fora do Google.
Há ainda uma porta entre os dois destinos do Google: quem começa no AI Studio pode, depois, exportar o projeto para o Antigravity pela aba de código. Ou seja, escolher o AI Studio agora não prende o app a ele.
Como migrar do Firebase Studio para o Google AI Studio sem perder a URL?
O primeiro passo é simples. O segundo é o que decide se o cliente vai continuar encontrando o app no mesmo endereço.
1. Transferir o workspace com o Move now
No topo do workspace, o botão Move now leva a “Prepare for AI Studio” e depois a “Move to Google AI Studio”. Aceitos os termos, o código abre num workspace novo do AI Studio. A conversão pode levar alguns minutos, e o AI Studio avisa quando termina.
2. Escolher a publicação: App Hosting ou Cloud Run
Aqui está a armadilha. O botão Publish do AI Studio é o caminho de um clique, mas publica no Cloud Run, com um endereço novo terminado em run.app. Quem tem domínio próprio precisa mapeá-lo para o serviço novo, e a documentação avisa que esse mapeamento pode levar até 24 horas e deixar o app fora do ar.
Para manter o endereço hosted.app ou o domínio próprio, o caminho é continuar no App Hosting, e ele tem três etapas:
- Guardar a chave da Gemini API no console. No Firebase Studio, essa chave ficava no arquivo .env e era copiada sozinha para o App Hosting. No AI Studio, isso não acontece: é preciso abrir o back-end (geralmente chamado studio) no console do Firebase e cadastrar a chave como variável de ambiente.
- Ligar o AI Studio ao GitHub, criar o repositório e conferir que o arquivo .env não entrou na lista, para a chave não ficar exposta.
- Conectar esse repositório ao back-end do App Hosting, no ramo main e na pasta raiz, e salvar. Daí em diante, cada envio ao GitHub publica o app no mesmo endereço.
Um efeito colateral costuma aparecer só depois: se o app tem login com conta Google, ele para de funcionar no endereço novo até que o domínio do app no AI Studio seja incluído entre os domínios autorizados do Authentication, no console do Firebase.
Como migrar para o Antigravity ou baixar o projeto do Firebase Studio?
Para o Antigravity, a documentação pede três coisas instaladas e atualizadas na máquina: o Antigravity IDE, o Node.js na versão 20 ou superior e a Firebase CLI na versão 15.10.0 ou superior. Depois, há dois jeitos de fazer a passagem.
1. Migração com o agente
No Firebase Studio, o Move now gera um zip com o projeto. Extraído o arquivo e aberto no Antigravity, basta pedir ao agente o comando @fbs-to-agy-export, e ele conduz a conversão pedindo ajuda quando precisa. O Google sugere o modelo Gemini Flash para gastar menos tokens nessa tarefa. Para publicar, o pedido é “Publish my app”: se o app já estava no App Hosting, ele vai para o mesmo endereço.
2. Exportação manual, sem agente
Quem prefere não gastar tokens pode rodar o comando studio:export da Firebase CLI sobre a pasta extraída. A documentação avisa que ele está otimizado para projetos em Next.js, Flutter e Angular. Em outros tipos de projeto, pode deixar partes do código sem a adaptação necessária.
3. Só baixar e publicar fora
Para levar o projeto a outro ambiente, o caminho é Move now > Zip and Download, ou enviar o workspace para o GitHub. Com o código na máquina, o comando firebase init apphosting, ligado ao back-end existente chamado studio, mantém a mesma URL. Qualquer provedor de hospedagem fora do Firebase significa endereço novo.
| Caminho | Para quem | Mantém a URL? | Ponto de atenção |
|---|---|---|---|
| AI Studio + App Hosting via GitHub | App feito por prompt | Sim | Cadastrar a chave da Gemini API no console |
| AI Studio + botão Publish | App nunca publicado, ou URL nova aceitável | Não (*.run.app) | Domínio próprio pode levar até 24 h e ficar fora do ar |
| Antigravity com o agente | App em código, modelo ou repositório | Sim, se já estava no App Hosting | Consome tokens do agente |
| Antigravity com studio:export | Quem não quer usar o agente | Sim, publicando no back-end existente | Otimizado só para Next.js, Flutter e Angular |
| Zip + Firebase CLI | Equipe técnica que cuida à mão | Sim, ligando ao back-end studio | Exige Node.js e a CLI instalados |
| Zip + host externo | Quem quer sair do Google | Não | Firestore e Authentication continuam no Firebase |
Elaborado pela Alliance Comunicação a partir da documentação oficial de migração do Firebase Studio (atualizada em 20/10/2026).
Quais armadilhas a migração esconde?
A documentação responde a maioria delas na seção de perguntas frequentes, mas espalhadas. Juntas, elas mostram que a migração é menos um clique e mais uma pequena operação de inventário.
- Só o criador do workspace usa o Move now. Quem recebeu o workspace compartilhado precisa duplicá-lo para a própria conta ou exportar o código à mão. Se o criador saiu da empresa, ou era um fornecedor, esse é o primeiro problema a resolver.
- Workspace compartilhado leva a configuração do dono. Na exportação manual, o projeto do Firebase e as chaves de API continuam apontando para os recursos de quem criou o workspace. É preciso criar um projeto novo e trocar as variáveis de ambiente.
- O histórico de conversa com o agente não vai no zip. Ele fica na pasta /home/user/.idx/ai do workspace e precisa ser baixado à parte. Para quem construiu o app por prompt, esse histórico é a única documentação das decisões tomadas.
- A chave da Gemini API não acompanha o código. Ela ficava no .env, que não deve ir para o GitHub, e precisa ser recadastrada no console para o App Hosting continuar publicando.
- Projeto pesado trava a exportação. A pasta node_modules, mídias grandes, exportações de banco e histórico extenso do git podem fazer o processo travar. A recomendação é apagá-los antes e reinstalar as dependências no destino.
- Bloqueador de pop-up engole o download. Se o Zip and Download não faz nada, o navegador provavelmente bloqueou a janela que o processo abre.
Quem na empresa precisa agir, e até quando?
O prazo oficial é 22 de março de 2027, mas a data útil é anterior. Migrar no último mês deixa sem folga para os imprevistos que a própria documentação descreve: o agente que para no meio, o domínio que leva um dia para apontar, o login com Google que quebra no endereço novo.
- Inventário: listar todos os workspaces que a empresa usa, quem criou cada um e quais estão publicados.
- Dono: garantir que cada workspace com app no ar esteja na conta de alguém da empresa, duplicando os que estão na conta de ex-funcionário ou fornecedor.
- Caminho: decidir, app por app, entre AI Studio, Antigravity e saída manual, com base em como ele foi feito.
- Endereço: anotar se o app precisa manter a URL atual. Se precisar, descartar de saída os caminhos que trocam o endereço.
- Backup: baixar o zip e o histórico do agente de todos os workspaces, inclusive os que não serão migrados, antes de mexer em qualquer coisa.
- Teste: migrar primeiro o app menos crítico, conferir login, banco e publicação, e só então repetir nos demais.
Quem não tem certeza de que vale manter o app pode aproveitar a migração para fazer a pergunta. Um protótipo que ninguém usa não precisa ser carregado para a ferramenta nova. Basta guardar o zip e deixá-lo encerrar junto com o ambiente.
O que o fim do Firebase Studio ensina sobre criar app com IA?
O Firebase Studio não é um caso isolado. Em 2026, o Google também começou a encerrar outro produto para desenvolvedores, como mostramos no guia sobre o prazo para migrar do Gemini Code Assist. Ferramentas em Preview, gratuitas e muito rápidas de adotar são também as mais fáceis de descontinuar.
A lição prática não é evitar essas ferramentas, e sim adotar cada uma já sabendo como sair dela. É a tese que defendemos no guia sobre as saídas que ninguém desenha no low code: antes do primeiro prompt, a empresa precisa saber onde fica o código, em nome de quem está a conta e o que acontece com o endereço do app se a plataforma mudar. No caso do FlutterFlow e o código que a empresa leva, essa porta depende do plano contratado.
O Firebase Studio, nesse ponto, foi generoso: deu um ano de aviso, ferramenta de migração e caminho para manter a URL. A maioria das empresas que vai perder alguma coisa em março de 2027 vai perder por desatenção, não por falta de saída.
Por onde começar hoje
Comece pelo inventário e pelo backup, que não dependem de nenhuma decisão técnica: liste os workspaces, confirme quem é o criador de cada um e baixe o zip e o histórico do agente de todos. Isso já tira o risco de perder o trabalho na data do desligamento.
Depois, escolha o destino app por app, com a URL como critério de desempate. Se a empresa não tem equipe técnica para conduzir a passagem, ou quer aproveitar a mudança para redesenhar o app numa plataforma com saída clara, a Alliance pode ajudar pelo serviço de desenvolvimento low-code e no-code. E se a dúvida é maior do que um app, o diagnóstico de marketing gratuito mostra em que ponto a tecnologia da empresa está pesando no resultado.