Öppen källkod för DevOps i stor skala: kör GitLab själv

Källkoden är den tillgång som nästan alla teknikföretag är överens om är kritisk, och samtidigt den som de flesta förvarar på infrastruktur de inte äger, i en jurisdiktion de inte har valt, enligt ett avtal de inte läst särskilt noga. Oftast fungerar det bra. Men det är värt att veta vad alternativet kostar, eftersom GitLab i över tio år har gjort det fullt realistiskt att själv driva hela utvecklingskedjan.

Det är också en produkt där gratisnivån är generösare, och driften tyngre, än de flesta räknar med. Båda sakerna är värda att förstå innan du bestämmer dig. Den här guiden går därför igenom vad GitLab self-managed faktiskt är, vad gratisnivån verkligen ger dig och de tre driftproblem som står för det mesta av besväret.

Vad GitLab är

Inte en Git-tjänst med tillägg som skruvats på i efterhand. Det är en Rails-applikation, PostgreSQL, Redis, Gitaly för lagring av repon, Sidekiq för bakgrundsjobb och ett containerregister, paketerade som ett enda system för versionshantering, kodgranskning, ärendehantering, CI/CD, paket- och containerregister, säkerhetsskanning och driftsättning.

Den bredden är hela poängen. GitHub plus Actions plus Dependabot plus ett paketregister plus ett projektverktyg ger en jämförbar funktionsuppsättning, men ihopsatt av delar. GitLab är en applikation med en behörighetsmodell och en databas. Det är antingen precis vad du vill ha eller mer än du behöver, och vilket det blir beror på hur stor del av utvecklingskedjan du faktiskt tänker samla på ett ställe.

Det viktiga arkitektoniska faktumet är detsamma som när du driver din webbanalys själv med Matomo, din marknadsautomation med Mautic eller din teamchatt med Mattermost: systemet körs där du placerar det. Dina repon, dina CI-loggar, dina artefakter, din databas.

Licenserna, rakt på sak

Det här är verkligen förvirrande och värt att vara noggrann med, eftersom förvirringen går åt motsatt håll mot vad folk tror.

Det finns två källkodsdistributioner. Community Edition har MIT-licens. Enterprise Edition har en egen, mer restriktiv licens som gäller katalogen ee/ i repot. Så långt låter det som den vanliga open core-modellen.

Det som överraskar många: Linux-paketet som nästan alla installerar är Enterprise Edition-bygget, och utan licensnyckel körs det som Free-nivån och beter sig som Community Edition. Du kör alltså inte den MIT-licensierade distributionen om du inte medvetet har valt CE-paketet. I praktiken spelar det sällan roll. Men om skälet till att du driver GitLab själv är en strikt policy för öppen källkod snarare än kontroll över data, spelar det stor roll, och nästan ingen kontrollerar det.

De kommersiella nivåerna är Free, Premium för 29 dollar per användare och månad med årsfakturering, och Ultimate med offertbaserat pris. Premium lägger till avancerad CI/CD, bättre projektstyrning och prioriterad support. Ultimate lägger till säkerhets- och compliancepaketet: säkerhetstester av applikationer, säkerhet i leveranskedjan och beroendeskanning. Båda betalnivåerna ingår i dag med GitLab Credits för AI-funktionerna, 12 dollar per användare och månad på Premium och 24 på Ultimate. GitLabs prissida kallar dessa inkluderade krediter ett tidsbegränsat kampanjerbjudande som GitLab kan ändra efter eget gottfinnande.

Här är faktumet som ändrar kalkylen för de flesta team, och som är raka motsatsen till hur det ser ut med Mattermost: Free-nivån i self-managed har ingen gräns för antalet användare. Taket på fem användare som många har hört talas om gäller bara privata grupper på GitLab.com. Free i egen drift ger dig obegränsat antal användare, versionshantering, CI/CD och register, och du står själv för lagring och runners. En organisation med hundra utvecklare kan köra helt på den.

Det du avstår från är säkerhetsskanning, compliancerapportering, avancerade godkännanderegler och support. Om du omfattas av Cyber Resilience Act och vill ha beroendeskanning och SBOM-generering inbyggt i dina pipelines, i stället för ihopsatt av separata verktyg, är det ett samtal om Ultimate. För de flesta andra team är Free ingen provperiod. Det är en hållbar permanent lösning.

Så sätter du upp det

En liten installation

GitLab är tyngre än det ser ut. Den dokumenterade baslinjen för en enda nod är 8 vCPU och 16 GB RAM, och till skillnad från de flesta leverantörers minimikrav är den siffran ärlig snarare än optimistisk. Det går att klämma in på 8 GB, men du kommer att märka det, och swap bör vara avstängt eftersom det är värre att den här applikationen swappar än att minnet saknas.

PostgreSQL är den enda databas som stöds. Vilken version beror på din GitLab-version: 17.x vill ha PostgreSQL 14.14 till 16.x, 18.x vill ha 16.5 till 17.x och 19.x vill ha 17.x till 18.x. Redis 7.2 rekommenderas och 7.0 är minimum, och Valkey 7.2 fungerar som ersättning. Bara fristående instanser, eftersom klustrade och serverlösa varianter av Redis inte stöds.

Installera med Linux-paketet. Det finns Helm-diagram, en Operator, Docker-avbilder och en väg via källkoden, men Linux-paketet är det mest mogna alternativet och det är vad GitLab.com själv körs på. Det paketerar PostgreSQL, Redis och Sidekiq, så en maskin och en konfigurationsfil ger dig en fungerande instans.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

Kör gitlab-ctl reconfigure så har du en instans. Sätt external_url rätt från början, eftersom värdet bakas in i klon-URL:er, webhooks och registeradresser.

En produktionsinstallation

GitLab publicerar referensarkitekturer för 1 000 till 50 000 användare. De är värda att läsa även om du aldrig bygger någon av dem, eftersom de visar vilken komponent som blir flaskhals först.

Det råd som sparar mest pengar kommer från GitLab själva, och det talar emot komplexitet: under 3 000 användare rekommenderar de en gedigen backupstrategi framför hög tillgänglighet. Dokumentationen är ovanligt öppen med det och konstaterar att backupvägen ”does have a slower recovery time” men ”means you have a much smaller architecture and less maintenance costs.” Över 3 000 användare, eller där ett avbrott verkligen stoppar hela företaget, blir hög tillgänglighet rekommendationen.

Ta det på allvar. En enda nod med bra backup och en testad återställning är i praktiken mer pålitlig än ett halvförstått HA-kluster, och betydligt billigare.

Flytta artefakter, uppladdningar, LFS-objekt och registeravbilder till objektlagring från början. Samma resonemang som överallt annars: noden förblir tillståndslös, backuperna hanterbara och en migrering möjlig.

De tre saker som går fel

Allt ovan finns i dokumentationen. Det här är det som leder till incidenter.

Din backup innehåller inte det som dekrypterar den

Det här är det viktigaste stycket i hela artikeln.

gitlab-backup create fångar mycket: databasen, repon, LFS-objekt, CI-artefakter och jobbloggar, registeravbilder, wikis, uppladdningar, Pages-innehåll, Terraform-tillstånd och snippets. Det den inte fångar är konfigurationskatalogen, och i synnerhet /etc/gitlab/gitlab-secrets.json.

Den filen innehåller databasens krypteringsnyckel. Dokumentationen är rak om följden: ”If you lose it, then the GitLab application will not be able to decrypt any encrypted values in the database.” Det gäller CI/CD-variabler, tokens, hemligheter för tvåfaktorsautentisering och inloggningsuppgifter för integrationer. Du får en backup som återställs till en instans som inte kan läsa sina egna hemligheter.

Inte heller med: /etc/gitlab/gitlab.rb, TLS-nycklar och certifikat, SSH-värdnycklar och innehållet i objektlagringen när sådan är konfigurerad. Det sista drabbar dem som gjorde rätt arkitektoniskt och sedan utgick från att backupen täckte det.

Säkerhetskopiera alltså /etc/gitlab separat och förvara den någon annanstans än tillsammans med arkivet, eftersom den är nyckeln till arkivet. Återställ sedan alltihop på en testmaskin och kontrollera att du kan logga in och läsa en CI-variabel. En otestad återställning är ingen backup, och i GitLabs fall är en otestad återställning oftast en trasig.

Du kan inte uppgradera i ett enda hopp

GitLab har obligatoriska uppgraderingsstopp, och de är inga rekommendationer. Du kan inte hoppa över dem. Sedan 17.5 är stoppen förutsägbara och ligger på x.2, x.5, x.8 och x.11. Att uppgradera från 18.0 till 19.2 innebär alltså att du först stannar vid 18.2, 18.5, 18.8 och 18.11. 19.0 är inget stopp, så från 18.11 går du direkt till 19.2.

Varje stopp innehåller bakgrundsmigreringar som måste vara helt klara innan du går vidare till nästa. Att starta nästa uppgradering medan migreringarna fortfarande körs är just så instanser hamnar i lägen som kräver support för att redas ut. På en stor instans kan migreringarna ta timmar.

Två praktiska följder. Uppgradera regelbundet, eftersom ett år av uppskjutna uppgraderingar blir en helg av uppgraderingar i följd. Och ta alltid den senaste patchversionen av en målversion i stället för den första, vilket dokumentationen uttryckligen säger. GitLab har ett verktyg för uppgraderingsvägar som räknar ut sekvensen åt dig, och det är värt att använda i stället för att resonera fram den själv.

Det är runners som kostar på riktigt

GitLab-servern kör inte din CI. GitLab Runner är en separat komponent som du installerar, konfigurerar och betalar för, på infrastruktur som du står för. Self-managed Free innehåller inga beräkningsminuter alls, eftersom det inte finns någon inkluderad beräkningskapacitet att ge: du tar med dina egna maskiner.

Oftast är det en bra affär, eftersom en dedikerad runner är billigare per minut än hostad CI vid varje seriös volym, och du kan koppla in den hårdvara ett bygge behöver. Men det är riktigt infrastrukturarbete. Du kommer att fatta beslut om executors (shell, Docker eller Kubernetes), om autoskalning så att runners inte står och väntar klockan tre på natten, och om cachning, som är skillnaden mellan en pipeline på fyra minuter och en på fjorton.

Budgetera runnerflottan som en egen post. Team som räknar på kostnaden för egen drift genom att bara titta på GitLab-noden underskattar den rejält och upptäcker sedan underskottet som en kö av väntande jobb.

Flytta från GitHub

GitHub-importen är bra, betydligt bättre än de flesta leverantörers migreringsverktyg. Den tar med repodata, grenar, LFS-objekt, ärenden och pull requests med kommentarer, granskningar och diskussionssvar, wikisidor, releaser och bilagor, etiketter, milstolpar, regler för grenskydd och medarbetare med rollmappning.

De dokumenterade luckorna är värda att planera för. Organisationer och grupper följer inte med, så gruppstrukturen är din att utforma snarare än att ärva, vilket oftast är en förbättring. GitHub Actions-arbetsflöden konverteras inte till GitLab CI. Kommentarer på pull requests från före 2017 importeras som separata trådar på grund av begränsningar i GitHubs API, och repon med fler än ungefär 30 000 kommentarer kräver att den alternativa importmetoden för kommentarer aktiveras.

Eftersom GitHub använder # för både ärenden och pull requests medan GitLab skiljer på dem, kommer vissa korsreferenser inte att lösas upp. Inget går förlorat, men länkar i gamla diskussioner kan peka på fel sak.

Planera omskrivningen av CI som det egentliga projektet, för det är vad det är. Allt annat är ett importjobb som du kan köra och kontrollera.

Det europeiska perspektivet

För företag som verkar i Europa finns en compliancedimension utöver kostnaden. Källkod, byggpipelines och artefakter hör till det känsligaste ett teknikföretag har, och var de finns blir allt oftare en fråga du får snarare än en du själv väljer att besvara.

Egen drift placerar dem innanför en gräns som du kontrollerar. Det förenklar i ett enda steg analysen av överföringar enligt dataskyddsförordningen (GDPR) och frågorna om leveranskedjan enligt NIS2, och det är samma suveränitetsargument som Cloud and AI Development Act bygger på.

Den tydligaste kopplingen är Cyber Resilience Act. Om du levererar programvara till EU-marknaden kommer du att behöva förteckningar över beroenden, hantering av sårbarheter och en process för samordnad rapportering av sårbarheter. De skyldigheterna uppfylls i din byggpipeline snarare än i ett dokument, och om pipelinen, registret och skanningen finns i ett och samma system som du driver blir det betydligt mindre smärtsamt att ta fram underlaget än att pussla ihop det från fyra leverantörer.

När det inte är värt besväret

Om ni är färre än tjugo utvecklare, utan regulatoriskt tryck och utan starka åsikter om var koden ligger: använd SaaS-tjänsten. GitLab.com och GitHub är båda utmärkta, och driftarbetet kommer att kosta mer än prenumerationen.

Om din organisation sitter djupt inne i GitHubs ekosystem, räkna ärligt på vad du skulle förlora. Actions, marketplace och att varje kandidat du anställer redan kan plattformen är verkliga tillgångar, och svaret är inte automatiskt att GitLab vinner.

Och om ingen kommer att äga instansen: börja inte. GitLab belönar en ägare som patchar, håller koll på runnerflottan och testar återställningen. Utan den personen förfaller den till en opatchad server som rymmer din mest värdefulla tillgång, vilket är sämre än den SaaS-tjänst du försökte lämna.

Få hjälp

Vi driftsätter och driver utvecklingsinfrastruktur i egen regi för företag som verkar i Europa, inklusive de delar ingen tycker är roliga: uppgraderingssekvenser genom obligatoriska stopp, runnerflottor som autoskalar ordentligt, migreringar till objektlagring och backuplösningar som faktiskt har återställts.

Om du vill ha en GitLab-instans som är ärligt dimensionerad, en GitHub-migrering planerad av någon som har skrivit om CI förut, eller en genomgång av om din nuvarande backup skulle klara ett verkligt fel, skriv till office@c9group.dev. Mer om vårt infrastrukturarbete finns på sidan om kostnadsoptimering i AWS.

Om du bygger upp en hel stack i egen drift gäller samma resonemang för webbanalys, marknadsautomation och teammeddelanden.

---

Publicerad: 8 augusti 2026 · Uppdaterad: 10 oktober 2026 Kategorier: DevOps, Öppen källkod, Integritet