Instancje Google Cloud Run dla długotrwałych agentów AI
28 sierpnia 2026 roku Google ogłosił wersję preview usługi Cloud Run instances. To nowy runtime dla workloadów, które potrzebują jednego stale dostępnego kontenera zamiast autoskalowania sterowanego requestami. Google kieruje go przede wszystkim do osobistych agentów AI, ale ten model działania pasuje również do lekkich botów, narzędzi deweloperskich i małych usług utrzymujących aktywny proces.
Nazwa ma znaczenie. Nie jest to kolejna opcja skalowania usługi Cloud Run. Instancja Cloud Run jest dedykowanym runtime’em typu singleton: uruchamia dokładnie jedną instancję i nie skaluje się automatycznie.
Co oferują instancje Cloud Run
Według Google każda instancja ma cztery najważniejsze właściwości:
- dokładnie jedną działającą instancję bez autoskalowania;
- do siedmiu dni ciągłego działania;
- automatyczny restart, domyślnie włączony;
- stabilny adres HTTPS, który nie zmienia się po aktualizacjach ani restartach.
Operator może również zatrzymać niepotrzebną instancję i później ją wznowić. Częściowo wypełnia to lukę między tradycyjną maszyną wirtualną a usługą Cloud Run zorientowaną na requesty. Platforma zapewnia runtime kontenera i endpoint HTTPS, a aplikacja otrzymuje stale działający proces o przewidywalnej liczbie instancji.
Usługi Cloud Run nadal lepiej nadają się do bezstanowych aplikacji HTTP, które powinny dodawać instancje przy rosnącym obciążeniu lub skalować się do zera w czasie bezczynności. Instancje Cloud Run są przeznaczone dla workloadów, w których skalowanie do zera zatrzymałoby pracę w tle, a skalowanie w poziomie utworzyłoby niepożądane kopie workerów.
Dlaczego pojedyncza instancja ma znaczenie dla agentów
Osobisty agent często obsługuje ruch inny niż typowe web API. Przez większość czasu może czekać, a następnie wykonać serię zadań po odebraniu wiadomości. Może też utrzymywać scheduler, odpytywać kolejkę lub utrzymywać połączenie wychodzące, obsługując tylko jednego użytkownika.
Uruchomienie wielu kopii może być wręcz szkodliwe, jeśli każda z nich odbierze to samo zdarzenie lub wykona to samo zaplanowane zadanie. Runtime typu singleton eliminuje autoskalowanie jako źródło duplikacji. Nie zastępuje jednak zabezpieczeń na poziomie aplikacji. Zdarzenia zewnętrzne nadal mogą zostać dostarczone więcej niż raz, a proces może się zrestartować, dlatego operacje wywołujące skutki uboczne powinny pozostać idempotentne.
Limit siedmiu dni ciągłego działania oznacza również, że pamięci lokalnego procesu nie można traktować jako trwałego stanu. Nawet przy włączonym automatycznym restarcie aplikacja powinna umieć odtworzyć swój stan po uruchomieniu.
Trwałe dane wymagają zewnętrznego storage
W ogłoszeniu Google pokazano deployment OpenClaw z bucketem Cloud Storage zamontowanym pod /home/node/.openclaw. Ten szczegół jest ważniejszy niż wybór konkretnego agenta: lokalny stan kontenera nie powinien być jedyną kopią konfiguracji, danych uwierzytelniających, historii rozmów ani checkpointów zadań.
Praktyczna architektura rozdziela trzy rodzaje stanu:
- Sekrety należy przechowywać w zmiennych środowiskowych zasilanych przez odpowiedni system zarządzania sekretami, a nie w obrazie kontenera.
- Trwałe pliki i checkpointy należy umieścić w zewnętrznym storage.
- Cache, otwarte połączenia i kolejki w pamięci należy traktować jako tymczasowe i odtwarzać je po restarcie.
Polecenie pokazane przez Google korzysta z interfejsu beta CLI i łączy publiczny endpoint, mount Cloud Storage oraz zmienne środowiskowe:
gcloud beta run instances create openclaw-instance \
--image ghcr.io/openclaw/openclaw:latest \
--port 18789 \
--public \
--add-volume mount-path=/home/node/.openclaw,type=cloud-storage,mount-options="uid=1000;gid=1000;file-mode=0700;dir-mode=0700",bucket=${BUCKET} \
--set-env-vars "OPENCLAW_GATEWAY_PASSWORD=${PASSWORD},GEMINI_API_KEY=${GEMINI_API_KEY}"To przykład z ogłoszenia, a nie szablon produkcyjny. Trzeba w szczególności zdecydować, czy endpoint powinien być publiczny, przypiąć i przeskanować obraz kontenera, ograniczyć uprawnienia tożsamości runtime’u oraz nie ujawniać sekretów w historii powłoki ani logach deploymentu.
Model cenowy
Według Google instancja z 1 współdzielonym vCPU i 1 GiB pamięci kosztuje 5,70 USD za 30 dni ciągłego działania. Runtime korzysta ze współdzielonych zasobów vCPU i budżetów krótkotrwałego zwiększania wydajności, co odpowiada agentowi, który zwykle czeka, a tylko czasami potrzebuje większej mocy obliczeniowej.
Tej kwoty nie należy mylić z całkowitym rachunkiem za aplikację. Inferencja modeli, storage, transfer sieciowy, logowanie i wszystkie inne usługi chmurowe są rozliczane osobno. Worker stale intensywnie wykorzystujący CPU może też nie pasować do produktu ze współdzielonym vCPU, zaprojektowanego z myślą o okresowych skokach obciążenia.
Zatrzymywanie i wznawianie przydaje się, gdy agent jest potrzebny tylko w godzinach pracy albo na czas krótkiego projektu. Pozwala to ograniczyć koszty runtime’u bez dostosowywania workloadu do sterowanego requestami skalowania do zera.
Ograniczenia operacyjne, które trzeba uwzględnić
Cloud Run instances są w fazie preview, dlatego wymagają ostrożniejszej oceny niż runtime dostępny w wersji ogólnej. Ogłoszenie informuje również, że dostęp SSH pojawi się wkrótce i wymaga osobnej rejestracji dostępu prywatnego. Nie przedstawiono go jako funkcji dostępnej w obecnej wersji preview.
Przed wyborem usługi należy sprawdzić, czy workload toleruje:
- jedną instancję zamiast skalowania poziomego lub wbudowanej redundancji;
- restarty procesu i maksymalnie siedem dni ciągłego działania;
- wydajność współdzielonego vCPU z budżetami krótkotrwałego przyspieszenia;
- przechowywanie trwałego stanu poza instancją;
- interfejsy i zachowanie operacyjne usługi w fazie preview.
Singleton nie oznacza wysokiej dostępności. Automatyczny restart może przywrócić proces po awarii, ale nadal istnieje tylko jeden runtime. Workloady z rygorystycznymi wymaganiami dostępności potrzebują architektury uwzględniającej czas restartu albo powinny pozostać na platformie obsługującej wiele replik.
Gdzie pasuje nowy runtime
Instancje Cloud Run są najbardziej interesujące, gdy spełnione są wszystkie poniższe warunki:
- aplikacja jest już spakowana jako kontener;
- powinna działać dokładnie jedna kopia;
- proces musi pozostać aktywny bez przychodzących requestów HTTP;
- zapotrzebowanie na CPU jest okresowe;
- trwały stan może znajdować się poza procesem;
- zarządzany endpoint HTTPS jest przydatny.
Gorzej sprawdzą się w przypadku API obsługujących duży ruch, konsumentów skalowanych poziomo, zadań batch intensywnie wykorzystujących CPU oraz systemów, które nie mogą zaakceptować okresowych restartów. Dla takich workloadów usługi Cloud Run, platformy batchowe lub maszyny wirtualne nadal oferują bardziej przejrzysty model działania.
Istotną zmianą nie jest tylko to, że Cloud Run może pozostać aktywny. Google oferuje teraz jawny mechanizm singletona ze stabilnym adresem URL oraz cyklem życia obejmującym zatrzymywanie i wznawianie. Daje to małym, długotrwałym agentom zarządzaną opcję między autoskalowaną usługą a samodzielnie administrowaną maszyną wirtualną, pod warunkiem że zespoły zaprojektują aplikację z myślą o restartach i uwzględnią ograniczenia wersji preview.