Slik selvhoster du code-server i 2026: WebSockets, workspaces og tilgangskontroll

En mislykket code-server-distribusjon krasjer ikke alltid. Den kan vise en innloggingsside mens proxyen blokkerer WebSockets, eller fileierskap kan hindre installasjon av extensions. Start heller med en ende-til-ende-sjekk: logg inn, åpne et montert repository, opprett en fil, kjør en terminalkommando, installer en extension og koble til editorens WebSocket på nytt.

Denne sjekken samsvarer med den dokumenterte hensikten med code-server: VS Code som kjører i nettleseren på en ekstern maskin. Den avdekker også manglende avhengigheter, feil antakelser om proxyen og ephemeral data tidligere enn en uptime-sjekk kan.

Hva code-server er avhengig av

Trekk tre grenser rundt code-server: ingress til port 8080, persistent state og støttende krav. Containeren kan erstattes, men de to andre må ha tydelige eiere. Det lokale runtime-kravet er et workspace-mount som bare inneholder prosjektene editoren skal ha tilgang til. Test denne grensen før publisering og igjen etter at en container er erstattet.

Diagrammet er komplett når en ren klient kan logge inn, åpne et montert repository, opprette en fil, kjøre en terminalkommando, installere en extension og koble til editorens WebSocket på nytt. Registrer tids- og ressursdata for minne og CPU brukt av language servers, builds, extension hosts og terminaler, ikke av code-server-webskallet. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert, om du bør undersøke routing, lokal kapasitet eller en støttetjeneste.

Gjør den lokale kommandoen til en tjeneste du kan inspisere

En produksjonslignende oppstart er med vilje kjedelig: navngitt state, eksplisitt port og ingen secret inne i imaget.

docker run -d \
  --name code-server \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v code-server-data:/home/coder \
  -e PASSWORD=replace-with-a-long-random-value \
  codercom/code-server:latest \
  --bind-addr 0.0.0.0:8080 --auth password .

Eksempelet er et utgangspunkt, ikke en komplett støttestack. Bekreft det lokale kravet før eksponering: et workspace-mount som bare inneholder prosjektene editoren skal ha tilgang til. Kontroller de faktiske mountene og lytteren, og prøv deretter å logge inn, åpne et montert repository, opprette en fil, kjøre en terminalkommando, installere en extension og koble til editorens WebSocket på nytt. Lås den fungerende imaget før neste restart.

Gjør den offentlige origin-en entydig

Plasser editoren bak HTTPS og behold WebSocket-upgrades. Send det valgte hostname-et til containerport 8080, videresend den opprinnelige host-en og HTTPS-skjemaet, og unngå å publisere en ekstra direkte origin.

Test code-server fra en ren ekstern klient. Skill ingress-feil fra den kjente applikasjonsgrensen — proxyen blokkerer WebSockets, eller fileierskap hindrer installasjon av extensions. En certificate-, DNS- eller 502-feil hører hjemme i routing; en request som når code-server og feiler senere, hører hjemme i application state, kapasitet eller et støttende krav. Veiledningen for TLS med custom domain dekker den første gruppen.

Sikkerhetskopier state som code-server ikke kan gjenskape

Et container-image kan lastes ned på nytt, men konfigurasjonen, extensions og eksplisitt monterte prosjektkataloger kan ikke det. Monter /home/coder før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Inspiser det faktiske mountet i stedet for å stole på et Compose-filnavn, og kontroller at runtime-brukeren kan skrive der code-server forventer det.

Velg retention og en destinasjon utenfor verten, og øv på gjenoppretting uten å berøre produksjon. Øvelsen er bare godkjent når settings, extensions og workspace-filer kommer tilbake med riktig eierskap, og terminalen starter med den tiltenkte brukeren. For databasebasert state bør du kombinere storage snapshots med application-consistent exports, som beskrevet i point-in-time recovery versus snapshots.

Sikre code-server etter bootstrap

For code-server er den verdifulle angrepsflaten ikke nødvendigvis landingssiden. Den største feilen er å gi containeren tilgang til Docker-socketen eller hele vertens filsystem uten videre. Motvirk dette bevisst: monter bare tiltenkte workspaces, unngå Docker-socketen på verten og plasser editoren bak både HTTPS og sterk autentisering.

Bytt ut eksempelverdien for PASSWORD umiddelbart, lagre den utenfor imaget og roter den som en administrator-legitimasjon hvis den blir eksponert. Bruk en unprivileged container-bruker når imaget støtter det, og ikke monter uvedkommende credentials. Bruk rate- eller størrelsesbegrensninger i ingressen der arbeid fra brukere du ikke stoler på, kan bruke minne og CPU som egentlig trengs av language servers, builds, extension hosts og terminaler, ikke av code-server-webskallet.

Feilsøk en code-server som ser frisk ut

Observer arbeidet code-server utfører: minne og CPU brukt av language servers, builds, extension hosts og terminaler, ikke av code-server-webskallet. Sett grenser med nok margin for dette arbeidet, og unngå en liveness probe som konkurrerer om ressursene. Operatørsjekken bør fortsatt forsøke å logge inn, åpne et montert repository, opprette en fil, kjøre en terminalkommando, installere en extension og koble til editorens WebSocket på nytt med jevne mellomrom.

Ved oppdateringer må du huske at extension-kompatibilitet og toolchains i base-imaget kan endres selv om code-server-grensesnittet fortsatt starter. Deploy kandidatversjonen mot en gjenopprettet kopi og gjenta den kjente testen. Hvis proxyen blokkerer WebSockets eller fileierskap hindrer installasjon av extensions, bruker du runtime-logger og den faktiske nettverksforespørselen for å finne ut hvilken antakelse som er endret.

Dokumentasjon du bør samle inn før code-server settes i produksjon

Opprett en liten, midlertidig code-server-fixture og behold den for hver release. Fixturen bør teste den faktiske arbeidsflyten: logg inn, åpne et montert repository, opprett en fil, kjør en terminalkommando, installer en extension og koble til editorens WebSocket på nytt. Registrer image digest, eksternt hostname, adressen til avhengigheten og forventet resultat, slik at en senere operatør kan gjenta testen uten å tolke denne veiledningen.

Kjør fixturen tre ganger. Først bruker du den nye deploymenten. Deretter erstatter du containeren uten å berøre persistent state. Til slutt gjenoppretter du sikkerhetskopien i et tomt miljø. Den tredje kjøringen er bare godkjent når settings, extensions og workspace-filer kommer tilbake med riktig eierskap, og terminalen starter med den tiltenkte brukeren. Registrer under hver kjøring latency og ressursbruk knyttet til minne og CPU brukt av language servers, builds, extension hosts og terminaler, ikke av code-server-webskallet; dette blir baseline for alarmer i stedet for en vilkårlig CPU-prosent.

Til slutt tester du den negative banen med vilje: send ufarlig input nær ressurs- eller formatgrensen som er knyttet til denne grensen: proxyen blokkerer WebSockets, eller fileierskap hindrer installasjon av extensions. Bekreft at code-server feiler synlig uten å ødelegge state, gjenopprett riktig tilstand og gjenta den vellykkede transaksjonen. En release-registrering som inneholder disse fire resultatene, er sterkere dokumentasjon enn skjermbilder av et dashboard eller en enkelt curl-respons.

Flytt det repeterbare infrastrukturarbeidet til Dockup

Dockup kan håndtere de utskiftbare plattformdelene: route trafikk til port 8080, opprette domenet og sertifikatet, injisere secrets, koble til persistent storage og koble code-server til administrerte eller privat tilkoblede tjenester. Dette kan gjøres på Dockup-infrastruktur eller på en server du kobler til.

Akseptansearbeidet for code-server må fortsatt være eksplisitt. Etter one-click-deploymenten plasserer du editoren bak HTTPS og beholder WebSocket-upgrades, bekrefter det lokale kravet — et workspace-mount som bare inneholder prosjektene editoren skal ha tilgang til — og kjører dette scenarioet: logg inn, åpne et montert repository, opprett en fil, kjør en terminalkommando, installer en extension og koble til editorens WebSocket på nytt. Denne arbeidsdelingen er bevisst: Dockup fjerner repetitivt infrastrukturarbeid uten å late som om applikasjonsroller, provider-credentials eller restore-policy velger seg selv.

Ofte stilte spørsmål

Hva trenger code-server for en produksjonsdeployment?

Route code-server-containeren på port 8080 gjennom én HTTPS-origin. Det lokale runtime-kravet er et workspace-mount som bare inneholder prosjektene editoren skal ha tilgang til. Ikke erklær code-server som klar før du kan logge inn, åpne et montert repository, opprette en fil, kjøre en terminalkommando, installere en extension og koble til editorens WebSocket på nytt.

Hvilke code-server-data hører hjemme i en sikkerhetskopi?

Gjør /home/coder persistent, og ta med konfigurasjonen, extensions og eksplisitt monterte prosjektkataloger i det samme recovery-manifestet. En ren code-server-gjenoppretting er bare godkjent når settings, extensions og workspace-filer kommer tilbake med riktig eierskap, og terminalen starter med den tiltenkte brukeren.

Krever code-server HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige code-server-origin-en, og behold port 8080 på den interne routen. Bruk code-server-innstillingen riktig: plasser editoren bak HTTPS og behold WebSocket-upgrades. For code-server beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en code-server-oppgradering testes?

Gjenopprett gjeldende code-server-state i en isolert deployment, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at extension-kompatibilitet og toolchains i base-imaget kan endres selv om code-server-grensesnittet fortsatt starter. Behold den forrige code-server-imaget til grensene for datamigrering og rollback er forstått.