CI-runnere

fremforge tilbyr hostede runnere som er inkludert i alle planer med betaling per bruker, og støtter egne runnere (BYO) for team som trenger on-prem, spesiell maskinvare eller en bestemt plassering i nettverket. Begge runnertypene kjører Forgejo Actions-workflower med den samme YAML-syntaksen som GitHub Actions.

Hostede runnere

Hostede runnere er virtuelle maskiner per commit på T Cloud Public i regionen eu-de (Biere/Magdeburg). En VM klargjøres fra et tilpasset debian-image med Docker forhåndsinstallert, kjører jobber fra én commit i ett repository og slettes når jobbene for den commiten er ferdige. Ingenting blir værende mellom commits.

Tilgjengelige etiketter

Referer til en etikett i workflowen:

jobs:
  build:
    runs-on: fremforge

Containerbygg fungerer på to måter rett ut av boksen – se Innholdet i runner-imaget § Containerbygg nedenfor for hele oppdelingen:

• Innebygd Docker (standard) – docker build, docker compose og docker pull virker uten videre. Docker-daemonen kjører direkte på VM-en (ingen Docker-in-Docker-sidecar), så docker oppfører seg som på en GitHub-hostet runner. Passer for 90 % av workflowene.
• kaniko – uten daemon, raskere kaldstart, bedre lagbuffer mot eksterne registre. Bruk den når du ikke trenger BuildKit-spesifikke funksjoner.

jobs:
  build-image:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA .
      - run: docker push registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA 2>&1 | stdbuf -oL tr '\r' '\n' | grep -vE '^(Waiting|)$'

Hostede ARM64-runnere og flere OS-varianter (Ubuntu, Fedora, …) står på veikartet (se endringsloggen) – fremforge støtter i dag bare x86_64 Linux. Egne runnere (se nedenfor) er veien for ARM64 eller workflower som ikke er Linux, i mellomtiden.

Isolasjonsmodell

Jobber kjører på dedikerte virtuelle maskiner med egen kjerne. Plattformen følger med på køen i Forgejo Actions og starter en ny VM for en ventende jobb. En kaldstart tar rundt 40 sekunder før jobbens første steg; det finnes ingen pool med forhåndsstartede VM-er.

Én commit, ett tillitsdomene. En VM kjører bare jobber fra commiten og repositoryet den ble startet for. Når en jobb er ferdig, venter VM-en i opptil 60 sekunder på en annen jobb fra den samme commiten, i hvilken som helst workflow, og kjører den uten ny oppstart (rundt 5 sekunder før den starter). Deretter slås den av og slettes. Ingen VM kjører jobber fra to commits, to repositoryer eller to organisasjoner, så behandle alle jobbene i én commit som ett tillitsdomene. Legitimasjon som plattformen kjenner til (Docker- og npm-innlogginger, de vanlige legitimasjonsfilene), nullstilles mellom jobbene, men verktøybuffere og pullede imager blir liggende på VM-en. Se Sikkerhetsmodellen for hostede runnere for hele designet.

Dimensjonere jobber for hostede runnere

Hver ny VM koster rundt 40 sekunder oppstart før det første steget ditt, og ofte ventetiden på 60 sekunder etter det siste. En jobb som gjør 15 sekunders arbeid, holder derfor en VM i rundt to minutter. Altså:

• Gi en jobb sin egen VM bare når arbeidet tar rundt 2 minutter eller mer. Kortere sjekker (lint, en liten testpakke, et kontrollskript) er billigere og raskere som ekstra steg i en eksisterende jobb.
• Parallelliser langt, uavhengig arbeid (testshards, imagebygg, ende-til-ende-tester) på tvers av jobber. Det er det samtidighet er til for.
• Parallelliser kort arbeid inne i én jobb i stedet for på tvers av jobber, for eksempel flere tofu plan-kjøringer i bakgrunnsprosesser i ett steg. De venter for det meste på API-er, ikke på CPU.
• Kjeder gjenbruker VM-er automatisk. En needs:-jobb som blir klar mens forgjengerens VM fortsatt venter (innen 60 sekunder), kjører på den VM-en uten oppstart. En bred vifte av jobber som alle starter samtidig, kan ikke gjenbruke noe: hver av dem trenger sin egen VM.
• Hold en kjøring innenfor samtidigheten din. En matrise som er bredere enn organisasjonens garanterte andel, kjører i bølger, og den siste bølgen venter på at en hel jobb skal bli ferdig. Dimensjoner shards slik at en kjøring passer i én bølge.

Minne

En hostet runner-VM har 4 GiB minne og ingen swap (2 vCPU). Det finnes i dag ingen større størrelse på hostede runnere.

En jobb som går tom for minne, feiler i løpet av rundt ett minutt. Når tilgjengelig minne faller under rundt 4 % (omtrent 130 MiB), stopper runneren jobbens største prosess, helst byggeverktøy som node, tsc, java og vitest-workere. Den sender SIGTERM først og SIGKILL hvis minnet fortsetter å synke. Steget feiler med exit-kode 143 eller 137, og steg-loggen sier hvorfor:

earlyoom: killed node (pid 4242) because the runner VM ran out of memory. ...

Det er aldri runneren selv som stoppes, så jobbens resultat og logger rapporteres fortsatt. Før denne endringen kunne en jobb som vokste ut av VM-en, henge i det stille til timeout-minutes var nådd.

Ser du denne linjen, reduserer du jobbens toppforbruk av minne:

• Del opp arbeidet i flere jobber. Kjører du et stort bygg ved siden av integrasjonstestene, eller en docker build ved siden av testcontainere, legges de to toppene sammen på én VM.
• Begrens verktøyets minne. For eksempel NODE_OPTIONS=--max-old-space-size=2048 for Node, --checkers 1 og GOMEMLIMIT for TypeScript 7 (tsc skrevet i Go), -Xmx for Java, færre testworkere (--maxWorkers / --pool-options).
• Strøm i stedet for å laste inn. For skanning av store imager, se Skanne store imager med Trivy.

Hvis en jobb ikke får plass i 4 GiB, kontakter du support@frem.sh eller kjører den på en egen runner som er dimensjonert for den.

Inkluderte minutter og samtidighet

Jobber over organisasjonens grense venter i køen i stedet for å feile. Kontakt support@frem.sh hvis du trenger en høyere garantert andel.

Fakturering av overforbruk (tilvalg): som standard settes nye jobber i kø når potten er brukt opp. Eiere av organisasjonen kan slå på målt overforbruk under Organisasjonsadministrasjon → Fakturering → Forbruk av runner-minutter. Når det er slått på, faktureres minutter utover potten med 0,01 € per minutt på neste faktura. Overforbruk kan slås av når som helst fra samme side.

Dashbord for forbruk

Følg forbruket av runner-minutter under Organisasjonsadministrasjon → Fakturering → Forbruk av runner-minutter.

Dashbordet for forbruk viser:

Minutter telles fra jobbstart til jobbslutt, rundet opp til nærmeste sekund. Tid i kø (venting på en runner) telles ikke.

Den månedlige perioden nullstilles den 1. i hver måned (UTC). Ubrukte minutter overføres ikke.

Minutter på egne runnere følges separat i det samme dashbordet og teller ikke mot den hostede potten.

Varselgrenser for forbruk som kunden kan justere, er ennå ikke tilgjengelige – fremforge sender en standard advarsel på e-post når organisasjonen når 80 % av den månedlige potten. Kontakt support@frem.sh for å justere grensen.

Innholdet i runner-imaget

Det hostede runner-imaget bygges på nytt hver uke (mandag 06:00 UTC) fra upstream-versjoner av verktøyene som Renovate følger. Hver nedlasting under byggingen er pinnet med sha256 (bygget feiler ved avvik). En Trivy-sperre for CVE-er kjører ved byggingen – et image med HIGH- eller CRITICAL-funn blokkeres fra å bli levert til det er patchet.

Før et nybygget image tas i bruk på runnerflåten, kontrolleres det på nytt mot listene over sårbarheter som utnyttes aktivt (ENISA EUVD og CISA KEV). Et image med en aktivt utnyttet CVE som det finnes en rettelse for, rulles ikke ut, uansett alvorlighetsgrad, med mindre et gjennomgått unntak på høyst 30 dager dekker den CVE-en. Runnerne fortsetter å bruke det forrige imaget til et patchet image er bygget.

Modell med to lag, begge i EU:

• Systemlaget (~300 MB) – debian-base + systemverktøy i én versjon (Node 24 LTS, byggeverktøy, skannere, IaC- og sky-CLI-er, nettlesere, databaseklienter). Del av oppstartsdisken til VM-en; ingen nedlasting per jobb.
• hostedtoolcache-laget (~7 GB) – språkverktøykjeder i flere versjoner (Node, Go, Python, .NET, Java, Ruby) + Android SDK + Miniconda3 + R (siden 2026-06-06). Bakt inn i den samme oppstartsdisken på /opt/hostedtoolcache. setup-*-actions slås opp her uten nedlasting per jobb.

Hvordan vi gir full dekning på ~7 GB totalt når GitHubs ubuntu-latest er ~50 GB: se størrelsessammenligningen nedenfor.

Forhåndsinstallert i systemlaget:

Forhåndsinstallert i hostedtoolcache (slås opp av setup-*-actions, ingen nedlasting per jobb):

Den kanoniske versjonslisten med nøyaktige versjoner + image-digest + sammendrag av Trivy-skanningen + CycloneDX-SBOM publiseres med hver ukentlige gjenoppbygging – se referansen for runner-imaget for gjeldende verktøysett.

Containerbygg: innebygd Docker eller kaniko

To veier – velg etter arbeidslast:

Innebygd Docker (standard) – VM-en leveres med Docker-daemonen installert og kjørende på verten. docker-CLI-en snakker med den over den vanlige lokale socketen – ingen omvei via DOCKER_HOST, ingen sidecar. Virker for docker build, docker compose, docker pull, flertrinnsbygg og BuildKit-funksjoner. Fullt på nivå med docker på GitHub-hostede runnere.

- run: docker build -t myapp:${{ github.sha }} .
- run: docker push myapp:${{ github.sha }} 2>&1 | stdbuf -oL tr '\r' '\n' | grep -vE '^(Waiting|)$'

Skanne store imager med Trivy

trivy image <ref> (via daemonen) holder lagmetadata for hele imaget i minnet mens den går gjennom filsystemet – imager på flere GB kan gi topper langt over minnegrensen til runner-VM-en og utløse en OOM-kill midt i skanningen. Det pålitelige mønsteret for alle imagestørrelser er å strømme imaget via docker save:

- run: docker build -t myapp:${{ github.sha }} .
- run: |
    docker save myapp:${{ github.sha }} | trivy image \
      --severity HIGH,CRITICAL --ignore-unfixed \
      --scanners vuln --pkg-types os \
      --offline-scan --no-progress --quiet \
      --input -

Hvorfor det virker: docker save leser lagene fra disk og strømmer tar-filen inn på trivys stdin ett lag om gangen. Trivy tolker hvert lag for metadata om OS-pakker (~titalls KB per lag) og forkaster det før det neste. Samlet topp-RSS holder seg rundt 500 MB uansett total imagestørrelse, så skanningen får god plass innenfor minnebudsjettet til runner-VM-en. GOGC=10 foran trivy (f.eks. GOGC=10 trivy ...) strammer inn heapen ytterligere hvis du noen gang nærmer deg grensen.

Filteret tr '\r' '\n' på docker push anbefales: Docker skriver fremdriften for opplasting av lag med vognretur-overskrivinger som steg-loggen i Forgejo Actions behandler som én linje som vokser og vokser, og som avkortes uten varsel. Uten filteret viser en push som stopper opp eller feiler midt i opplastingen, bare <layer>: Preparing i loggen uten detaljer om feilen – når steget får tidsavbrudd, er den egentlige feilen allerede overskrevet. Ved å sende utdataene gjennom tr blir hvert fremdriftssteg en egen linje som fanges opp intakt, og grep -vE '^(Waiting|)$' fjerner tomme linjer og ventelinjer. Gjennomstrømningen for push av lag påvirkes ikke.

Kundens registre (ghcr.io, dockerhub, quay.io, dine egne) kan nås via runnerens utgående trafikk; proxyen har et tidsavbrudd på 30 min per forespørsel, slik at PUT av lag på flere GB fullføres uten problemer. Budsjett for imagestørrelse: 50 GB per bygg (grensen for VM-ens arbeidsdisk) – send en henvendelse hvis du trenger mer.

kaniko – OCI-bygger uten daemon og uten root. Raskere kaldstart enn hele Docker-daemonen, bedre oppførsel for lagbuffer mot eksterne registre. Bruk den når bygget ikke trenger BuildKit-spesifikke funksjoner.

- run: |
    /usr/local/bin/kaniko \
      --context=$GITHUB_WORKSPACE \
      --dockerfile=Dockerfile \
      --destination=registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA

For kind- / testcontainers-arbeidslaster som trenger KVM-nestede gjester, legger du etiketten dind-privileged til i runs-on. fremforge sender disse til en VM-variant med nestet virtualisering slått på.

Størrelse sammenlignet med GitHub-hostede runnere

GitHubs ubuntu-latest er ~50 GB fordi den baker inn:

• Flere versjoner per språk – 3 nyere serier for Node, Python, Java og Ruby; 2 for Go og .NET (~3 GB totalt). Tabellen over er det autoritative settet.
• Android SDK + NDK (~10 GB på GitHub-hostede) – vi baker inn kjerne-SDK-en (platform 34 + build-tools + platform-tools, ~3 GB); flere API-nivåer + NDK + emulatorer installeres per jobb via setup-android@v3 (det som er bakt inn, lastes ikke ned på nytt).
• Forhåndshentede Docker-imager for tjenestecontainere (postgres, mysql, mongo, redis, mssql ~5 GB) – ikke bakt inn; en docker pull henter dem fra Docker Hub eller gjennom organisasjonens avhengighetsproxy (se pakkebuffere).
• Nettleseren Microsoft Edge – ikke bakt inn (Chromium er samme motor for hodeløs testing i CI).
• Mono / Julia / Swift / Haskell / Lua / Crystal / Nim / Elixir – ikke bakt inn (smalt, installer per jobb via setup-* eller apt).
• Flere GCC-versjoner, gamle verktøykjeder som beholdes for kompatibilitet – vi leverer ett gjeldende sett.

Vi mangler ikke verktøy som en typisk workflow bruker – alle vanlige språk, alle store sky-CLI-er, alle vanlige skannere, begge de store nettleserne, Docker (innebygd, root via etiketten dind-privileged), Android (kjerne-SDK) og datavitenskap (Miniconda3 + R). iOS / Xcode er ikke kompatibelt med Linux og følges opp separat; smale språk (Julia/Swift/Haskell/Mono) installeres per jobb. Si fra hvis teamet ditt trenger noe vi ikke baker inn, så vurderer vi det for neste ukentlige gjenoppbygging av imaget.

For alle detaljer per verktøy, se docs.frem.sh/build/actions/runner-image/.

Egne runnere (BYO)

Registrer egne runnere mot en hvilken som helst organisasjon i fremforge (on-prem-servere, sky-VM-er, Mac mini, Raspberry Pi). Minutter på egne runnere teller ikke mot den hostede potten.

Registrering

1. I organisasjonens Forgejo-innstillinger går du til Innstillinger → Actions → Runnere → Opprett ny runner (frem.sh/org/<org>/settings/actions/runners).
2. Kopier registreringstokenet.
3. Last ned den binære Forgejo-runneren. Gjeldende stabile versjon publiseres på code.forgejo.org/forgejo/runner/releases; pin til en nylig tag når du installerer:

# Linux x86_64 — replace <version> with the tag from the releases page (e.g. v6.4.0)
curl -sSL https://code.forgejo.org/forgejo/runner/releases/download/<version>/forgejo-runner-<version>-linux-amd64 \
  -o forgejo-runner && chmod +x forgejo-runner

# macOS arm64
curl -sSL https://code.forgejo.org/forgejo/runner/releases/download/<version>/forgejo-runner-<version>-darwin-arm64 \
  -o forgejo-runner && chmod +x forgejo-runner

fremforge følger gjeldende Forgejo-utgivelser; runnere med eldre binærfiler fortsetter å virke, men bør oppgraderes innen én utgivelsessyklus for å få med CVE-rettelser.

4. Registrer runneren:

./forgejo-runner register \
  --instance https://frem.sh \
  --token <registration-token> \
  --name my-runner \
  --labels linux,self-hosted,my-custom-label

5. Start runneren:

./forgejo-runner daemon

Støttede plattformer

Egendefinerte etiketter

Etikettene du gir ved registrering, er det du refererer til i runs-on::

jobs:
  deploy:
    runs-on: [self-hosted, my-custom-label]

Flere etiketter i en liste betyr «finn en runner som har ALLE disse etikettene». Etiketten self-hosted er en konvensjon. Ta den med for å unngå at en BYO-jobb ved et uhell sendes til en hostet runner.

Ikke bruk reserverte etiketter. Etikettene fremforge og linux/amd64 sendes til poolen med hostede runnere (de eldre aliasene fremforge-cci og cci er utfaset og sendes samme vei). Velg egne etiketter for runnerne dine (f.eks. self-hosted, on-prem, my-team-runner), slik at workflower kan adressere dem entydig.

Nettverkskrav for runner-verten

Runner-binæren åpner HTTPS-tilkoblinger med long polling til https://frem.sh og kloner repositoryer over HTTPS. Sett fra verten er kravene til tilkobling:

Det trengs ingen innkommende tilkobling – runneren starter alle tilkoblinger utover. En runner bak NAT eller en brannmur fungerer fint så lenge den kan nå frem.sh:443.

Ansvar for sikkerhet og isolasjon

For hostede runnere sørger fremforge for isolasjon på kjernenivå mellom commits og mellom kunder (hver commit kjører i en ny, flyktig ECS-VM; jobber i samme commit kan dele den). For egne runnere er isolasjonen ditt ansvar. En selvhostet runner som håndterer workflower fra flere repositoryer, deler tilstand mellom jobber med mindre du avgrenser hver runner til ett enkelt repository eller én organisasjon.

Hvis du kjører workflower fra flere team eller tillitsdomener, behandler du den egne runneren på samme måte som selvhostede runnere i GitHub Actions:

• Én runner per repository (eller per tillitsgrense) når secrets er sensitive.
• Ikke registrer en egen runner mot et offentlig repository – alle med merge-tilgang kan få inn en endring i en workflow som kjører vilkårlig kode på runner-verten.
• Behandle runner-verten som produksjon: herd operativsystemet, hold runner-binæren patchet, og send den utgående trafikken gjennom dine egne SSRF- og egress-kontroller.

fremforges utgående SSRF-proxy gjelder IKKE for egne runnere – bare for hostede runnere. Nettverkspolicyen for runneren din er det du selv setter opp på verten.

Utgående trafikk og nettverk

Tillatelsesliste for utgående trafikk per organisasjon: for å tillate utgående tilgang til flere CIDR-er eller porter fra runner-jobber kontakter du support@frem.sh. Regler for utgående trafikk settes opp på plattformnivå.

SSRF-proxyen er et minstenivå for plattformen. Den kan ikke slås av. Den hindrer runner-jobber i å nå instansmetadata i T Cloud Public eller intern infrastruktur.

Secrets i jobber

Secrets legges inn som miljøvariabler og maskeres i jobbloggene. Alle logglinjer som inneholder verdien til en secret, erstattes med ***.

Syntaks for referanser:

steps:
  - name: Deploy
    env:
      API_KEY: ${{ secrets.MY_API_KEY }}
    run: ./deploy.sh

Omfang for secrets

Miljø-secrets krever at jobben deklarerer et miljø:

jobs:
  deploy:
    runs-on: fremforge
    environment: production
    steps:
      - run: echo ${{ secrets.PROD_API_KEY }}

For legitimasjon til skyleverandører bør du foretrekke OIDC-tokenføderasjon framfor langlivede secrets. Ingen secret å lagre, ingen secret å rotere.

Feilsøking

Et steg feiler med earlyoom: killed <process> ... ran out of memory.

Jobben brukte mer enn de 4 GiB minne runner-VM-en har, så runneren stoppet den største prosessen i stedet for å la VM-en henge. Se Minne for hvordan du reduserer jobbens toppforbruk.

Jobben står fast i køen.

Den vanligste årsaken er at grensen for samtidighet per organisasjon er nådd (2 samtidige jobber per bruker garantert, minst 10 og høyst 60; se Inkluderte minutter og samtidighet). Sjekk Organisasjonsadministrasjon → Fakturering → Forbruk av runner-minutter for antall aktive jobber nå. Hvis du er på grensen, venter du enten til en kjørende jobb er ferdig, eller kontakter support@frem.sh for en Enterprise-on-Demand-økning.

docker-kommandoen virker, men en operasjon som krever utvidede rettigheter, feiler (f.eks. oppretting av en kind-klynge med KVM-nesting).

Standard-VM-en for runs-on: fremforge kjører Docker direkte med standardinnstillinger for rotløs bruker – docker build / docker compose / docker pull virker rett ut av boksen, men operasjoner som krever ekstra capabilities (KVM-nesting, rå /dev-tilgang for en nestet gjest, visse nettverksmoduser for kind-klynger), gjør det ikke. Legg etiketten dind-privileged til i runs-on (runs-on: [fremforge, dind-privileged]) – fremforge sender jobben til en VM-variant med nestet virtualisering slått på. Samme isolasjon med én VM per commit; samme image; bare utvidede capabilities.

For ren kopiering/ny tagging av imager mellom registre (uten bygg) virker det forhåndsinstallerte skopeo uten at du trenger Docker-daemonen i det hele tatt.

En secret maskeres i loggene, men steget oppfører seg som om den er tom.

Secreten finnes i kjøremiljøet (maskeringen bekrefter det), men verdien på riktig nivå er ikke satt. Sjekk:

1. Er secreten satt på organisasjonsnivå, repository-nivå eller miljønivå?
2. Hvis det er en miljø-secret: deklarerer jobben environment: <name> som matcher miljøet til secreten?
3. Er navnet på secreten stavet helt riktig (det skilles mellom store og små bokstaver)?

Secrets-grensesnittet på det aktuelle nivået viser navnet på secreten og tidspunktet for siste oppdatering. Bruk det til å bekrefte at secreten finnes før du ser på workflowen.

Se også

• OIDC-tokenføderasjon: nøkkelfri skyautentisering fra CI-jobber
• Secrets: administrasjon av secrets for organisasjon, repository og miljø
• Marketplace-kompatibilitet: hvilke actions fra GitHub Marketplace som virker på fremforges runnere
• AI-holdning: hvilke AI-verktøy som finnes og ikke finnes i runner-miljøet