Google Cloud Run Tutorial: Deploy i 12 Steg [2026]

Google Cloud Run fylte seks år i 2025, men 2026 har vært det travleste året for tjenesten så langt. På Google Cloud Next i april kom en ny generasjon funksjoner, blant annet støtte for GPU-arbeidslaster og noe Google kaller Cloud Run Instances. For norske og nordiske utviklere som vil unngå å drifte egne servere, men som heller ikke trenger full Kubernetes-kompleksitet, er Cloud Run fortsatt et av de raskeste veiene fra kode til produksjon. Denne guiden tar deg gjennom hele prosessen: fra et tomt Google Cloud-prosjekt til en containerisert applikasjon som kjører i europe-north1 i Finland, med egen HTTPS-adresse, hemmeligheter håndtert riktig og kostnadskontroll fra dag én.

Du trenger ingen tidligere erfaring med Google Cloud for å følge denne guiden, men du bør kunne litt Docker og terminalkommandoer. Alt kodeeksempel er testet mot gcloud CLI versjon 580.0.0, som var den nyeste versjonen tilgjengelig i august 2026.

Hva er Google Cloud Run, og hvorfor er det relevant i 2026?

Cloud Run er Googles administrerte plattform for containeriserte arbeidslaster. Du bygger en container, pusher den til et registry, og Google tar seg av resten: nettverk, TLS-sertifikater, lastbalansering og autoskalering ned til null instanser når ingen bruker tjenesten. Det gjør Cloud Run til et mellomting mellom Cloud Functions, som kun kjører enkeltfunksjoner, og full Kubernetes, hvor du selv styrer klyngen.

På Google Cloud Next i april 2026 annonserte Google flere utvidelser som gjør plattformen mer relevant for AI-arbeidslaster og bakgrunnsjobber, ikke bare korte HTTP-kall. Den viktigste nyheten var Cloud Run Instances, en ny type ressurs som gir deg individuelt adresserbare, langvarige instanser i stedet for kun stateløse tjenester som skaleres av HTTP-trafikk. Samtidig ble støtte for NVIDIA RTX PRO 6000 Blackwell-GPUer gjort allment tilgjengelig, slik at du kan kjøre inferens for modeller med over 70 milliarder parametere uten å administrere egen GPU-infrastruktur, og fortsatt skalere til null når ressursen ikke er i bruk. Kilde: Google Cloud-bloggen om nyheter på Next ’26.

For de fleste team er likevel den klassiske bruken fortsatt mest aktuell: en containerisert REST-API, et bakgrunnsjobb-system eller en intern mikrotjeneste som skal nås over HTTPS uten at noen manuelt patcher servere klokka to om natten.

Det som gjør Cloud Run spesielt attraktivt for mindre norske team, er at du slipper å velge mellom «for enkelt» og «for komplisert». Cloud Functions tvinger deg til å skrive kode som passer inn i en enkeltfunksjonsmodell, noe som blir upraktisk så snart applikasjonen vokser forbi noen få hundre linjer. GKE, selv i Autopilot-modus, krever at du forstår konsepter som Deployments, Services og Ingress-kontrollere før du i det hele tatt har fått ut din første HTTP-respons. Cloud Run lar deg ta med deg en helt vanlig containerisert applikasjon, uansett språk eller rammeverk, og få den i produksjon uten å lære et helt nytt orkestreringslag først.

Cloud Run sammenlignet med Cloud Functions og GKE Autopilot

Google har tre hovedveier inn i skyen for kode du ikke vil drifte selv. Valget mellom dem handler i praksis om hvor mye kontroll du trenger, og hvor komplekst arbeidslasten din er. Cloud Functions passer for korte, hendelsesdrevne funksjoner. Cloud Run passer for de fleste containeriserte applikasjoner og mikrotjenester. GKE Autopilot passer når du trenger Kubernetes-spesifikke funksjoner som egne kontrollere eller avansert nettverkspolicy.

Egenskap	Cloud Functions	Cloud Run	GKE Autopilot
Kjøretidsenhet	Enkeltfunksjon	Container (hvilket som helst språk)	Pod i Kubernetes-klynge
Skalering til null	Ja	Ja (standard)	Nei, krever noder
Maks. request-timeout	9 minutter	Opptil 60 minutter	Ingen fast grense
Kontrollnivå	Lavt	Middels	Høyt
Egnet for GPU-inferens	Nei	Ja, siden Next ’26	Ja
Driftskompleksitet	Svært lav	Lav	Middels til høy

Denne guiden fokuserer på Cloud Run fordi det treffer den brede midten: du får containerfleksibilitet uten å måtte administrere en klynge. Vurderer du GKE i tillegg, kan du sammenligne med hvordan vi satte opp Kubernetes 1.36 og EKS-støtte i en tidligere gjennomgang.

En tommelfingerregel mange team i Norden bruker: start alltid med Cloud Run. Merker du etter hvert at du trenger funksjoner Cloud Run ikke tilbyr, som DaemonSets, egendefinerte nettverkspolicyer eller finkornet kontroll over planlegging av poder på spesifikk maskinvare, er det da du migrerer til GKE. Å starte med full Kubernetes «for sikkerhets skyld» fører ofte til at team bruker uker på klyngekonfigurasjon før de i det hele tatt har fått ut den første funksjonaliteten til brukerne.

Forutsetninger og versjonskrav

Før du starter trenger du følgende på plass. Ingen av delene koster noe å opprette, men Cloud Run krever at prosjektet har en fakturakonto koblet til, selv om du holder deg innenfor gratisnivået.

En Google Cloud-konto med et betalingsprofil koblet til (kredittkort kreves for verifisering, men du blir ikke belastet før du overstiger gratisnivået)
gcloud CLI versjon 580.0.0 eller nyere (dette er den nyeste versjonen per august 2026, ifølge Googles offisielle SDK-dokumentasjon)
Docker Engine eller Docker Desktop, versjon 24 eller nyere, for lokal bygging og testing
Node.js 22 LTS installert lokalt, kun for utvikling (selve produksjonskoden kjører inne i containeren)
Grunnleggende kjennskap til terminal, miljøvariabler og HTTP
Et tekstredigeringsprogram, for eksempel VS Code

Sjekk at du har riktig CLI-versjon før du går videre:

gcloud version
# Forventet: Google Cloud SDK 580.0.0 (eller nyere)

docker --version
# Forventet: Docker version 24.x eller nyere

Steg 1: Opprett et Google Cloud-prosjekt og aktiver fakturering

Alt i Google Cloud lever inne i et prosjekt. Opprett et nytt prosjekt dedikert til denne guiden, slik at du enkelt kan slette alt igjen etterpå uten å påvirke andre ressurser.

gcloud projects create mitt-cloud-run-prosjekt --name="Cloud Run Demo"
gcloud config set project mitt-cloud-run-prosjekt

# List tilgjengelige fakturakontoer
gcloud billing accounts list

# Koble fakturakontoen til prosjektet
gcloud billing projects link mitt-cloud-run-prosjekt \
  --billing-account=XXXXXX-XXXXXX-XXXXXX

Bytt ut prosjektnavnet med noe unikt globalt (prosjekt-ID-er kan ikke gjenbrukes selv etter sletting), og erstatt fakturakonto-IDen med din egen fra listen over.

Steg 2: Installer og oppdater gcloud CLI

Har du allerede gcloud installert, hold den oppdatert, siden nye Cloud Run-funksjoner ofte krever siste versjon av CLI-verktøyet. Sett også standard region til Finland for lavest mulig ventetid fra Norge og resten av Norden.

gcloud components update
gcloud auth login
gcloud config set project mitt-cloud-run-prosjekt
gcloud config set run/region europe-north1
gcloud config set compute/region europe-north1

europe-north1 ligger i Hamina i Finland og er den nærmeste Google Cloud-regionen for brukere i Norge, Sverige, Danmark og Finland. Trenger du redundans i tillegg, kan europe-west1 (Belgia) eller europe-west4 (Nederland) fungere som sekundærregion.

Steg 3: Aktiver nødvendige API-er

Google Cloud krever at du eksplisitt aktiverer hvert API du skal bruke. For denne guiden trenger du fire: Cloud Run, Artifact Registry, Cloud Build og Secret Manager.

gcloud services enable \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  secretmanager.googleapis.com

Kommandoen tar typisk 30 til 60 sekunder å fullføre. Kjører du den på nytt senere, er den trygg å gjenta, siden allerede aktiverte API-er bare hoppes over.

Steg 4: Bygg en enkel Node.js-applikasjon

Cloud Run stiller ett krav til applikasjonen din: den må lytte på porten som gis via miljøvariabelen PORT, som Cloud Run setter til 8080 som standard. Opprett en ny mappe og legg til følgende filer.

// index.js
const express = require('express');
const app = express();
const port = process.env.PORT || 8080;

app.get('/', (req, res) => {
  res.send('Hei fra Cloud Run! Region: ' + (process.env.REGION || 'ukjent'));
});

app.get('/helse', (req, res) => {
  res.status(200).json({ status: 'ok', tidspunkt: new Date().toISOString() });
});

app.listen(port, () => {
  console.log('Server lytter på port ' + port);
});

{
  "name": "cloud-run-demo",
  "version": "1.0.0",
  "main": "index.js",
  "engines": { "node": ">=22" },
  "scripts": { "start": "node index.js" },
  "dependencies": { "express": "^4.19.2" }
}

Kjør npm install lokalt for å generere package-lock.json, som Docker-bygget senere er avhengig av for reproduserbare installasjoner.

Steg 5: Skriv en produksjonsklar Dockerfile

Bruk et slankt basisimage for å holde både byggetid og cold start-tid nede. node:22-slim er et godt kompromiss mellom størrelse og kompatibilitet med native npm-pakker.

FROM node:22-slim

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

ENV NODE_ENV=production
EXPOSE 8080

USER node
CMD ["node", "index.js"]

Legg merke til USER node på nest siste linje. Det offisielle Node.js-imaget har en innebygd, ikke-root-bruker kalt node, og å bruke den reduserer angrepsflaten betraktelig sammenlignet med å kjøre containeren som root. Legg også til en .dockerignore-fil med node_modules og .git for å unngå at unødvendige filer havner i imaget.

Steg 6: Test containeren lokalt med Docker

Test alltid containeren lokalt før du pusher den til skyen. Det sparer deg for mange runder med treg feilsøking i Cloud Run-logger.

docker build -t cloud-run-demo .
docker run -p 8080:8080 -e PORT=8080 cloud-run-demo

Åpne en ny terminal og test endepunktet:

curl http://localhost:8080

# Forventet output:
# Hei fra Cloud Run! Region: ukjent

curl http://localhost:8080/helse

# Forventet output:
# {"status":"ok","tidspunkt":"2026-08-26T09:14:02.001Z"}

Fungerer begge endepunktene lokalt, er du klar til å publisere imaget til Google Cloud.

Steg 7: Opprett et Artifact Registry-repository

Artifact Registry er Googles administrerte registry for containerimages og har erstattet det eldre Container Registry. Opprett ett repository per prosjekt, eller ett per applikasjon om du har flere tjenester.

gcloud artifacts repositories create cloud-run-demo-repo \
  --repository-format=docker \
  --location=europe-north1 \
  --description="Docker-images for Cloud Run-demo"

Steg 8: Bygg og push image til Artifact Registry

Før du kan pushe, må Docker autentiseres mot registryet i riktig region. Kommandoen under skriver til din lokale Docker-konfigurasjon og trenger vanligvis kun å kjøres én gang per maskin.

gcloud auth configure-docker europe-north1-docker.pkg.dev

docker tag cloud-run-demo \
  europe-north1-docker.pkg.dev/mitt-cloud-run-prosjekt/cloud-run-demo-repo/cloud-run-demo:v1

docker push \
  europe-north1-docker.pkg.dev/mitt-cloud-run-prosjekt/cloud-run-demo-repo/cloud-run-demo:v1

Push-tiden avhenger av imagestørrelsen og internettforbindelsen din, men et slankt Node.js-image som dette pusher normalt på under et minutt.

Steg 9: Deploy applikasjonen til Cloud Run

Dette er selve hovedkommandoen. Den oppretter en ny Cloud Run-tjeneste, kobler den til imaget du nettopp pushet, og gjør den tilgjengelig på en offentlig HTTPS-adresse.

gcloud run deploy cloud-run-demo \
  --image=europe-north1-docker.pkg.dev/mitt-cloud-run-prosjekt/cloud-run-demo-repo/cloud-run-demo:v1 \
  --region=europe-north1 \
  --platform=managed \
  --allow-unauthenticated \
  --memory=512Mi \
  --cpu=1

Vent noen sekunder, og du får en URL tilbake i terminalen:

Deploying container to Cloud Run service [cloud-run-demo] in project [mitt-cloud-run-prosjekt] region [europe-north1]
✓ Deploying new service... Done.
✓ Creating Revision...
✓ Routing traffic...
✓ Setting IAM Policy...
Done.
Service URL: https://cloud-run-demo-abc123xyz-lz.a.run.app

Test den nye adressen med samme curl-kommandoer som i steg 6. Får du 200 OK og riktig svar, kjører applikasjonen din nå på ekte i Google Cloud, med automatisk HTTPS og lastbalansering inkludert uten ekstra konfigurasjon.

Steg 10: Konfigurer CPU, minne og samtidighet

Standardinnstillingene fungerer for en demo, men i produksjon bør du justere samtidighet og skaleringsgrenser bevisst. Cloud Run støtter to CPU-allokeringsmodeller: forespørselsbasert, hvor CPU kun er tilgjengelig mens en request behandles, og alltid-allokert, hvor CPU forblir tildelt selv i ro. Den første er billigst og passer HTTP-tjenester, den andre passer bakgrunnsjobber og WebSocket-tilkoblinger.

gcloud run services update cloud-run-demo \
  --region=europe-north1 \
  --concurrency=80 \
  --cpu-boost \
  --min-instances=0 \
  --max-instances=20

Standard samtidighet i Cloud Run er satt til 80 forespørsler per instans, men de fleste Node.js- og Python-applikasjoner håndterer langt mer parallell trafikk uten problemer. Å øke concurrency til for eksempel 80 reduserer antall instanser som må startes under trafikktopper, noe som både senker kostnaden og reduserer antall cold starts brukerne merker.

Flagget --cpu-boost gir containeren midlertidig mer CPU-kraft under selve oppstartsfasen, noe som er nyttig for applikasjoner med tunge oppstartsrutiner, som å laste en stor ML-modell inn i minnet eller bygge opp en tilkoblingspool mot en database. Uten boost deles CPU-en jevnt gjennom hele levetiden til instansen, inkludert oppstarten, noe som kan gjøre cold starts merkbart tregere enn nødvendig. Sett min-instances til minst 1 for tjenester der brukerne aldri bør oppleve en cold start i det hele tatt, som for eksempel en betalingsflyt eller et innloggingsendepunkt, mens du gjerne kan la bakgrunnstjenester og interne verktøy skalere helt ned til null når de ikke er i bruk.

Steg 11: Miljøvariabler og hemmeligheter med Secret Manager

Legg aldri API-nøkler eller passord rett i Dockerfilen eller kildekoden. Secret Manager lar deg lagre hemmeligheter separat og injisere dem som miljøvariabler kun ved kjøretid.

# Opprett en hemmelighet
echo -n "hemmelig-api-nokkel-123" | gcloud secrets create api-nokkel --data-file=-

# Gi Cloud Run-tjenestekontoen tilgang
gcloud secrets add-iam-policy-binding api-nokkel \
  --member="serviceAccount:[email protected]" \
  --role="roles/secretmanager.secretAccessor"

# Koble hemmeligheten til tjenesten som miljøvariabel
gcloud run services update cloud-run-demo \
  --region=europe-north1 \
  --set-secrets=API_KEY=api-nokkel:latest

Inne i applikasjonen leser du hemmeligheten på vanlig måte via process.env.API_KEY. Cloud Run henter alltid siste versjon av hemmeligheten når du refererer til :latest, men du kan også låse til et spesifikt versjonsnummer for full kontroll over når endringer tas i bruk.

For team med flere miljøer, som utvikling, test og produksjon, er det verdt å opprette separate hemmeligheter per miljø fra starten av, i stedet for å dele én hemmelighet på tvers. Et vanlig mønster er å navngi dem api-nokkel-dev, api-nokkel-test og api-nokkel-prod, og deretter la utrullingsskriptet velge riktig hemmelighet basert på hvilket miljø som deployes. Det hindrer at en utvikler ved et uhell tester mot produksjonsdata under lokal feilsøking, som er en av de mer kostbare feilene å gjøre i et team med delte ressurser.

Steg 12: Egendomene og automatisk HTTPS

Standard-URL-en fra Cloud Run fungerer fint til testing, men i produksjon vil du sannsynligvis bruke ditt eget domene. Domenetilordning i Cloud Run håndterer TLS-sertifikatet automatisk, uten at du trenger Let’s Encrypt eller andre verktøy selv.

gcloud run domain-mappings create \
  --service=cloud-run-demo \
  --domain=api.dittdomene.no \
  --region=europe-north1

Kommandoen returnerer DNS-poster (vanligvis en CNAME eller A/AAAA-post, avhengig av oppsettet ditt) som du må legge inn hos din DNS-leverandør. Etter at postene er verifisert, utsteder Google automatisk et sertifikat, noe som normalt tar fra noen minutter til rundt 24 timer avhengig av DNS-propagering.

Før du kan koble et domene til Cloud Run, må domenet være verifisert i Google Search Console under samme Google-konto som administrerer prosjektet. Har du allerede verifisert domenet fra tidligere prosjekter, som en eksisterende nettside eller e-posttjeneste, kan du gjenbruke verifiseringen direkte uten å gå gjennom prosessen på nytt. Mangler du verifisering, må du legge til en TXT-post hos DNS-leverandøren din før domenetilordningen kan opprettes.

Logging og overvåking med Cloud Logging

Alt en Cloud Run-container skriver til stdout eller stderr, havner automatisk i Cloud Logging uten at du trenger å installere noen egen logg-agent. Det er en av de store fordelene med en administrert plattform sammenlignet med å drifte egne virtuelle maskiner, hvor logghåndtering ofte blir et eget prosjekt i seg selv. For strukturerte logger, som er langt enklere å søke i og lage varsler ut fra, bør du likevel formatere loggene dine som JSON i stedet for ren tekst.

// Strukturert logging i index.js
function logJson(severity, message, ekstra = {}) {
  console.log(JSON.stringify({
    severity,
    message,
    ...ekstra,
  }));
}

app.get('/', (req, res) => {
  logJson('INFO', 'Mottok forespørsel', { sti: req.path, metode: req.method });
  res.send('Hei fra Cloud Run!');
});

Med dette formatet kan du filtrere direkte på feltet severity i Cloud Logging, og bygge varsler som trigger når antall ERROR-linjer overstiger en terskel over en gitt periode. Du kan også hente logger direkte fra terminalen, noe som er raskere enn å bla gjennom konsollet når du feilsøker en pågående hendelse.

gcloud run services logs read cloud-run-demo \
  --region=europe-north1 \
  --limit=50

For produksjonstjenester bør du i tillegg sette opp et varsel i Cloud Monitoring på metrikker som feilrate og responstid, slik at du blir varslet før brukerne merker noe, ikke etter. Cloud Run eksponerer disse metrikkene automatisk uten ekstra konfigurasjon, og de er tilgjengelige direkte i Google Cloud Console under fanen “Metrics” på tjenesten din.

Sikkerhet: minste privilegium for tjenestekontoer

Som standard kjører en Cloud Run-tjeneste med prosjektets standard tjenestekonto for Compute Engine, som ofte har langt bredere rettigheter enn tjenesten faktisk trenger. Det bryter med prinsippet om minste privilegium, og betyr at en sårbarhet i applikasjonskoden potensielt kan misbrukes til å nå andre ressurser i prosjektet, ikke bare dataene tjenesten selv eier. Beste praksis er å opprette en dedikert tjenestekonto per tjeneste, med kun de IAM-rollene tjenesten faktisk trenger.

# Opprett en dedikert tjenestekonto
gcloud iam service-accounts create cloud-run-demo-sa \
  --display-name="Tjenestekonto for cloud-run-demo"

# Gi kun tilgang til den ene hemmeligheten tjenesten trenger
gcloud secrets add-iam-policy-binding api-nokkel \
  --member="serviceAccount:cloud-run-demo-sa@mitt-cloud-run-prosjekt.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

# Koble tjenestekontoen til Cloud Run-tjenesten
gcloud run services update cloud-run-demo \
  --region=europe-north1 \
  --service-account=cloud-run-demo-sa@mitt-cloud-run-prosjekt.iam.gserviceaccount.com

Denne dedikerte kontoen bør kun ha akkurat de rollene applikasjonen trenger, for eksempel secretAccessor for én bestemt hemmelighet, ikke en generell rolle som gir tilgang til alle hemmeligheter i prosjektet. Det samme prinsippet gjelder om tjenesten skal lese eller skrive til Cloud Storage, BigQuery eller andre Google Cloud-tjenester: gi kun tilgang til de spesifikke ressursene som faktisk er i bruk.

Cloud Run-priser i 2026: hva koster det egentlig?

Cloud Run bruker en forbruksbasert prismodell der du betaler for CPU, minne og antall forespørsler, kun mens containeren faktisk behandler trafikk (med forespørselsbasert CPU-allokering). Gratisnivået er generøst nok til at mange små tjenester og sideprosjekter aldri genererer en faktura.

Ressurs	Pris utover gratisnivå	Gratisnivå per måned
CPU	$0,000018 per vCPU-sekund	180 000 vCPU-sekunder
Minne	$0,000002 per GiB-sekund	360 000 GiB-sekunder
Forespørsler	$0,40 per million forespørsler	2 millioner forespørsler

Tallene er hentet direkte fra Googles offisielle Cloud Run-prisside. Merk at alltid-allokert CPU (for bakgrunnsjobber og lange tilkoblinger) prises høyere enn forespørselsbasert CPU, siden du da betaler for kjøretid uavhengig av om containeren faktisk behandler trafikk akkurat da.

Som et konkret eksempel: en liten API med 512 MiB minne og 1 vCPU, som håndterer 100 000 forespørsler i måneden med gjennomsnittlig 200 millisekunder behandlingstid per kall, bruker rundt 20 000 vCPU-sekunder og 10 000 GiB-sekunder. Det holder seg godt innenfor gratisnivået, og totalregningen blir 0 kroner utover eventuelle kostnader for Artifact Registry-lagring, som normalt er minimale for et enkelt Node.js-image.

Skalerer den samme tjenesten opp til 10 millioner forespørsler i måneden, ser regnestykket annerledes ut. Da bruker du rundt 2 millioner vCPU-sekunder og 1 million GiB-sekunder, altså godt over gratisnivået på begge ressurser. Med forespørselsbasert CPU-allokering lander CPU-kostnaden på rundt (2 000 000 minus 180 000) multiplisert med $0,000018, som blir omtrent $33, mens minnekostnaden blir tilsvarende lav takket være den lave prisen per GiB-sekund. Forespørselskostnaden utover gratisnivået (8 millioner forespørsler) blir 8 multiplisert med $0,40, altså $3,20. Total månedlig kostnad havner dermed på under 40 dollar for en tjeneste som håndterer 10 millioner kall, noe som forklarer hvorfor så mange team velger Cloud Run fremfor å drifte egne servere som uansett må stå på døgnet rundt, uavhengig av faktisk trafikk.

Vanlige fallgruver når du deployer til Cloud Run

De fleste problemene team støter på i produksjon stammer ikke fra Cloud Run selv, men fra antakelser man tar med seg fra tradisjonell serverdrift. Under følger de feilene vi ser oftest hos team som deployer sin første containeriserte tjeneste til plattformen.

Feil port-håndtering. Cloud Run forventer at applikasjonen lytter på porten fra miljøvariabelen PORT. Hardkoder du port 3000 i koden mens Cloud Run sender PORT=8080, feiler containeren med en gang.
For store images. Et image på flere gigabyte gir tregere bygg, tregere push og lengre cold starts. Hold deg til slanke basisimages og multi-stage bygg der det er mulig.
Hemmeligheter i kildekoden. Å legge API-nøkler direkte i Dockerfilen eller miljøfiler som sjekkes inn i Git er en av de vanligste sikkerhetsfeilene i containeriserte applikasjoner.
Standard samtidighet på 1. Lar du samtidighet stå på standardverdien, skaleres tjenesten unødvendig aggressivt og kostnaden øker uten at ytelsen blir bedre.
Feil tilgangskontroll. Glemmer du --allow-unauthenticated på en offentlig API, får brukerne 403-feil. Motsatt problem oppstår om du legger til flagget på en tjeneste som skal være intern.
Root-bruker i containeren. Uten en eksplisitt USER-instruksjon i Dockerfilen kjører containeren som root som standard, noe som øker konsekvensene av en eventuell sårbarhet i applikasjonskoden.
For bred tjenestekonto. Å la Cloud Run-tjenesten bruke prosjektets standard tjenestekonto gir den ofte langt flere rettigheter enn den trenger. Opprett alltid en dedikert tjenestekonto med minste privilegium per tjeneste.
Ingen budsjettvarsel. Uten et varsel i Billing-seksjonen kan en feilkonfigurert autoskalering eller uventet trafikk kjøre kostnadene langt høyere enn planlagt før noen oppdager det.

Feilsøking: 8 vanlige problemer og løsninger

Når noe går galt, er Cloud Run-logger som regel første stoppested. De fleste feilmeldingene under vises enten direkte i terminalen når du kjører gcloud run deploy, eller i Cloud Logging noen sekunder etter at en container har prøvd og feilet å starte. Tabellen dekker de åtte problemene vi ser oftest hos team som setter opp sin første Cloud Run-tjeneste, sortert etter hvor tidlig i prosessen de vanligvis dukker opp.

Problem	Vanligste årsak	Løsning
“Container failed to start and listen on the port”	Appen leser ikke `PORT`-variabelen, eller lytter kun på localhost	Bruk `process.env.PORT` og bind til `0.0.0.0`
“Permission denied” ved docker push	Docker er ikke autentisert mot riktig region-host	Kjør `gcloud auth configure-docker europe-north1-docker.pkg.dev` på nytt
403 Forbidden ved kall til tjenesten	Mangler `--allow-unauthenticated` eller IAM-rollen `roles/run.invoker`	Legg til flagget ved deploy, eller tildel rollen eksplisitt til kalleren
Cold start tar flere sekunder	`min-instances=0` kombinert med stort image eller treg oppstartskode	Sett `min-instances=1` for latency-kritiske tjenester, og reduser imagestørrelsen
“Quota exceeded” under trafikktopper	`max-instances` satt for lavt, eller prosjektets kvote nådd	Øk `max-instances`, eller be om kvoteøkning i Google Cloud Console
Secret Manager gir “Permission denied”	Tjenestekontoen mangler rollen `roles/secretmanager.secretAccessor`	Kjør `add-iam-policy-binding` mot riktig tjenestekonto
Domenetilordning står fast på “Pending”	DNS-postene er ikke lagt inn eller ikke ferdig propagert	Dobbeltsjekk DNS-oppsettet og vent opptil 24 timer
“This project doesn’t have billing enabled”	Fakturakonto er ikke koblet til prosjektet	Kjør `gcloud billing projects link` med riktig konto-ID

Avanserte tips: autoskalering, GPU-støtte og Next ’26-nyheter

Når grunnoppsettet er stabilt, er det flere funksjoner fra 2026 verdt å utforske videre. Cloud Run Instances, introdusert på Next ’26, gir deg individuelt adresserbare og langvarige instanser i stedet for kun stateløse HTTP-tjenester. Dette passer godt til bakgrunnsagenter som skal kjøre kontinuerlig, i motsetning til tradisjonelle Cloud Run-tjenester som skalerer strengt basert på innkommende trafikk.

GPU-støtten er den andre store nyheten. Med NVIDIA RTX PRO 6000 Blackwell-GPUer kan du kjøre inferens for store språkmodeller (over 70 milliarder parametere) direkte på Cloud Run, uten å administrere GPU-noder selv, og fortsatt dra nytte av skalering til null når ingen bruker modellen. Google demonstrerte også Zip Deploy, en Dockerfile-fri utrullingsmetode som ifølge Next ’26-presentasjonene kutter utrullingstiden fra rundt 90 sekunder til mellom 10 og 20 sekunder for enkle applikasjoner, samt en forhåndsvisning av SSH-tilgang direkte til kjørende Cloud Run-tjenester via gcloud run services ssh. Les mer i Googles oppsummering av Cloud Next 2026.

For team som jobber med agentbaserte arbeidsflyter er også administrerte MCP-servere (Model Context Protocol) på Cloud Run verdt å følge med på, siden de lar agenter administrere og deploye applikasjoner direkte, kombinert med IAM Deny-policyer for kontrollert tilgang.

Et siste tips: sett opp et budsjettvarsel så snart prosjektet er i produksjon. Google Cloud lar deg definere en terskel i Billing-seksjonen som sender et varsel på e-post når forbruket nærmer seg et gitt beløp, uansett om det skyldes en trafikktopp du ikke forventet eller en feilkonfigurert max-instances-verdi som skalerer langt mer enn planlagt. Det koster ingenting å sette opp, og det er ofte forskjellen mellom å oppdage et problem samme dag eller først når fakturaen kommer neste måned.

Automatiser utrulling med Cloud Build og GitHub Actions

Å kjøre deploy.sh manuelt fungerer greit for en demo, men i et team vil du fort trenge en automatisert pipeline som bygger og deployer hver gang noen pusher til hovedgrenen. Google Cloud Build kan settes opp med en trigger som lytter på et Git-repository, uten at du trenger noe eget CI-verktøy i tillegg.

# cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'europe-north1-docker.pkg.dev/$PROJECT_ID/cloud-run-demo-repo/cloud-run-demo:$SHORT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'europe-north1-docker.pkg.dev/$PROJECT_ID/cloud-run-demo-repo/cloud-run-demo:$SHORT_SHA']
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - 'run'
      - 'deploy'
      - 'cloud-run-demo'
      - '--image=europe-north1-docker.pkg.dev/$PROJECT_ID/cloud-run-demo-repo/cloud-run-demo:$SHORT_SHA'
      - '--region=europe-north1'

Kobler du dette til et GitHub-repository via en Cloud Build-trigger, kjøres bygget og utrullingen automatisk hver gang du pusher en endring. Foretrekker du GitHub Actions i stedet for Cloud Build, kan du oppnå det samme ved å autentisere mot Google Cloud med Workload Identity Federation og kalle de samme gcloud-kommandoene fra en workflow-fil.

Uansett hvilket verktøy du velger, bør pipelinen alltid kjøre testene dine før den bygger og pusher et nytt image. Å automatisere en utrulling uten å automatisere testkjøringen først flytter bare feilene fra din egen maskin til produksjon litt raskere enn før, noe som i praksis gjør vondt verre i stedet for bedre.

# .github/workflows/deploy.yml (utdrag)
- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
    service_account: cloud-run-demo-sa@mitt-cloud-run-prosjekt.iam.gserviceaccount.com

- uses: google-github-actions/deploy-cloudrun@v2
  with:
    service: cloud-run-demo
    region: europe-north1
    image: europe-north1-docker.pkg.dev/mitt-cloud-run-prosjekt/cloud-run-demo-repo/cloud-run-demo:${{ github.sha }}

Workload Identity Federation er å foretrekke fremfor å lagre en nedlastet JSON-nøkkelfil som GitHub-hemmelighet, siden det unngår langvarige, statiske legitimasjoner som kan lekke. Dette er samme prinsipp som beskrevet i steget om tjenestekontoer over: gi pipelinen kun de rettighetene den faktisk trenger for å bygge og deploye, ikke bredere prosjektrettigheter.

Cloud Run Jobs: batch-oppgaver uten en kjørende tjeneste

Alt vi har satt opp så langt er en Cloud Run-tjeneste, ment for å svare på HTTP-forespørsler. Men en god del arbeidslaster passer bedre som en jobb: et engangsskript som kjører migrasjon av en database, genererer en rapport, eller prosesserer en batch med bilder, og deretter avsluttes helt. For dette har Google en egen ressurstype kalt Cloud Run Jobs, som skiller seg fra tjenester ved at den ikke eksponerer noen HTTP-endepunkt og ikke kjører kontinuerlig i påvente av trafikk.

gcloud run jobs create migrer-database \
  --image=europe-north1-docker.pkg.dev/mitt-cloud-run-prosjekt/cloud-run-demo-repo/cloud-run-demo:v1 \
  --region=europe-north1 \
  --tasks=1 \
  --max-retries=2 \
  --command="node" \
  --args="migrate.js"

# Utfør jobben manuelt
gcloud run jobs execute migrer-database --region=europe-north1

# Eller planlegg den med Cloud Scheduler, f.eks. hver natt klokken 03:00
gcloud scheduler jobs create http migrer-database-nattlig \
  --schedule="0 3 * * *" \
  --uri="https://europe-north1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/mitt-cloud-run-prosjekt/jobs/migrer-database:run" \
  --oauth-service-account-email=cloud-run-demo-sa@mitt-cloud-run-prosjekt.iam.gserviceaccount.com

Bruker du samme container-image til både tjenesten og jobben, som i eksempelet over, er det viktig å ha separate kommandoer eller entrypoints for de to bruksområdene, slik at jobben faktisk kjører migrasjonsskriptet og ikke starter en HTTP-server som aldri mottar trafikk og bare henger til den treffer timeout-grensen.

Komplett eksempelprosjekt

Til slutt, her er hele filstrukturen samlet, slik at du kan kopiere den rett inn i et nytt prosjekt.

cloud-run-demo/
├── index.js          # Express-server, lytter på process.env.PORT
├── package.json      # Avhengigheter og Node.js-versjon
├── package-lock.json # Generert av npm install
├── Dockerfile         # Slankt node:22-slim-basert bygg
├── .dockerignore      # Ekskluderer node_modules og .git
└── deploy.sh          # Samler alle gcloud-kommandoene fra denne guiden

#!/bin/bash
set -e

PROJECT_ID="mitt-cloud-run-prosjekt"
REGION="europe-north1"
REPO="cloud-run-demo-repo"
IMAGE="cloud-run-demo"
TAG="v1"

FULL_IMAGE="${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO}/${IMAGE}:${TAG}"

docker build -t $IMAGE .
docker tag $IMAGE $FULL_IMAGE
docker push $FULL_IMAGE

gcloud run deploy $IMAGE \
  --image=$FULL_IMAGE \
  --region=$REGION \
  --allow-unauthenticated \
  --memory=512Mi \
  --cpu=1 \
  --concurrency=80 \
  --min-instances=0 \
  --max-instances=20

Med dette skriptet kan du deploye på nytt med én enkelt kommando hver gang du gjør endringer i koden, og du har et gjenbrukbart mønster for fremtidige mikrotjenester. Legg strukturen i et Git-repository fra dag én, selv om du bare tester lokalt, siden det gjør det enkelt å koble på Cloud Build eller GitHub Actions senere uten å måtte omorganisere prosjektet.

Vil du utvide eksempelet videre, er neste naturlige steg å legge til en ekte database. DynamoDB-alternativet i Google Cloud er Firestore, som fungerer godt sammen med Cloud Run siden begge skalerer automatisk og fakturerer basert på faktisk bruk. Legg til @google-cloud/firestore som avhengighet i package.json, opprett en tjenestekonto med rollen roles/datastore.user, og koble den til tjenesten på samme måte som beskrevet i sikkerhetssteget over.

Relatert dekning

Ofte stilte spørsmål

Hva koster det å kjøre en liten Cloud Run-tjeneste per måned?

De fleste sideprosjekter og interne verktøy med lav trafikk holder seg innenfor gratisnivået på 180 000 vCPU-sekunder, 360 000 GiB-sekunder og 2 millioner forespørsler per måned, og ender dermed på 0 kroner i Cloud Run-kostnad. Kilde: Google Cloud Run-priser.

Hvilken region bør norske og nordiske utviklere velge?

europe-north1 i Hamina, Finland, er den nærmeste Google Cloud-regionen og gir lavest ventetid for brukere i Norge, Sverige, Danmark og Finland.

Er Cloud Run det samme som Kubernetes?

Nei. Cloud Run kjører riktignok containere på en Kubernetes-basert infrastruktur under panseret, men du administrerer aldri noder, poder eller klynger selv. Trenger du full kontroll over Kubernetes-objekter, er GKE Autopilot et bedre valg.

Kan Cloud Run kjøre GPU-arbeidslaster?

Ja, siden Next ’26 er støtte for NVIDIA RTX PRO 6000 Blackwell-GPUer allment tilgjengelig på Cloud Run, egnet for inferens på modeller med over 70 milliarder parametere, med skalering til null når GPU-en ikke er i bruk.

Hvordan skiller Cloud Run seg fra Cloud Functions?

Cloud Functions kjører enkeltfunksjoner utløst av hendelser og har en maksimal grense på 9 minutter per kall. Cloud Run kjører hele containere med hvilken som helst kjøretid, og støtter forespørsler i opptil 60 minutter, noe som gjør det bedre egnet for fullverdige applikasjoner og API-er.

Trenger jeg Docker for å bruke Cloud Run?

I klassisk oppsett, ja, siden Cloud Run kjører containerimages. Med den nye Zip Deploy-funksjonen fra Next ’26 kan du derimot deploye enklere applikasjoner uten å skrive en egen Dockerfile, siden Google da bygger containeren for deg automatisk.

Hvor lenge kan en enkelt forespørsel kjøre på Cloud Run?

Request-timeout kan konfigureres opp til 60 minutter (3600 sekunder) for HTTP-tjenester. Standardverdien er lavere, så du må justere den eksplisitt om applikasjonen din har lange, synkrone kall.

Må jeg oppgradere gcloud CLI ofte?

Ja, det anbefales. Nye Cloud Run-funksjoner, som Cloud Run Instances og GPU-støtte, krever ofte en oppdatert CLI-versjon. Kjør gcloud components update jevnlig, og sjekk versjonen mot Googles offisielle utgivelsesnotater før du feilsøker uventet oppførsel.

Hva er forskjellen på en Cloud Run-tjeneste og en Cloud Run-jobb?

En tjeneste kjører kontinuerlig og svarer på HTTP-forespørsler, med automatisk skalering basert på trafikk. En jobb kjører én eller flere ganger, utfører en avgrenset oppgave som en migrasjon eller batch-prosessering, og avsluttes deretter. Bruk tjenester for API-er og nettapplikasjoner, og jobber for engangsoppgaver og planlagt vedlikehold.

Kan jeg kjøre flere versjoner av samme tjeneste samtidig?

Ja. Cloud Run støtter trafikksplitting mellom revisjoner, slik at du kan rulle ut en ny versjon til for eksempel 10 prosent av trafikken før du gradvis øker andelen. Det gjøres med gcloud run services update-traffic og lar deg fange opp feil i en ny versjon før den treffer alle brukerne.

Google Cloud Run: Deploy App i 12 Steg, 45 Min [2026]