Tabby: Selvhostet AI-kodeassistent i 12 Trin [2026]

Hver gang en udvikler trykker Tab i sin editor og får et kodeforslag fra GitHub Copilot eller Cursor, sendes et udsnit af koden til en sky-server i USA. For danske virksomheder med kunde- eller sundhedsdata er det ofte et problem, som IT-sikkerhedschefen ikke kan skrive under på. Løsningen er ikke at droppe AI-kodeassistance, men at hoste den selv. Tabby (TabbyML) er et open source-projekt under Apache 2.0-licensen, der gør præcis det: en komplet AI-kodeassistent, der kører på dit eget hardware, uden at en eneste kodelinje forlader dit netværk.

I denne guide sætter vi Tabby op fra bunden med Docker, kobler den til en lokal kodemodel, integrerer den med VS Code og JetBrains, og gennemgår de faldgruber, der typisk vælter et selvhostet AI-projekt. Du får et komplet, fungerende setup, ikke bare en overordnet introduktion. Vil du se flere sammenligninger og opsætningsguider til AI-drevne udviklerværktøjer, kan du også besøge vores samlede oversigt over software og udviklerværktøjer.

Hvad er Tabby, og hvorfor selvhoste sin AI-kodeassistent?

Tabby er en selvhostet AI-kodeassistent, der leverer autofuldførelse og en chat-baseret assistent direkte i din editor, ligesom GitHub Copilot gør det. Forskellen er arkitekturen: hvor Copilot og Cursor sender kodekontekst til Microsoft eller Anthropic-drevne modeller i skyen, kører Tabby-serveren på din egen maskine eller i dit eget datacenter. Projektet er licenseret under Apache 2.0, hvilket betyder, at hele serveren kan hostes gratis, uden per-forespørgsel-gebyrer og uden brugsbegrænsninger. Den eneste omkostning er den hardware, du selv stiller til rådighed.

Ifølge TabbyMLs GitHub-repository ligger den seneste serverudgivelse på version 0.32.0, udgivet 25. januar 2026. Projektet har passeret 30.000 stjerner på GitHub, med en optælling på 33.052 stjerner registreret i en tredjeparts-oversigt over GitHub-repositories i marts 2026. Det placerer Tabby blandt de mest populære open source-projekter inden for AI-kodeassistance, og det er en tydelig indikation af, at interessen for selvhostede alternativer til Copilot vokser i takt med, at flere virksomheder strammer deres datapolitikker.

Baggrunden for den stigende interesse er ikke svær at forstå. Danske og nordiske virksomheder i finans, sundhed og den offentlige sektor arbejder under GDPR, og mange har interne retningslinjer om, at kildekode og forretningslogik ikke må sendes til amerikanske skytjenester uden en databehandleraftale på plads. Når en udvikler bruger en sky-baseret assistent, sendes typisk hele filen eller store dele af den som kontekst til modellen, hver gang der bedes om et forslag. For et selskab med proprietær prisberegning, kundedata i kommentarer eller interne API-nøgler i konfigurationsfiler er det en reel risiko, uanset hvor gode leverandørens databehandleraftaler er på papiret. Tabby fjerner den diskussion helt, fordi modellen kører lokalt, og fordi projektet er transparent om, at kerneserveren ikke foretager eksterne kald til tredjeparter, når den er sat op med en lokal model.

Det gør ikke Tabby til det rigtige valg for alle. Er I et lille team på tre udviklere uden særlige compliance-krav, er den administrative byrde ved at drifte egen GPU-server sandsynligvis større end gevinsten, og et abonnementsbaseret alternativ som vores gennemgang af Tabnine-opsætning kan være hurtigere at komme i gang med. Til gengæld er selvhosting oplagt for virksomheder med mere end 10-15 udviklere, hvor den samlede licensomkostning til Copilot Business eller Cursor Team allerede løber op, og hvor en enkelt server med en solid GPU hurtigt betaler sig selv hjem.

Tabby adskiller sig fra Continue.dev, som primært er en editor-udvidelse, der peger på eksterne eller lokale modelendepunkter, uden selv at levere en fuld multi-bruger-server. Tabby leverer derimod hele stakken: model-serving, indeksering af kodebaser, brugerstyring og et administrationspanel, alt sammen pakket i et enkelt Docker-image. Det gør Tabby til det oplagte valg, hvis målet er en samlet, virksomhedsklar løsning frem for et løst sammensat sæt af værktøjer.

Forudsætninger: dette skal du bruge, før du starter

Før du går i gang, skal du sikre dig, at din maskine eller server lever op til minimumskravene. Tabby kan køre på ren CPU, men for en brugbar oplevelse med kodeforslag i realtid anbefales en GPU. Her er de præcise versioner og krav, du skal have styr på.

• Docker Engine version 24 eller nyere, samt Docker Compose v2 (indbygget i moderne Docker-installationer)
• Operativsystem: Ubuntu 22.04/24.04 LTS, Debian 12, eller enhver Linux-distribution med kernel 5.x+. Tabby kan også køre på Windows via WSL2 og på macOS med Docker Desktop
• RAM: minimum 8 GB, anbefalet 16 GB til en model som DeepSeek-Coder-6.7B eller StarCoder2-7B
• Diskplads: minimum 20 GB, anbefalet 50 GB til modelvægte, indekser og logs
• GPU (valgfrit, men anbefalet): en Nvidia GPU med CUDA 12.8 eller nyere. En RTX 3060 med 12 GB VRAM dækker mindre modeller, mens en RTX 3080 med 10 GB+ eller nyere giver markant hurtigere svartider
• NVIDIA Container Toolkit, hvis du vil give Docker adgang til GPU’en
• Netværksadgang til at hente Docker-imaget tabbyml/tabby fra Docker Hub og modelvægte fra Hugging Face
• Grundlæggende kendskab til terminalen, YAML-syntaks og din valgte editor (VS Code eller en JetBrains-IDE)

Har du ikke en GPU til rådighed, kan du stadig følge denne guide. Tabby understøtter CPU-only inferens, men forvent markant længere svartider på autofuldførelse, typisk flere sekunder i stedet for millisekunder. Til test og mindre teams er det til at leve med, men til et helt udviklingsteam bør du investere i en dedikeret GPU-server.

Trin 1: Klargør serveren og installer Docker

Start med at sikre, at Docker og Docker Compose er installeret korrekt. Hvis du allerede har Docker kørende, kan du springe dette trin over.

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Foretrækker du en pakkebaseret installation frem for shell-scriptet, findes den fulde vejledning for hver distribution i Dockers officielle installationsdokumentation. Uanset metode er det vigtigt at bekræfte, at din bruger er tilføjet til docker-gruppen, så du undgår at skulle skrive sudo foran hver eneste kommando i resten af denne guide.

Hvis du har en Nvidia-GPU og vil bruge den til modelinferens, skal du også installere NVIDIA Container Toolkit, så Docker kan tildele GPU-ressourcer til containeren.

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Test at Docker kan se din GPU, før du går videre:

docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu22.04 nvidia-smi

Kommandoen skal vise din GPU-model, driverversion og hukommelsesforbrug. Ser du en fejl om manglende driver eller “unknown runtime”, er NVIDIA Container Toolkit ikke sat korrekt op, og du skal gennemgå trinnet igen, før du fortsætter til modelvalg. Trin-for-trin-installationen for hver Linux-distribution ligger i Nvidias officielle installationsguide til Container Toolkit, som også dækker Rootless Docker og Podman, hvis I bruger en af de opsætninger internt.

Trin 2: Vælg den rigtige kodemodel til din hardware

Tabby vedligeholder en officiel modelregistrering med understøttede modeller, hvor hver model har sit eget ID og licens. Ifølge Clore.ai’s driftsguide til Tabby afhænger valget primært af, hvor meget VRAM din GPU har, og hvor hurtigt du forventer svar. Tabellen herunder viser de mest brugte modeller i produktion sammen med deres omtrentlige VRAM-forbrug.

Model	Cirka VRAM	Hastighed	Bedst til
StarCoder2-1B	~3 GB	Hurtigst	Test og bærbare uden dedikeret GPU
StarCoder2-3B	~5 GB	Hurtig	Mindre teams, godkendt kvalitet
StarCoder2-7B	~8 GB	Middel	Standardvalg, høj kvalitet
DeepSeek-Coder-6.7B	~8 GB	Middel	Python, JavaScript og TypeScript
CodeLlama-7B	~8 GB	Middel	Generel kodning på tværs af sprog
StarCoder2-15B	~16 GB	Langsommere	Komplekse kodebaser, bedste kvalitet

For de fleste danske udviklingsteams er StarCoder2-7B eller DeepSeek-Coder-6.7B det rigtige startpunkt. Begge kræver omkring 8 GB VRAM, hvilket en RTX 3060 eller nyere håndterer uden problemer, og begge leverer kodeforslag, der ligger tæt på det, man er vant til fra Copilot på almindelige webudviklingssprog. Har du kun adgang til en mindre GPU eller kører helt uden GPU, så start med StarCoder2-1B eller 3B og opgrader senere, når du har målt den faktiske belastning.

Ønsker I i stedet en terminal-baseret, open source-tilgang til AI-kodning frem for en editor-integreret assistent, er vores guide til Aider AI-opsætning et godt supplement til at sammenligne arkitekturvalg. Det er værd at bemærke, at modelvalget ikke er permanent. Fordi Tabby indlæser modellen som en separat parameter til serve-kommandoen, kan I til enhver tid teste flere modeller mod hinanden i en testperiode og lade de faktiske udviklere afgøre, hvilken der giver de mest brugbare forslag i netop jeres kodebase. Nogle teams finder, at en mindre, hurtigere model med kortere svartid opleves som mere nyttig i det daglige end en stor model med højere kvalitet, men et halvt sekunds ventetid på hvert tastetryk.

Trin 3: Opret docker-compose.yml til Tabby-serveren

Opret en projektmappe og en Compose-fil, der definerer Tabby-containeren, model-valget og GPU-tildelingen.

mkdir -p ~/tabby-server/data
cd ~/tabby-server
nano docker-compose.yml

Indsæt følgende i filen:

services:
  tabby:
    image: tabbyml/tabby
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./data:/data
    command: serve --model StarCoder2-7B --chat-model StarCoder2-7B --device cuda
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Kører du uden GPU, fjerner du hele deploy-blokken og ændrer --device cuda til --device cpu. Gem filen, og start containeren:

docker compose up -d
docker compose logs -f tabby

Første opstart tager typisk mellem 5 og 15 minutter, fordi Tabby skal hente modelvægtene fra Hugging Face. Følg loggen indtil du ser en besked om, at serveren lytter på port 8080. Herefter kan du åbne http://din-server-ip:8080 i browseren og se Tabbys web-dashboard.

Trin 4: Opret admin-konto og hent din API-nøgle

Når dashboardet loader for første gang, bliver du bedt om at oprette en administrator-konto. Vælg en stærk adgangskode, da dette panel styrer adgang for hele teamet. Efter login finder du under “Settings” eller “Profile” en personlig adgangstoken, som du skal bruge, når du forbinder editoren til serveren i de næste trin. Kopiér token og gem den midlertidigt et sikkert sted, for eksempel i en password manager, ikke i en almindelig tekstfil på skrivebordet.

Under “Members” kan du invitere resten af teamet. Den gratis, selvhostede kerne har ingen brugergrænse, men TabbyMLs administrerede Community-tier er begrænset til 5 brugere, hvis I i stedet vælger den hostede løsning frem for at selvhoste.

Trin 5: Installer og konfigurer VS Code-udvidelsen

Åbn VS Code, gå til Extensions (Ctrl+Shift+X), og søg efter “Tabby”. Installer den officielle udvidelse fra TabbyML. Efter installation skal du pege udvidelsen mod din selvhostede server:

• Åbn Command Palette (Ctrl+Shift+P) og vælg “Tabby: Set Endpoint”
• Indtast serveradressen, for eksempel http://din-server-ip:8080
• Indsæt din personlige adgangstoken fra trin 4
• Genstart VS Code for at aktivere autofuldførelse og chat-panelet

Du kan bekræfte, at forbindelsen virker, ved at åbne en kodefil og begynde at skrive. Kodeforslag skal dukke op som gråt, gennemsigtigt tekst, som du accepterer med Tab-tasten, præcis som i Copilot. VS Code-udvidelsen understøtter også HTTP-proxy-konfiguration via miljøvariabler, hvis din organisation kører bag en firewall med en central proxy.

Trin 6: Installer JetBrains-plugin (IntelliJ, PyCharm, WebStorm)

Bruger dit team JetBrains-produkter som IntelliJ IDEA, PyCharm eller WebStorm, findes der et officielt IntelliJ Platform-plugin til Tabby. Installer det via Settings → Plugins → Marketplace, søg efter “Tabby”, og genstart IDE’en.

Efter genstart finder du Tabby-indstillingerne under Settings → Tools → Tabby. Her indtaster du samme serveradresse og token som i VS Code-opsætningen. Pluginet tilføjer en chat-visning i sidepanelet, hvor du kan stille spørgsmål om din kodebase, og det understøtter samme HTTP-proxy-indstillinger som VS Code-udvidelsen. Bemærk, at ældre versioner af pluginet har haft rapporterede fejl med, at IDE’en fryser under store redigeringer. Sørg for at opdatere til nyeste pluginversion via Marketplace, før du ruller det ud til et helt team.

Fordi pluginet bygger på IntelliJ Platform, kan det i praksis installeres i de fleste JetBrains-produkter, der understøtter platformens plugin-system, ikke kun IntelliJ IDEA. Tjek altid Marketplace-siden for det konkrete JetBrains-produkt, I bruger, for at bekræfte kompatibilitet med jeres version, før I ruller det ud bredt i teamet. For et team med blandede editor-præferencer betyder det typisk, at I kan vedligeholde én fælles serveradresse og konfiguration på tværs af hele udviklingsorganisationen, uanset hvilken JetBrains-editor den enkelte udvikler foretrækker. Foretrækker nogle i teamet en anden editor med indbyggede AI-agenter, kan vores Zed Editor-opsætning være relevant at kigge på som supplement, da Zed også kan kobles til eksterne modelendepunkter.

Trin 7: Indeksér din kodebase for kontekstbevidste svar

En af Tabbys stærkeste funktioner er repository-indeksering, som gør chat-assistenten i stand til at svare på spørgsmål om jeres faktiske kodebase, ikke kun generel kodningsviden. Fra web-dashboardet under “Repositories” tilføjer du dine Git-repositories:

# Fra dashboardet: Repositories -> Add Repository
# Indtast Git-URL, f.eks:
[email protected]:dit-firma/dit-repo.git

# Eller lokalt repository via volume mount i docker-compose.yml:
volumes:
  - ./data:/data
  - /sti/til/dit/repo:/repos/dit-repo:ro

Efter tilføjelse starter Tabby en baggrundsindeksering, der kan tage fra få minutter til flere timer afhængig af kodebasens størrelse. Du kan følge fremdriften under “Jobs” i dashboardet. Når indekseringen er færdig, kan du i chat-panelet stille spørgsmål som “hvor defineres brugerautentificering i dette repository”, og Tabby vil finde og citere de relevante filer.

Indekseringen genkører automatisk med jævne mellemrum, så nye commits bliver en del af den kontekst, chat-assistenten kan trække på. Har I meget store monorepos, kan det være en god idé at starte med at indeksere ét centralt repository frem for at kaste alle jeres repositories ind på én gang. Det giver jer mulighed for at følge, hvor lang tid en typisk indeksering tager på jeres hardware, før I skalerer op til hele kodebasen. Nogle teams vælger desuden at ekskludere genererede mapper som build-output, node_modules eller vendor-biblioteker fra indekseringen, både for at spare tid og for at undgå, at chat-svarene forurenes af tredjeparts-afhængigheder frem for jeres egen kode.

Trin 8: Sæt en Nginx reverse proxy op med HTTPS

Tabby-serveren lytter som standard på almindelig HTTP. Skal serveren tilgås af flere udviklere over internettet eller på tværs af kontorer, bør trafikken krypteres. Her sætter vi en Nginx reverse proxy op foran Tabby med et gratis Let’s Encrypt-certifikat.

sudo apt install -y nginx certbot python3-certbot-nginx

sudo tee /etc/nginx/sites-available/tabby <<'EOF'
server {
    listen 80;
    server_name tabby.dit-firma.dk;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
EOF

sudo ln -s /etc/nginx/sites-available/tabby /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d tabby.dit-firma.dk

Husk at ændre serveradressen i VS Code- og JetBrains-konfigurationen til https://tabby.dit-firma.dk, når certifikatet er sat op. WebSocket-headerne (Upgrade og Connection) er nødvendige, fordi chat-panelet streamer svar over en vedvarende forbindelse, ikke almindelige HTTP-kald.

Trin 9: Backup, opdatering og drift af Tabby-serveren

Alt Tabbys persistente data, brugerkonti, indekser og konfiguration, ligger i mappen, du monterede som /data i Compose-filen. En simpel backup-rutine er derfor at arkivere den mappe regelmæssigt.

# Backup
docker compose stop tabby
tar -czf tabby-backup-$(date +%Y%m%d).tar.gz ./data
docker compose start tabby

# Opdatering til nyeste version
docker compose pull
docker compose up -d
docker compose logs -f tabby

Sæt backup-kommandoen i en cron-opgave, der kører uden for arbejdstid, og opbevar arkiverne et andet sted end selve serveren, for eksempel i objektlagring eller på en separat backup-server. Ved opdatering bør du altid tage en frisk backup først, da nye versioner af og til ændrer databaseskemaet, og en fejlslagen migrering ellers kan koste jer indekserede repositories.

Skulle en opdatering gå galt, gendanner du simpelt fra jeres seneste arkiv:

# Gendan fra backup
docker compose stop tabby
rm -rf ./data
tar -xzf tabby-backup-20260901.tar.gz
docker compose start tabby

Har I i forvejen sat en CLI-baseret assistent op til automatiserede opgaver, kan det være nyttigt at sammenholde driftsrutinerne med vores OpenCode CLI-opsætning, da mange af backup- og opdateringsprincipperne går igen på tværs af selvhostede AI-værktøjer. Test altid gendannelsesprocessen mindst én gang, før I er afhængige af den i en reel krisesituation. Mange teams opdager først under et nedbrud, at deres backup-arkiver var korrupte eller ufuldstændige, fordi de aldrig blev afprøvet på forhånd. Sæt derfor en fast kvartalsvis rutine, hvor I genskaber Tabby-serveren fra et arkiv i et testmiljø og bekræfter, at både brugerkonti og indekserede repositories kommer med tilbage.

Trin 10: Skift eller opgradér model uden nedetid

Efterhånden som teamet bruger Tabby, vil I sandsynligvis ønske at teste en anden model, for eksempel skifte fra StarCoder2-7B til DeepSeek-Coder-6.7B for bedre Python-forslag. Rediger command-linjen i docker-compose.yml, og genstart containeren:

command: serve --model DeepSeek-Coder-6.7B --chat-model DeepSeek-Coder-6.7B --device cuda

docker compose up -d
docker compose logs -f tabby

Tabby henter automatisk den nye models vægte, hvis de ikke allerede findes i din data-mappe. Under selve modelskiftet vil autofuldførelse være utilgængelig i typisk 2-10 minutter, afhængigt af modelstørrelse og din internetforbindelse, så planlæg skiftet uden for kernearbejdstid, hvis I har et team, der er afhængige af værktøjet dagligt.

Trin 11: Sæt adgangsstyring og gruppepolitikker op

Skal Tabby bruges af mere end en håndfuld udviklere, bør du oprette grupper i dashboardet under "Members" og "Access Control", så du kan styre hvilke repositories den enkelte medarbejder kan indeksere og forespørge på. Dette er særligt relevant, hvis flere teams deler samme Tabby-server, men arbejder på adskilte, følsomme kodebaser. TabbyMLs eget salgsmateriale beskriver denne gruppestyring som en del af Enterprise-tilbuddet, men de grundlæggende adgangskontroller er tilgængelige i den åbne kildekode-server, du netop har sat op.

Trin 12: Test hele opsætningen end-to-end

Afslut opsætningen med en systematisk gennemgang, før du erklærer projektet klar til produktion:

1. Åbn VS Code og skriv en simpel funktion, f.eks. en sorteringsalgoritme. Bekræft, at kodeforslag dukker op inden for et par sekunder
2. Åbn chat-panelet og stil et spørgsmål om et konkret fil i dit indekserede repository
3. Log ind på dashboardet fra en anden maskine for at bekræfte, at HTTPS-adgangen virker korrekt
4. Genstart serveren (docker compose restart) og verificér, at data og indekser overlever genstarten
5. Tjek loggen for fejl relateret til GPU-hukommelse (out of memory), hvilket er det mest almindelige problem ved for lille VRAM til den valgte model

Et eksempel på et korrekt outputforløb i terminalen ser typisk sådan ud, når serveren er klar:

tabby-1  | 2026-09-05T08:12:41Z INFO tabby: Model loaded successfully: StarCoder2-7B
tabby-1  | 2026-09-05T08:12:42Z INFO tabby: Server listening on 0.0.0.0:8080
tabby-1  | 2026-09-05T08:12:42Z INFO tabby: Indexing job started for repository: dit-repo

Tabby vs. GitHub Copilot, Cursor og Continue.dev: hvad er forskellen?

Det centrale argument for Tabby er ikke, at kodeforslagene er bedre end Copilots, det er, at data aldrig forlader jeres infrastruktur. Ifølge TabbyMLs egen produktbeskrivelse er kerneserveren "Apache-2.0 licensed and self-hostable via Docker on a consumer-grade GPU or your own cloud", uden eksterne kald til tredjeparter og uden per-token-gebyrer. GitHub Copilot og Cursor er derimod rene SaaS-produkter bygget oven på Microsofts og Anthropics skymodeller, uden mulighed for on-premise-drift. Continue.dev indtager en mellemposition: det er en editor-udvidelse, der kan pege på lokale modeller, men leverer ikke selv en samlet multi-bruger-server med indeksering, brugerstyring og administrationspanel, som Tabby gør.

Løsning	Selvhosting	Licensmodel	Data forlader netværk
Tabby (selvhostet)	Fuld, Docker-baseret	Apache 2.0, gratis kerne	Nej, hvis lokal model bruges
GitHub Copilot	Ikke muligt	Abonnement, ingen selvhosting	Ja, altid
Cursor	Ikke muligt	Abonnement, ingen selvhosting	Ja, altid
Continue.dev	Delvis (kun modelendepunkt)	Open source-udvidelse	Afhænger af valgt model

For danske virksomheder underlagt GDPR eller branchespecifikke krav som i finans- og sundhedssektoren betyder dette i praksis, at Tabby er den eneste af de fire løsninger, hvor man kan garantere, at kildekoden aldrig krydser en landegrænse eller havner hos en amerikansk cloud-udbyder. Det koster til gengæld tid til drift og en investering i egen GPU-kapacitet, som Copilot og Cursor ikke kræver.

Det er også værd at nævne, hvor Tabby placerer sig i forhold til rene lokale model-runnere som Ollama eller LM Studio. Disse værktøjer kører også modeller lokalt, men de er tænkt som generelle model-servere uden en indbygget editor-integration, repository-indeksering eller brugerstyring målrettet kodning. Man kan i princippet pege Continue.dev eller andre editor-udvidelser mod en Ollama-instans og opnå en delvist selvhostet opsætning, men man mister Tabbys indbyggede team-funktioner: fælles dashboard, delt indeksering af kodebaser og centraliseret adgangsstyring. For et enkelt individuelt setup er Ollama plus en generisk udvidelse en fin, letvægts løsning. For et team, der skal dele én kodebevidst assistent, er Tabbys samlede pakke det mere modne valg.

Cloud-GPU eller egen hardware: hvor skal Tabby-serveren stå?

Et af de første spørgsmål, der dukker op, når man planlægger en Tabby-udrulning, er om serveren skal stå fysisk i eget serverrum eller lejes hos en cloud-udbyder. Begge veje har fordele, og valget afhænger i høj grad af, hvor følsom jeres kode er, og hvor forudsigeligt jeres brug er hen over ugen.

Ifølge Clore.ais prisoversigt for GPU-leje koster en RTX 3080-instans typisk mellem 0,05 og 0,19 dollar i timen hos specialiserede GPU-cloud-udbydere. For et team, der primært koder i almindelig kontortid, svarer det til en månedlig udgift på et par hundrede kroner, hvis I lukker serveren ned uden for arbejdstid. Til gengæld ligger data midlertidigt hos en ekstern udbyder, hvilket betyder, at I stadig skal sikre jer en databehandleraftale, og at I bør vælge en udbyder med datacentre inden for EU, hvis compliance er en driver for projektet.

Egen on-premise-hardware kræver en større engangsinvestering, ofte i omegnen af 8.000 til 15.000 kroner for en maskine med en passende GPU, men giver til gengæld fuld fysisk kontrol og ingen løbende cloud-regning. For virksomheder, der allerede har et serverrum og en driftsafdeling, er dette ofte den foretrukne løsning, netop fordi den fjerner enhver tvivl om, hvor dataene fysisk befinder sig. Har I derimod ikke eksisterende serverkapacitet, eller vil I teste Tabby i en pilotperiode, før I investerer i hardware, er en lejet cloud-GPU den hurtigste vej til at komme i gang uden en stor forudgående investering.

Priser: gratis selvhosting vs. TabbyMLs administrerede tiers

Tabby har to forskellige forretningsmodeller, som er vigtige at holde adskilt. Den ene er selvhosting, som er den, denne guide gennemgår, og som er helt gratis bortset fra jeres egne serveromkostninger. Den anden er TabbyMLs administrerede, hostede tilbud, hvor virksomheden selv drifter serveren for jer.

Tier	Pris	Brugergrænse	Noter
Open source (selvhostet)	Gratis	Ubegrænset	Apache 2.0, kører på egen hardware via Docker
Community (hostet af TabbyML)	0 $/bruger/md	Op til 5 brugere	Administreret af TabbyML
Team (hostet af TabbyML)	19 $/bruger/md	Op til 50 brugere	Per-sæde-fakturering
Enterprise	Tilpasset, årlig fakturering	Ubegrænset	Udvidet sikkerhed og gruppestyring

Vælger man selvhosting, som denne guide fokuserer på, er den eneste reelle omkostning hardwaren. En server med en RTX 3060 kan lejes hos flere GPU-cloud-udbydere for få kroner i timen, mens en fast on-premise-server med tilsvarende GPU typisk koster mellem 8.000 og 15.000 kroner i anskaffelse, afhængigt af resten af specifikationerne. For et team på 10-20 udviklere er det ofte tjent hjem inden for få måneder sammenlignet med Copilot Business-abonnementer. De fulde og opdaterede priser på TabbyMLs hostede tiers finder du altid på TabbyMLs officielle prisside, da tallene kan ændre sig hurtigere, end en artikel som denne bliver opdateret.

Tabby og GDPR: hvad betyder selvhosting reelt for compliance?

Mange IT-afdelinger antager fejlagtigt, at "selvhostet" automatisk betyder "GDPR-compliant". Det er kun halvdelen af sandheden. Selvhosting fjerner den del af risikoen, der handler om, hvorvidt kode og kommentarer sendes til en tredjepartsserver uden for EU. Det løser derimod ikke automatisk andre dele af compliance-billedet, som stadig kræver opmærksomhed, når I ruller Tabby ud i en dansk organisation.

For det første indeholder kildekode ofte personoplysninger i test-data, loguddrag eller hardkodede eksempler, selv når det ikke burde være tilfældet. Når Tabby indekserer et repository, gemmes en søgbar repræsentation af koden i serverens data-mappe. Er den mappe placeret på en server, der fysisk står i et tredjeland, eller på en cloud-instans hos en udbyder uden databehandleraftale, har I reelt ikke løst det problem, I forsøgte at undgå ved at forlade Copilot. Placér derfor Tabby-serveren på infrastruktur, hvor I allerede har styr på den juridiske ramme, typisk enten on-premise eller hos en EU-baseret cloud-udbyder med en gyldig databehandleraftale.

For det andet bør adgangsstyringen tages lige så alvorligt, som hvis det var et internt kildekode-repository. Fordi chat-funktionen kan svare på tværs af alle indekserede repositories, en bruger har adgang til, er det vigtigt, at gruppeopdelingen fra trin 11 rent faktisk afspejler jeres organisations behov for adskillelse mellem teams og projekter. En fejlkonfigureret adgangspolitik kan i praksis give en udvikler indsigt i kodebaser, vedkommende ikke burde have adgang til, hvilket er lige så alvorligt et databrud, uanset om det sker via Tabby eller et hvilket som helst andet internt system.

5 almindelige faldgruber ved selvhosting af Tabby

De fleste problemer med en selvhostet Tabby-server skyldes ikke selve softwaren, men konfigurationsfejl, der er lette at undgå, når man kender dem på forhånd.

• For lille GPU til den valgte model. Vælger man StarCoder2-15B på en GPU med kun 8 GB VRAM, crasher containeren med en "out of memory"-fejl ved opstart. Match altid modelstørrelsen til den faktiske VRAM, ikke den ønskede kvalitet.
• Manglende WebSocket-headers i reverse proxy. Uden proxy_set_header Upgrade og Connection "upgrade" i Nginx-konfigurationen fryser chat-panelet, fordi streaming-svar afbrydes.
• Data-mappen mountes forkert. Glemmer man volume-mountet på /data, mister man alle indekser, brugerkonti og indstillinger, hver gang containeren genstartes eller opdateres.
• Firewall blokerer port 8080 eller 443. Serveren starter fint, men ingen kan tilgå den udefra, fordi cloud-udbyderens sikkerhedsgruppe eller den lokale firewall aldrig blev åbnet.
• Forældet IDE-plugin. Ældre versioner af JetBrains-pluginet har haft rapporterede fejl med, at IDE'en fryser ved store redigeringer. Opdater altid pluginet til nyeste version, før det rulles ud bredt i organisationen.

Avancerede tips: skalering, sikkerhed og performance-tuning

Når grundopsætningen kører stabilt, er der en række justeringer, der løfter Tabby fra et testprojekt til en produktionsklar tjeneste for hele udviklingsorganisationen.

For skalering på tværs af flere teams bør I overveje at køre Tabby-serveren på en dedikeret GPU-node adskilt fra andre arbejdsbelastninger, så modelinferens ikke konkurrerer om ressourcer med for eksempel CI/CD-pipelines. Sæt desuden ressourcegrænser i Compose-filen, så en enkelt tung indekseringsopgave ikke sulter resten af serveren for hukommelse.

På sikkerhedssiden bør adgangstokens roteres periodisk, og adgangen til dashboardet bør begrænses via IP-whitelisting eller et internt VPN, så kun jeres eget netværk kan nå administrationspanelet. Overvej også at logge al trafik til Tabby-serveren i jeres SIEM-løsning, så uautoriserede forsøg på at forespørge kodebasen opdages hurtigt.

Til performance kan I eksperimentere med quantiserede modelvarianter, som reducerer VRAM-forbruget markant på bekostning af en smule kvalitet i forslagene. Det er en fornuftig mellemvej, hvis budgettet ikke rækker til en GPU med 16 GB+ VRAM, men I stadig ønsker en af de større, mere præcise modeller som StarCoder2-15B.

Bruger jeres team allerede flere AI-assistenter side om side, kan det også være relevant at kigge på, hvordan I centraliserer værktøjsadgang på tværs af dem via en MCP-serveropsætning, så Tabby og eventuelle andre assistenter kan dele samme kontekst-kilder. Et sidste tip handler om overvågning. Sæt et simpelt sundhedstjek op, der med jævne mellemrum kalder Tabbys API og logger svartiden. Stiger svartiden markant over tid, er det ofte et tegn på, at GPU-hukommelsen er ved at blive fyldt op af flere samtidige indekseringsjob, eller at der er behov for at skalere til en kraftigere GPU. En simpel cron-opgave, der kører curl -s -o /dev/null -w '%{time_total}\n' http://localhost:8080/ hvert femte minut og logger resultatet, giver jer et historisk billede uden at skulle indføre et helt observability-stack fra dag ét.

8 fejl og løsninger: fejlfinding af Tabby-serveren

Herunder er de mest almindelige problemer, danske teams typisk støder på, sammen med den konkrete løsning.

• Containeren stopper straks efter opstart. Tjek loggen med docker compose logs tabby. Ofte skyldes det manglende diskplads til modelvægtene, tjek med df -h.
• "CUDA out of memory" i loggen. Modellen er for stor til GPU'en. Skift til en mindre model, eller reducér antallet af samtidige forespørgsler.
• Kodeforslag dukker aldrig op i VS Code. Bekræft, at endpoint-adressen og adgangstoken er korrekt indtastet under Tabby: Set Endpoint, og at der ikke er en tastefejl i URL'en.
• Chat-panelet hænger eller loader evigt. Reverse proxy'en mangler WebSocket-support. Verificér Nginx-konfigurationen fra trin 8.
• Repository-indeksering fejler. Bekræft, at serveren har netværksadgang til Git-hosten, og at eventuelle SSH-nøgler eller access tokens til private repositories er korrekt konfigureret i dashboardet.
• Langsomme kodeforslag på CPU-only opsætning. Dette er forventet adfærd uden GPU. Overvej en mindre model som StarCoder2-1B, eller invester i en GPU til produktionsbrug.
• Certbot kan ikke udstede certifikat. Bekræft, at DNS-posten for jeres subdomæne peger korrekt mod serverens offentlige IP, og at port 80 er åben under selve udstedelsen.
• Data forsvinder efter en opdatering. Volume-mountet på /data mangler i Compose-filen, eller stien blev ændret ved en fejl. Genskab fra jeres seneste backup, og ret Compose-filen, før I opdaterer igen.

Løser ovenstående ikke jeres problem, er det næste skridt at søge i eksisterende issues på Tabbys GitHub-repository eller tjekke projektets sikkerhedsside for kendte sårbarheder, før I opretter en ny fejlrapport. Projektet er aktivt vedligeholdt, og de fleste driftsrelaterede spørgsmål er allerede besvaret i tidligere issues.

Komplet eksempel: fuldt fungerende Tabby-projekt

Til sidst samler vi hele opsætningen i én komplet, fungerende docker-compose.yml med reverse proxy, som I kan bruge som direkte udgangspunkt for jeres eget projekt.

version: "3.9"

services:
  tabby:
    image: tabbyml/tabby
    container_name: tabby-server
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./data:/data
      - /srv/repos:/repos:ro
    command: serve --model StarCoder2-7B --chat-model StarCoder2-7B --device cuda
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  nginx:
    image: nginx:stable
    container_name: tabby-proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./certs:/etc/letsencrypt
    depends_on:
      - tabby

Med denne fil, en tilhørende nginx.conf som beskrevet i trin 8, og et Let's Encrypt-certifikat udstedt via Certbot, har I en produktionsklar, selvhostet AI-kodeassistent, der er tilgængelig for hele teamet over HTTPS, med indekserede repositories og fuld kontrol over, hvor koden bevæger sig hen.

Ofte stillede spørgsmål om Tabby

Er Tabby helt gratis at bruge?
Kerneserveren er open source under Apache 2.0-licensen og gratis at selvhoste uden brugsbegrænsninger. TabbyML tilbyder derudover betalte, administrerede tiers, hvis I foretrækker, at virksomheden drifter serveren for jer.

Kræver Tabby en GPU for at fungere?
Nej, Tabby kan køre på ren CPU, men svartiderne på autofuldførelse bliver markant længere. Til produktionsbrug med et helt team anbefales en Nvidia GPU med mindst 8 GB VRAM.

Kan Tabby erstatte GitHub Copilot fuldt ud?
Til autofuldførelse og kodeforståelse via chat, ja. Tabby dækker de samme grundfunktioner. Copilot har dog flere avancerede agent-funktioner i visse IDE-integrationer, som Tabby endnu ikke matcher fuldt ud.

Understøtter Tabby danske kodekommentarer og variabelnavne?
Ja, de understøttede modeller som StarCoder2 og DeepSeek-Coder er trænet på flersprogede kodebaser og håndterer danske kommentarer og navngivning på linje med engelske.

Hvor meget diskplads bør jeg afsætte til Tabby?
Minimum 20 GB, men 50 GB anbefales, så der er plads til modelvægte, flere indekserede repositories og logfiler over tid.

Kan flere teams dele én Tabby-server?
Ja, via grupper og adgangskontrol i dashboardet kan I begrænse, hvilke repositories den enkelte bruger kan tilgå, selvom alle deler samme underliggende server.

Hvad sker der, hvis serveren går ned midt i en arbejdsdag?
Editorernes autofuldførelse holder simpelthen op med at give forslag, indtil serveren er oppe igen. Der er ingen risiko for tab af kode, da Tabby aldrig gemmer eller ændrer jeres kildefiler direkte.

Findes der kendte sikkerhedshuller i Tabby?
Der er ikke offentligt dokumenterede CVE'er specifikt for Tabby på tidspunktet for denne guide. Tjek altid projektets GitHub Security-fane og relevante CVE-databaser, før I ruller løsningen ud i produktion.

Kan Tabby køre uden internetadgang efter opsætningen?
Ja, når Docker-imaget og modelvægtene først er hentet, kan serveren køre helt offline eller i et isoleret netværkssegment. Det er relevant for organisationer med krav om luftgab mellem udviklingsmiljøet og internettet, selvom den første installation kræver netværksadgang til at hente selve softwaren og modellen.