Google Cloud Run låter dig köra containers utan att hantera Kubernetes eller servrar. Denna guide täcker arkitektur, containerkrav, skalning, concurrency, traffic splitting, domäner, VPC-anslutning, prissättning och jämförelse med Cloud Functions och GKE.
Google Cloud Run är en serverless compute-plattform som kör dina containers direkt från container-registryt – utan att du behöver orkestrera Kubernetes eller hantera EC2-instanser. Sedan lanseringen 2019 har Cloud Run blivit en av de mest populära serverless-plattformarna för containers, särskilt för API:er, webbapplikationer och mikrotjänster.
Den här guiden ger dig en komplett genomgång av Google Cloud Run. Jag har använt Cloud Run för flera produktionsapplikationer och delar här vad som fungerar, vad som är begränsningar, och hur du jämför med alternativ som Cloud Functions och GKE.
Cloud Run – arkitektur och koncept
Cloud Run bygger på Knative, en open source-plattform som bygger på Kubernetes men abstraherar bort komplexiteten. Du bygger en containerimage (enligt Cloud Run-kraven), pushar till Artifact Registry eller Docker Hub, och Cloud Run kör den som en serverless tjänst. Cloud Run ansvarar för att starta, skala och stoppa containers baserat på HTTP-trafik.
Cloud Run kan köras i två lägen: Fully managed (Google hanterar all infrastruktur) och Cloud Run for Anthos (körs på ditt GKE-kluster). Fully managed är det vanligaste och rekommenderas för de flesta användningsfall – du betalar bara för resurser som används. Cloud Run for Anthos är för organisationer som redan har GKE och vill ha en enhetlig serverless-upplevelse.
Varje Cloud Run-tjänst har en HTTPS-endpoint och stöder all HTTP-trafik (GET, POST, PUT, DELETE, etc). Cloud Run stöder också gRPC, WebSockets och HTTP/2 – alla relevanta protokoll för moderna applikationer. Tjänsten kan nås via en auto-genererad URL (`https://
Krav på containerimages
Cloud Run ställer specifika krav på din containercontainer: den måste lyssna på en port (miljövariabeln `PORT`, vanligtvis 8080), starta snabbt (Cloud Run väntar max 4 minuter för start, men för auto-scaling bör containern starta på under 10 sekunder), och vara stateless (all state måste lagras externt i Cloud SQL, Firestore, eller annan lagring).
Containern ska vara så liten som möjligt. Använd distroless-basimages (Google-distroless, Alpine) eller minimala images. Cloud Run har en maxgräns på 32 GB minne och 4 vCPU (2026), men containers över 1 GB startar långsammare. Varje request får bearbetas i max 60 minuter (timeout) – längre tid för asynkron bearbetning, kortare för webbapplikationer.
Undvik att lagra data i containerns filsystem – det är temporärt och försvinner när containern stoppas. Använd Cloud Storage för filer, Cloud SQL för databaser, och Memorystore för caching. Cloud Run-montering av Cloud Storage FUSE (gcsfuse) är möjligt men inte rekommenderat för produktionskritiska system på grund av prestanda och konsistens.
Auto-scaling och concurrency
Cloud Run skalar automatiskt från 0 till tusentals instanser baserat på inkommande HTTP-trafik. Detta är en av de största fördelarna – du betalar inte för inaktiv kapacitet. Du kan konfigurera: min-instanser (min 0, betalar endast för beräkning när de används, men inga cold starts), max-instanser (standard 100, skyddar mot oväntade trafiktoppar eller DDOS).
Concurrency är en annan kraftfull funktion – en Cloud Run-instans kan hantera flera samtidiga requests per container. Standard concurrency är 80, men du kan ställa in 1 (för känsliga eller tunga arbetsbelastningar) upp till 250 (för lätta HTTP-api:er). Konfigurera concurrency baserat på din applikations resursanvändning – för Node.js och Go med async I/O är 80–250 lämpligt, för CPU-tunga eller minneskrävande processer är 1–10 lämpligt.
Cold starts är Cloud Runs största utmaning. När en tjänst skalar från 0 måste en ny container startas. Cold start-tiden varierar från 200 ms (Go, minimal container) till 5 sekunder (Java, Spring Boot). Använd min-instanser (min=1) för latenskänsliga produktionstjänster, och optimera containerstorleken för snabb start. Cloud Run har också "startup CPU boost" (2014–) som ger extra CPU under start för att minska cold starts.
Traffic splitting och anpassade domäner
Cloud Run har inbyggt stöd för traffic splitting mellan revisioner. En revision är en ögonblicksbild av din tjänst vid en deployment. Du kan distribuera trafik mellan revisioner i procent – användbart för canary deployments (skicka 10% trafik till ny revision, 90% till gammal), A/B-testning, eller blue/green-deployment.
Anpassade domäner kräver att du verifierar domänägarskap via Google Search Console och lägger till en DNS-post (CNAME eller A). Cloud Run genererar ett SSL-certifikat automatiskt via Let's Encrypt eller Google-managed certifikat. Du kan också använda Google Cloud Load Balancer framför Cloud Run för avancerad routing, SSL-policy och DDOS-skydd.
Traffic splitting och domäner gör Cloud Run lämpligt för produktionsapplikationer med krav på deployment-strategier och egen domän. Du kan också använda Cloud Run-taggar för att skapa staging/development-miljöer med egna URL:er som inte tar emot produktionstrafik.
VPC-anslutning och nätverk
Cloud Run-körningar kan anslutas till ditt VPC via Serverless VPC Access eller Direct VPC. Serverless VPC Access skapar en bro mellan Cloud Run och ditt VPC så att containers kan nå internt resurser som Compute Engine, Cloud SQL, Memorystore och interna API:er – utan att gå över internet.
Direct VPC (lanserad 2024) är en mer direkt integrering där Cloud Run-körningar får interna IP-adresser i ditt VPC. Detta är snabbare (lägre latens) och enklare (ingen extra connector att hantera) än Serverless VPC Access. För de flesta nya applikationer rekommenderas Direct VPC.
Cloud Run-stöd för VPC-anslutning innebär att du kan köra backend-applikationer som kräver åtkomst till interna resurser – databaser i Cloud SQL, cache i Memorystore, och privata API:er. Utan VPC-anslutning har Cloud Run endast internetåtkomst (och GCP-tjänster via offentliga endpoints).
Cloud Run vs Cloud Functions vs GKE
Cloud Functions är GCP:s FaaS (Functions-as-a-Service) för enkla, händelsestyrda funktioner. Cloud Functions är bäst för enkla triggers (filuppladdning, pub/sub-meddelanden, HTTP-trigger) med kort exekveringstid (max 9 minuter 2026). Cloud Run är bättre för hela applikationer och API:er med komplex routing, WebSockets och långkörande processer.
GKE (Google Kubernetes Engine) är för team som behöver full kontroll över Kubernetes-orkestrering. GKE är rätt val om du har Kubernetes-specifik kompetens, behöver GPU-stöd, StatefulSets, eller avancerade nätverkskonfigurationer. GKE är generellt dyrare och mer komplext än Cloud Run.
Cloud Run är bäst för: webbapplikationer och API:er, mikrotjänster, batch-jobb med HTTP-trigger, och när du vill ha serverless-containrar utan Kubernetes-komplexitet. Många organisationer använder en hybrid-strategi: Cloud Run för API:er och webbtjänster, GKE för komplexa batch-jobb och stateful arbetsbelastningar.
Prissättning och kostnadsoptimering
Cloud Run prissättning är enkel: du betalar per request, per CPU-tid och per minne under request-bearbetning. Den första 2 miljoner requests per månad är gratis. Därefter: 0,08 USD per miljon requests, 0,0240 USD per vCPU-timme och 0,0025 USD per GB-timme. Minsta debitering är 100 ms per request.
Cost management: använd budgetvarningar i GCP Billing, konfigurera max-instanser för att undvika oväntade kostnadstoppar, och övervaka CPU/minne-användning per request. En instans som körs 24/7 med 1 vCPU och 2 GB minne kostar ca 0,63 USD/dag (19 USD/månad) exklusive requests.
Cloud Run är ofta billigare än App Engine och Cloud Functions för applikationer med högre trafikvolymer eftersom container-modellen är mer resurseffektiv. För lågvolym-applikationer (<100k requests/månad) är Cloud Functions billigast. För medelhög trafik (1–10M requests/månad) är Cloud Run mest kostnadseffektivt.
Övervakning och logging
Cloud Run integreras sömlöst med Google Cloud's observability-plattform: Cloud Monitoring (metrics), Cloud Logging (loggar), och Cloud Trace (distribuerad tracing). Varje Cloud Run-tjänst får automatiskt grundläggande metrics: request count, latency, error rate, CPU användning, minnesanvändning, och container instance count.
Använd Cloud Logging för att se container-loggar. Logga i JSON-format med strukturerade fält för effektiv sökning och filtrering. Cloud Logging stöder log-baserade metrics – skapa anpassade metrics baserat på specifika loggmönster (t.ex. "antal 500-fel").
Cloud Trace ger distribuerad tracing genom din applikation. Integrera Cloud Trace SDK i din applikation (stöd för Java, Python, Go, Node.js, .NET, Ruby, PHP). Tracing är ovärderligt för att identifiera flaskhalsar – särskilt i mikrotjänstarkitekturer där en request kan gå genom flera API:er och databaser.
Cloud Run i produktion – bästa praxis
- Använd minsta möjliga containerimage – Go, Node.js (Alpine), eller Python (slim) för snabbast cold starts.
- Konfigurera concurrency baserat på din applikations resursbehov – starta med 80, övervaka och justera.
- Använd min-instanser (min=1) för latenskänsliga produktionstjänster – eliminerar cold starts för baslinjetrafik.
- Använd traffic splitting för canary deployments och A/B-testning.
- Använd Direct VPC eller Serverless VPC Access för åtkomst till interna resurser.
- Använd Cloud SQL via Unix-socket (Cloud SQL Auth Proxy) för databasanslutning – säkrare och snabbare än TCP.
- Använd Cloud Monitoring-alerting för request latency, error rate och CPU/minne-användning.
- Använd Cloud Build + Cloud Deploy för CI/CD – bygg container, push till Artifact Registry, deploy till Cloud Run.
- Använd Cloud Armor för DDOS-skydd och WAF-regler om du exponerar tjänster direkt mot internet.
- Använd Cloud Scheduler för schemalagda jobb som triggar Cloud Run via HTTP.
Sammanfattning: Cloud Run 2026
Google Cloud Run är en mogen och kraftfull serverless-containerplattform som passar perfekt för API:er, webbapplikationer och mikrotjänster. Det bästa med Cloud Run är kombinationen av serverless-skalning (0 till tusentals) och containerflexibilitet – du kan använda vilket språk, bibliotek eller verktyg som helst som får plats i en container.
Cloud Runs främsta begränsning är cold starts och en max-exekveringstid på 60 minuter. För de flesta webbapplikationer är cold starts hanterbara med min-instanser och optimerade containers. För batch-jobb och tunga processer över 60 minuter behöver du GKE eller Cloud Batch.
Vill du ha hjälp med Google Cloud Run?
Jag hjälper företag att migrera till och optimera Cloud Run-applikationer. Läs mer om moln- och infratjänster eller boka ett samtal.
“Cloud Run kombinerar serverless-skalning med containerflexibilitet – du får det bästa från två världar utan Kubernetes-komplexiteten.”
- Simon Axelsson
Vanliga frågor
- Vad är skillnaden mellan Cloud Run och Cloud Functions?
- Cloud Run är serverless-containrar som kör hela applikationer och API:er med full HTTP-support (gRPC, WebSockets, valfritt språk). Cloud Functions är FaaS för enkla, händelsestyrda funktioner med max 9 minuters exekveringstid och begränsad HTTP-routing. Cloud Run ger mer kontroll och flexibilitet.
- Hur hanterar jag cold starts i Cloud Run?
- Använd min-instanser (min=1) för att hålla minst en container varm. Optimera containerstorleken (distroless, Alpine, under 500 MB). Använd startup CPU boost (kräver att tjänsten är konfigurerad för CPU alltid på). Välj språk med snabb starttid (Go, Node.js, Python före Java, .NET).
- Kan jag köra WebSockets och gRPC på Cloud Run?
- Ja, Cloud Run stöder både WebSockets och gRPC. WebSockets kräver att concurrency är 1 (en request per container åt gången) eftersom WebSocket-anslutningar är långlivade. gRPC kräver HTTP/2-aktivering och att din klient stöder TLS. Båda funktionerna är produktionsklara.
- Vad kostar Cloud Run per månad för en typisk API-tjänst?
- För en API-tjänst med 5M requests/månad, 500 ms genomsnittlig bearbetningstid, 1 vCPU, 2 GB: ca 30–50 USD/månad. För en lågvolymstjänst (<100k requests): ca 5–10 USD/månad (ofta inom gratisnivån). Tillkommer kostnader för Cloud SQL, Artifact Registry och dataöverföring.
- Kan jag migrera en befintlig containerapp till Cloud Run?
- Ja, om containern är stateless, lyssnar på PORT-miljövariabeln, och startar inom 4 minuter. Du pushar imagen till Artifact Registry och skapar en Cloud Run-tjänst med ett klick eller kommando (`gcloud run deploy`). För applikationer som behöver VPC-anslutning konfigurerar du Direct VPC eller Serverless VPC Access.
Om författaren
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar av Simon