CI-runners

fremforge tillhandahåller hostade runners som ingår i varje abonnemang per användare, och stöder egna runners (BYO) för team som behöver on-prem, särskild hårdvara eller en viss placering i nätverket. Båda typerna kör Forgejo Actions-arbetsflöden med samma YAML-syntax som GitHub Actions.

Hostade runners

Hostade runners är virtuella maskiner per commit på T Cloud Public i regionen eu-de (Biere/Magdeburg). En VM provisioneras från en egen Debian-image med Docker förinstallerat, kör jobb från en commit i ett repo och förstörs när jobben för den commiten är klara. Ingenting sparas mellan commits.

Tillgängliga etiketter

Ange en etikett i ditt arbetsflöde:

jobs:
  build:
    runs-on: fremforge

Containerbyggen fungerar på två sätt direkt, utan konfiguration. Se Innehållet i runner-imagen § Containerbyggen nedan för hela uppdelningen:

• Inbyggd Docker (standard): docker build, docker compose och docker pull fungerar bara. Docker-daemonen körs direkt på VM:en (ingen Docker-in-Docker-sidecar), så docker beter sig likadant som på en runner hostad av GitHub. Passar 90 % av arbetsflödena.
• kaniko: utan daemon, snabbare kallstart och bättre lagercache mot fjärrregister. Använd det när du inte behöver BuildKit-specifika funktioner.

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|)$'

Hostade ARM64-runners och fler OS-varianter (Ubuntu, Fedora, …) finns på färdplanen (se ändringsloggen). I dag stöder fremforge bara Linux på x86_64. Under tiden är egna runners (se nedan) vägen för ARM64 eller arbetsflöden som inte kör Linux.

Isoleringsmodell

Jobb körs på dedikerade virtuella maskiner med egen kärna. Plattformen bevakar kön i Forgejo Actions och startar en ny VM för ett väntande jobb. En kallstart tar ungefär 40 sekunder innan jobbets första steg; det finns ingen pool av förstartade VM:ar.

En commit, en förtroendedomän. En VM kör bara jobb från den commit och det repo den startades för. När ett jobb är klart väntar VM:en i upp till 60 sekunder på ett annat jobb från samma commit, i vilket arbetsflöde som helst, och kör det utan ny uppstart (ungefär 5 sekunder till start). Därefter stängs den av och raderas. Ingen VM kör jobb från två commits, två repon eller två organisationer, så behandla alla jobb i en commit som en och samma förtroendedomän. Inloggningsuppgifter som plattformen känner till (inloggningar för Docker och npm, de vanliga filerna med inloggningsuppgifter) återställs mellan jobben, men verktygscacher och hämtade images ligger kvar på VM:en. Se Modellen för hostade runners för hela designen.

Dimensionera jobb för hostade runners

Varje ny VM kostar ungefär 40 sekunders uppstart innan ditt första steg, och ofta 60 sekunders väntan efter ditt sista. Ett jobb som gör 15 sekunders arbete håller därför en VM i ungefär två minuter. Alltså:

• Ge ett jobb en egen VM bara när arbetet tar ungefär 2 minuter eller mer. Kortare kontroller (lint, en liten testsvit, ett kontrollskript) blir billigare och snabbare som extra steg i ett befintligt jobb.
• Parallellisera långt, oberoende arbete (testshards, image-byggen, end-to-end-sviter) över flera jobb. Det är det samtidigheten är till för.
• Parallellisera kort arbete inom ett jobb i stället för över flera jobb, till exempel flera tofu plan-körningar i bakgrundsprocesser i ett och samma steg. De väntar mest på API:er, inte på CPU.
• Kedjor återanvänder VM:ar automatiskt. Ett needs:-jobb som blir redo medan föregångarens VM fortfarande väntar (inom 60 sekunder) körs på den VM:en utan uppstart. En bred utgrening av jobb som alla startar samtidigt kan inte återanvända något: vart och ett behöver en egen VM.
• Håll en körning inom din samtidighet. En matris som är bredare än organisationens garanterade andel körs i vågor, och den sista vågen väntar på att ett helt jobb ska bli klart. Dimensionera dina shards så att en körning ryms i en våg.

Minne

En VM för hostade runners har 4 GiB minne och ingen swap (2 vCPU). Det finns i dag ingen större storlek på hostade runners.

Ett jobb som får slut på minne misslyckas inom ungefär en minut. När tillgängligt minne sjunker under ungefär 4 % (cirka 130 MiB) stoppar runnern jobbets största process, och väljer helst byggverktyg som node, tsc, java och vitest-workers. Den skickar SIGTERM först och SIGKILL om minnet fortsätter att sjunka. Steget misslyckas med slutkod 143 eller 137, och stegets logg förklarar varför:

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

Runnern själv är aldrig den process som stoppas, så jobbets resultat och loggar rapporteras ändå. Före den här ändringen kunde ett jobb som växte ur VM:en hänga tyst tills dess timeout-minutes löpte ut.

Om du ser den raden, minska jobbets minnestopp:

• Dela upp arbetet på flera jobb. Ett stort bygge bredvid sina integrationstester, eller en docker build bredvid testcontainrar, lägger ihop de två topparna på en och samma VM.
• Begränsa verktygets minne. Till exempel NODE_OPTIONS=--max-old-space-size=2048 för Node, --checkers 1 och GOMEMLIMIT för TypeScript 7 (tsc skrivet i Go), -Xmx för Java, färre test-workers (--maxWorkers / --pool-options).
• Strömma i stället för att läsa in allt. För skanning av stora images, se Skanna stora images med Trivy.

Om ett jobb inte ryms i 4 GiB, kontakta support@frem.sh eller kör det på en egen runner som är dimensionerad för det.

Inkluderade minuter och samtidighet

Jobb över organisationens gräns väntar i kön i stället för att misslyckas. Kontakta support@frem.sh om du behöver en högre garanterad andel.

Debitering av överförbrukning (frivillig): som standard köas nya jobb när poolen är slut. Organisationens ägare kan slå på mätt överförbrukning under Organisationens administration → Fakturering → Förbrukning av runner-minuter. När det är påslaget debiteras minuter utöver poolen med 0,01 €/min på nästa faktura. Överförbrukning kan stängas av när som helst på samma sida.

Användningsöversikt

Följ förbrukningen av runner-minuter under Organisationens administration → Fakturering → Förbrukning av runner-minuter.

Översikten visar:

Minuter räknas från jobbets start till dess slut, avrundat uppåt till närmaste sekund. Kötid (väntan på en runner) räknas inte.

Månadsperioden nollställs den 1:a varje månad (UTC). Oanvända minuter förs inte över.

Minuter på egna runners följs separat i samma översikt och räknas inte mot den hostade poolen.

Varningsgränser som kunden själv kan ställa in finns inte i gränssnittet ännu. fremforge skickar en standardvarning per mejl när organisationen når 80 % av månadspoolen. Kontakta support@frem.sh om du vill ändra gränsen.

Innehållet i runner-imagen

Imagen för hostade runners byggs om varje vecka (måndag 06:00 UTC) från de verktygsversioner uppströms som Renovate följer. Varje nedladdning vid byggtid är låst med sha256 (bygget misslyckas vid avvikelse). En Trivy-kontroll av CVE:er körs vid byggtid: en image med fynd av typen HIGH eller CRITICAL stoppas från leverans tills den är åtgärdad.

Innan en ombyggd image tas i bruk i runner-flottan kontrolleras den igen mot listorna över sårbarheter som utnyttjas aktivt (ENISA EUVD och CISA KEV). En image med en aktivt utnyttjad CVE som har en tillgänglig rättning rullas inte ut, oavsett allvarlighetsgrad, om inte ett granskat undantag på högst 30 dagar täcker den CVE:n. Runners fortsätter använda den föregående imagen tills en åtgärdad image har byggts.

Tvålagersmodell, båda lagren lagrade i EU:

• Systemlagret (~300 MB): Debian-bas plus systemverktyg i en version vardera (Node 24 LTS, byggverktyg, skannrar, IaC- och moln-CLI:er, webbläsare, databasklienter). Ingår i VM:ens startdisk; ingen nedladdning per jobb.
• hostedtoolcache-lagret (~7 GB): språkverktygskedjor i flera versioner (Node, Go, Python, .NET, Java, Ruby) samt Android SDK, Miniconda3 och R (sedan 2026-06-06). Inbakat på samma startdisk i /opt/hostedtoolcache. setup-*-actions hämtar härifrån utan nedladdning per jobb.

Hur vi ger full täckning på ~7 GB totalt när GitHubs ubuntu-latest är ~50 GB: se storleksjämförelsen nedan.

Förinstallerat i systemlagret:

Förinstallerat i hostedtoolcache (hämtas av setup-*-actions, ingen nedladdning per jobb):

Den kanoniska versionslistan, med exakta versioner, image-digest, sammanfattning av Trivy-skanningen och en CycloneDX-SBOM, publiceras med varje veckovis ombyggnad. Se referensen för runner-imagen för den aktuella verktygsuppsättningen.

Containerbyggen: inbyggd Docker eller kaniko

Två vägar; välj efter arbetslast:

Inbyggd Docker (standard): VM:en levereras med Docker-daemonen installerad och igång på värden. Din docker-CLI pratar med den över den vanliga lokala socketen, utan omväg via DOCKER_HOST och utan sidecar. Fungerar för docker build, docker compose, docker pull, flerstegsbyggen och BuildKit-funktioner. Direkt ersättning för docker på runners hostade av GitHub.

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

Skanna stora images med Trivy

trivy image <ref> (via daemonen) håller lagermetadata för hela imagen i minnet medan den går igenom filsystemet. Images på flera GB kan då gå långt över runner-VM:ens minnesgräns och utlösa en OOM-kill mitt i skanningen. Det pålitliga mönstret för alla image-storlekar är att strömma imagen 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 -

Varför det fungerar: docker save läser lagren från disk och strömmar tar-arkivet till trivys stdin ett lager i taget. Trivy tolkar varje lager för metadata om OS-paket (några tiotal KB per lager) och släpper det före nästa. Den sammanlagda toppen av RSS ligger kring 500 MB oavsett imagens totala storlek, så skanningen ryms med god marginal i runner-VM:ens minnesbudget. GOGC=10 framför trivy (t.ex. GOGC=10 trivy ...) stramar åt heapen ytterligare om du någon gång kommer nära gränsen.

Filtret tr '\r' '\n' på docker push rekommenderas: Docker skriver förloppet för lageruppladdningen med vagnreturer som skriver över raden, och stegloggen i Forgejo Actions behandlar det som en enda rad som växer hela tiden och kortas av utan förvarning. Utan filtret visar en push som hänger eller misslyckas mitt i uppladdningen bara <layer>: Preparing i loggen, utan några detaljer om felet; när steget når sin tidsgräns har det egentliga felet redan skrivits över. Med tr blir varje förloppssteg en egen rad som fångas intakt, och grep -vE '^(Waiting|)$' tar bort tomma rader och vänteutfyllnad. Genomströmningen vid push av lager påverkas inte.

Kundens register (ghcr.io, dockerhub, quay.io, dina egna) nås via runnerns utgående trafik; proxyn har en tidsgräns på 30 min per förfrågan så att PUT av lager på flera GB slutförs utan problem. Budget för image-storlek: 50 GB per bygge (gränsen för VM:ens arbetsdisk). Skicka in ett ärende om du behöver mer.

kaniko: daemonlös OCI-byggare utan root. Snabbare kallstart än den fullständiga Docker-daemonen och bättre beteende för lagercache mot fjärrregister. Använd den när bygget inte behöver BuildKit-specifika funktioner.

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

För arbetslaster med kind eller testcontainers som behöver nästlade KVM-gäster lägger du till etiketten dind-privileged i runs-on. fremforge skickar dem till en VM-typ med nästlad virtualisering påslagen.

Storleken jämfört med GitHubs hostade runners

GitHubs ubuntu-latest är ~50 GB eftersom den bakar in:

• Flera versioner per språk: de 3 senaste serierna för Node, Python, Java och Ruby, och 2 för Go och .NET (~3 GB totalt). Tabellen ovan är den auktoritativa uppsättningen.
• Android SDK + NDK (~10 GB på GitHubs runners). Vi bakar in kärn-SDK:n (platform 34 + build-tools + platform-tools, ~3 GB); fler API-nivåer, NDK och emulatorer installeras per jobb via setup-android@v3 (det som redan är inbakat laddas inte ned igen).
• Förhämtade Docker-images för tjänstecontainrar (postgres, mysql, mongo, redis, mssql, ~5 GB). Inte inbakade; en docker pull hämtar dem från Docker Hub, eller via organisationens beroendeproxy (se paketcacher).
• Webbläsaren Microsoft Edge. Inte inbakad (Chromium är samma motor för headless-tester i CI).
• Mono / Julia / Swift / Haskell / Lua / Crystal / Nim / Elixir. Inte inbakade (nischade; installeras per jobb via setup-* eller apt).
• Flera GCC-versioner och gamla verktygskedjor som behålls för kompatibilitet. Vi levererar en aktuell uppsättning.

Vi saknar inte de verktyg som ett typiskt arbetsflöde använder: alla vanliga språk, alla stora moln-CLI:er, alla vanliga skannrar, båda de stora webbläsarna, Docker (inbyggd, root via etiketten dind-privileged), Android (kärn-SDK) och datavetenskap (Miniconda3 + R). iOS/Xcode fungerar inte på Linux och följs separat; nischade språk (Julia/Swift/Haskell/Mono) installeras per jobb. Hör av dig om ditt team behöver något vi inte bakar in, så utvärderar vi det inför nästa veckovisa ombyggnad av imagen.

Fullständiga detaljer per verktyg finns på docs.frem.sh/build/actions/runner-image/.

Egna runners (BYO)

Registrera dina egna runners mot valfri fremforge-organisation (on-prem-servrar, moln-VM:ar, Mac mini, Raspberry Pi). Minuter på egna runners räknas inte mot den hostade poolen.

Registrering

1. Gå i organisationens Forgejo-inställningar till Inställningar → Actions → Körare → Skapa ny körare (frem.sh/org/<org>/settings/actions/runners).
2. Kopiera registreringstoken.
3. Ladda ned binären för Forgejo runner. Den aktuella stabila versionen publiceras på code.forgejo.org/forgejo/runner/releases; lås till en nyligen släppt tagg när du installerar:

# 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öljer aktuella Forgejo-versioner; runners med äldre binärer fortsätter att fungera men bör uppgraderas inom en releasecykel för att få med CVE-rättningar.

4. Registrera runnern:

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

5. Starta runnern:

./forgejo-runner daemon

Plattformar som stöds

Egna etiketter

Etiketterna som tilldelas vid registreringen är det du anger i runs-on::

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

Flera etiketter i en lista betyder “hitta en runner som har ALLA dessa etiketter”. Etiketten self-hosted är konvention. Ta med den så att ett jobb för en egen runner inte av misstag hamnar på en hostad runner.

Använd inte reserverade etiketter. Etiketterna fremforge och linux/amd64 går till vår pool av hostade runners (de äldre aliasen fremforge-cci och cci är utfasade och skickas samma väg). Välj egna etiketter för dina runners (t.ex. self-hosted, on-prem, my-team-runner) så att arbetsflöden kan peka ut dem entydigt.

Nätverkskrav för runner-värden

Runner-binären öppnar HTTPS-anslutningar med long-poll mot https://frem.sh och klonar repon över HTTPS. Sett från värden är kraven på anslutning:

Ingen inkommande anslutning behövs: runnern initierar alla anslutningar utåt. En runner bakom NAT eller en brandvägg fungerar utmärkt så länge den når frem.sh:443.

Ansvar för säkerhet och isolering

För hostade runners ger fremforge isolering på kärnnivå mellan commits och mellan kunder (varje commit körs på en ny kortlivad ECS-VM; jobb från samma commit kan dela den). För egna runners är isoleringen ditt ansvar. En egen runner som hanterar arbetsflöden från flera repon delar tillstånd mellan jobben, om du inte begränsar varje runner till ett enda repo eller en enda organisation.

Om du kör arbetsflöden från flera team eller förtroendedomäner, behandla din egen runner på samma sätt som egna runners i GitHub Actions behandlas:

• En runner per repo (eller per förtroendegräns) när secrets är känsliga.
• Registrera inte en egen runner mot ett offentligt repo: den som har rätt att göra merge kan få in en ändring i ett arbetsflöde som kör godtycklig kod på din runner-värd.
• Behandla runner-värden som produktion: härda operativsystemet, håll runner-binären uppdaterad och led dess utgående trafik genom dina egna kontroller för SSRF och utgående trafik.

fremforges utgående SSRF-proxy gäller INTE egna runners, bara hostade runners. Din runners nätverkspolicy är det du själv konfigurerar på värden.

Utgående trafik och nätverk

Tillåtelselista för utgående trafik på organisationsnivå: kontakta support@frem.sh för att tillåta utgående åtkomst till fler CIDR-block eller portar från runner-jobb. Reglerna för utgående trafik konfigureras på plattformsnivå.

SSRF-proxyn är ett golv i plattformen. Den kan inte stängas av. Den hindrar runner-jobb från att nå instansmetadata i T Cloud Public eller intern infrastruktur.

Secrets i jobb

Secrets skickas in som miljövariabler och maskeras i jobbens loggar. Varje loggrad som innehåller värdet av en secret ersätts med ***.

Syntax:

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

Omfång för secrets

Secrets för en miljö kräver att jobbet anger en miljö:

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

För inloggningsuppgifter hos molnleverantörer bör du välja OIDC-tokenfederation framför långlivade secrets. Då finns det ingen secret att lagra och ingen secret att rotera.

Felsökning

Ett steg misslyckas med earlyoom: killed <process> ... ran out of memory.

Jobbet använde mer än runner-VM:ens 4 GiB minne, så runnern stoppade dess största process i stället för att låta VM:en hänga sig. Se Minne för hur du minskar jobbets minnestopp.

Jobbet fastnar i kön.

Den vanligaste orsaken är att organisationen har nått taket för samtidighet (2 samtidiga jobb per användare garanteras, minst 10 och högst 60; se Inkluderade minuter och samtidighet). Kontrollera antalet aktiva jobb under Organisationens administration → Fakturering → Förbrukning av runner-minuter. Om du ligger vid taket, vänta tills ett pågående jobb är klart eller kontakta support@frem.sh för en höjning via Enterprise-on-Demand.

Kommandot docker fungerar men en privilegierad åtgärd misslyckas (t.ex. att skapa ett kind-kluster med nästlad KVM).

Standard-VM:en för runs-on: fremforge kör Docker direkt med standardinställningar för användare utan root. docker build / docker compose / docker pull fungerar direkt, men åtgärder som kräver extra behörigheter (nästlad KVM, direkt åtkomst till /dev för en nästlad gäst, vissa nätverkslägen för kind-kluster) gör det inte. Lägg till etiketten dind-privileged i runs-on (runs-on: [fremforge, dind-privileged]), så skickar fremforge jobbet till en VM-typ med nästlad virtualisering påslagen. Samma isolering med en VM per commit, samma image, bara utökade behörigheter.

För att bara kopiera eller tagga om images mellan register (utan bygge) fungerar det förinstallerade skopeo helt utan Docker-daemonen.

En secret maskeras i loggarna men steget beter sig som om den vore tom.

Secreten finns i körmiljön (maskeringen bekräftar det), men värdet är inte satt i rätt omfång. Kontrollera:

1. Är secreten satt på organisationsnivå, repo-nivå eller miljönivå?
2. Om det är en secret för en miljö, anger jobbet environment: <name> som matchar secretens miljö?
3. Är namnet på secreten stavat exakt rätt (skiftlägeskänsligt)?

Secrets-gränssnittet för respektive omfång visar namnet på secreten och när den senast uppdaterades. Använd det för att bekräfta att secreten finns innan du granskar arbetsflödet.

Korsreferenser

• OIDC-tokenfederation: nyckelfri molnautentisering från CI-jobb
• Secrets: hantera secrets för organisation, repo och miljö
• Kompatibilitet med Marketplace: vilka actions från GitHub Marketplace som fungerar på fremforges runners
• AI-hållning: vilka AI-verktyg som finns och inte finns i runner-miljön