Har du en arbetsyta i Firebase Studio ska du flytta den före 22 mars 2027. Google uppger att kvarvarande data i arbetsytan då raderas permanent. En app som redan är publicerad på Firebase fortsätter däremot att köras, och tjänster som Firestore, Authentication och App Hosting påverkas inte av att utvecklingsmiljön stängs.
Tre datum som styr vad du kan göra
Det här slutar — och det här fortsätter
Utvecklingsmiljön försvinner
Firebase Studio är platsen där du öppnar arbetsytan, ber agenten ändra appen och publicerar nya versioner. Det är den miljön du måste lämna.
Den publicerade appen stängs inte automatiskt
Google säger att appar som redan är publicerade på Firebase fortsätter att köras. Databas, inloggning och App Hosting fortsätter också som egna Firebase-tjänster.
Prov: skilj appen från arbetsytan
Öppna appens publika adress i ett privat webbläsarfönster. Prova dess viktigaste flöde och kontrollera sedan att testuppgiften sparades. Då vet du att den publicerade appen fungerar oberoende av att du har Firebase Studio öppet.
Så flyttar du utan att chansa
För den som vill fortsätta bygga genom att beskriva appen i webbläsaren är Google AI Studio den närmaste vägen. Google beskriver Antigravity som alternativet för ett mer kodstyrt arbetsflöde. Eftersom Perestrojka inte förutsätter att du skriver kod utgår stegen här från AI Studio.
Publicerade du appen till App Hosting från Firebase Studio hämtade miljön automatiskt din Gemini-nyckel ur arbetsytans .env-fil och lade den som en miljövariabel hos App Hosting, läsbar för appen men inte för besökarna. Den automatiken följer inte med flytten.
Ska du fortsätta publicera till samma adress via GitHub måste du enligt Googles guide sätta miljövariabeln för hand i Firebase-konsolen. Anledningen är att .env-filen inte ska till GitHub — där ligger nyckeln öppet. Google påpekar samtidigt att en variabel i konsolen lagras säkert men är läsbar för alla som har åtkomst till Firebase-projektet, och hänvisar till Secret Manager när fler har åtkomst än de som ska se nyckeln.
Prov: sök igenom det du lagt i GitHub efter .env och efter strängar som börjar med AIza. Hittar du något är nyckeln röjd — byt den innan du gör något annat. Guide 7 går igenom vad som gäller för nycklar i övrigt.
Be modellen göra en kontroll före ändringar
När appen öppnas i den nya miljön är det frestande att genast be om nästa funktion. Börja i stället med en inventering som inte får ändra något.
Granska den importerade appen utan att ändra några filer. Beskriv: 1) vilka delar som startar, 2) vilka externa tjänster appen använder, 3) vilka miljövariabler eller hemligheter som verkar krävas, 4) hur data och inloggning är kopplade, och 5) vad jag måste prova manuellt före nästa publicering. Markera tydligt sådant du inte kan verifiera. Vänta på mitt godkännande innan du gör någon ändring.
Prov: svaret ska sluta i en konkret lista över manuella kontroller, inte i påståendet att allt ser bra ut. Genomför sedan varje kontroll själv. Modellen kan läsa filer men kan inte avgöra att din riktiga inloggning, databas eller domän fungerar för en besökare.
Vad det här säger om verktygsval
En nedstängning med ett års varsel är ovanligt hyfsat hanterad. Ändå är det här precis den situation som gör att guide 8 ber dig äga adressen själv, exportera en gång i månaden och hålla projektbeskrivningen i en fil utanför verktyget. Ingen av de tre vanorna hade hindrat stängningen — men var och en gör den till en teknisk detalj i stället för en kris.
Notera vad som faktiskt räddade de publicerade apparna: de låg på tjänster som är skilda från utvecklingsmiljön. Det är samma gränsdragning som guide 5 förespråkar av helt andra skäl — att data och inloggning ska ligga i något du inte byggt själv. Här visade det sig också vara det som gjorde apparna oberoende av vilket fönster de en gång skrevs i.