Sådan selvhoster du code-server i 2026: WebSockets, workspaces og adgangskontrol

En mislykket code-server-deployment går ikke altid ned. Den kan vise en login-side, mens proxyen blokerer WebSockets, eller file ownership kan forhindre installation af extensions. Start i stedet med en end-to-end-kontrol: Log ind, åbn et mounted repository, opret en fil, kør en terminalkommando, installér en extension, og opret forbindelse til editorens WebSocket igen.

Denne kontrol stemmer overens med det katalogiserede formål med code-server: VS Code, der kører i browseren på en remote machine. Den afslører også manglende dependencies, forkerte proxy-antagelser og ephemeral data tidligere, end en uptime-probe kan.

Hvad code-server afhænger af

Tegn tre grænser omkring code-server: ingress til port 8080, durable state og supporting requirements. Containeren kan udskiftes, men de to andre kræver tydeligt definerede ejere. Det lokale runtime-krav er et workspace mount, der kun indeholder de projekter, editoren skal have adgang til. Test denne grænse før publicering og igen efter udskiftning af en container.

Diagrammet er komplet, når en clean client kan logge ind, åbne et mounted repository, oprette en fil, køre en terminalkommando, installere en extension og oprette forbindelse til editorens WebSocket igen. Registrér timing- og resourcedata for memory og CPU, der bruges af language servers, builds, extension hosts og terminals, i stedet for code-server-webshellen. Hvis transaktionen mislykkes, viser den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en supporting service.

Gør den lokale kommando til en service, der kan inspiceres

En production-lignende launch er bevidst kedelig: navngiven state, eksplicit port og ingen secret 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 .

Eksemplet er et baseline-eksempel snarere end en komplet supporting stack. Bekræft det lokale krav før eksponering: et workspace mount, der kun indeholder de projekter, editoren skal have adgang til. Kontrollér de effektive mounts og listeneren, og prøv derefter at logge ind, åbne et mounted repository, oprette en fil, køre en terminalkommando, installere en extension og oprette forbindelse til editorens WebSocket igen. Pin det fungerende image før næste restart.

Gør den offentlige origin entydig

Placér editoren bag HTTPS, og bevar WebSocket-upgrades. Send det valgte hostname til container port 8080, videresend den oprindelige host og HTTPS scheme, og undgå at publicere en ekstra direkte origin.

Test code-server fra en clean external client. Adskil ingress-fejl fra den kendte application boundary — proxyen blokerer WebSockets, eller file ownership forhindrer installation af extensions. En certifikat-, DNS- eller 502-fejl hører til routing; en request, der når code-server og fejler senere, hører til application state, kapacitet eller dens supporting requirement. Guiden til TLS for custom domains dækker den første gruppe.

Tag backup af den state, code-server ikke kan genskabe

Et container image kan downloades igen; konfigurationen, extensions og eksplicit mountede projektmapper kan ikke. Mount /home/coder før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Inspicér det effektive mount i stedet for at stole på et Compose-filnavn, og kontrollér, at runtime-brugeren kan skrive dér, hvor code-server forventer det.

Vælg retention og en destination uden for hosten, og øv recovery uden at berøre production. Øvelsen er kun bestået, når settings, extensions og workspace-filer vender tilbage med korrekt ownership, og terminalen starter under den tilsigtede bruger. For database-backed state skal storage snapshots kombineres med application-consistente exports som beskrevet i point-in-time recovery versus snapshots.

Lås code-server ned efter bootstrap

For code-server er den værdifulde attack surface ikke nødvendigvis landing page. Den største fejl er uden videre at give containeren adgang til Docker socket eller hele host-filsystemet. Modvirk det bevidst: mount kun de tilsigtede workspaces, undgå hostens Docker socket, og placér editoren bag både HTTPS og stærk authentication.

Udskift eksempelværdien for PASSWORD med det samme, opbevar den uden for imaget, og rotér den som en administrator credential, hvis den bliver eksponeret. Brug en unprivileged container user, når imaget understøtter det, og mount ingen uvedkommende credentials. Anvend rate- eller size limits ved ingress, hvor untrusted work kan bruge memory og CPU, der ellers skal bruges af language servers, builds, extension hosts og terminals, i stedet for code-server-webshellen.

Diagnosticér en code-server, der ser sund ud

Observer det arbejde, code-server udfører: memory og CPU, der bruges af language servers, builds, extension hosts og terminals, i stedet for code-server-webshellen. Sæt limits med headroom til dette arbejde, og undgå en liveness probe, der konkurrerer med det. Operatørkontrollen skal stadig med faste intervaller forsøge at logge ind, åbne et mounted repository, oprette en fil, køre en terminalkommando, installere en extension og oprette forbindelse til editorens WebSocket igen.

Ved updates skal du huske, at extension compatibility og toolchains i base-imaget kan ændre sig, selv om code-server-UI'et stadig starter. Deploy kandidaten mod en recovered copy, og gentag den kendte test. Hvis proxyen blokerer WebSockets, eller file ownership forhindrer installation af extensions, skal du bruge runtime logs og den faktiske network request til at finde den ændrede antagelse.

Dokumentation, der skal indsamles, før code-server går i production

Opret et lille, disposable code-server-fixture, og behold det til hver release. Fixturen skal afprøve det reelle workflow: Log ind, åbn et mounted repository, opret en fil, kør en terminalkommando, installér en extension, og opret forbindelse til editorens WebSocket igen. Registrér image digest, eksternt hostname, dependency address og det forventede resultat, så en senere operatør kan gentage testen uden at fortolke denne guide.

Kør fixturen tre gange. Brug først den friske deployment. Udskift derefter containeren uden at ændre durable state. Gendan til sidst backup'en i et tomt environment. Den tredje kørsel er kun bestået, når settings, extensions og workspace-filer vender tilbage med korrekt ownership, og terminalen starter under den tilsigtede bruger. Under hver kørsel skal du registrere latency og resource use omkring memory og CPU, der bruges af language servers, builds, extension hosts og terminals, i stedet for code-server-webshellen; det bliver baseline for alerts frem for en tilfældig CPU-procent.

Test til sidst den negative path bevidst: Send ufarligt input tæt på den resource- eller formatgrænse, der er knyttet til denne boundary: proxyen blokerer WebSockets, eller file ownership forhindrer installation af extensions. Bekræft, at code-server fejler synligt uden at beskadige state, genskab den korrekte betingelse, og gentag den vellykkede transaktion. En release record med disse fire resultater er stærkere dokumentation end screenshots af et dashboard eller et enkelt curl-svar.

Flyt det gentagelige infrastrukturarbejde til Dockup

Dockup kan håndtere de udskiftelige platformdele: route traffic til port 8080, udstede domain og certificate, injecte secrets, tilknytte persistent storage og forbinde code-server med managed eller privately attached services. Det kan ske på Dockup-infrastruktur eller på en server, du tilknytter.

Acceptance-arbejdet for code-server forbliver eksplicit. Efter one-click-deploymenten skal du placere editoren bag HTTPS og bevare WebSocket-upgrades, bekræfte det lokale krav — et workspace mount, der kun indeholder de projekter, editoren skal have adgang til — og køre dette scenarie: Log ind, åbn et mounted repository, opret en fil, kør en terminalkommando, installér en extension, og opret forbindelse til editorens WebSocket igen. Denne opdeling er tilsigtet: Dockup fjerner gentagende infrastruktur-setup uden at lade som om application roles, provider credentials eller restore policy vælger sig selv.

Ofte stillede spørgsmål

Hvad kræver code-server til en production-deployment?

Route code-server-containeren på port 8080 gennem én HTTPS-origin. Det lokale runtime-krav er et workspace mount, der kun indeholder de projekter, editoren skal have adgang til. Erklær ikke code-server klar, før du kan logge ind, åbne et mounted repository, oprette en fil, køre en terminalkommando, installere en extension og oprette forbindelse til editorens WebSocket igen.

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

Persistér /home/coder, og medtag konfigurationen, extensions og eksplicit mountede projektmapper i det samme recovery-manifest. En clean code-server-restore er kun bestået, når settings, extensions og workspace-filer vender tilbage med korrekt ownership, og terminalen starter under den tilsigtede bruger.

Kræver code-server HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige code-server-origin, og behold port 8080 på den interne route. Anvend code-server-indstillingen korrekt: Placér editoren bag HTTPS, og bevar WebSocket-upgrades. For code-server beskytter HTTPS credentials eller brugerindhold under transmission og sikrer ensartet origin-sensitive client behavior.

Hvordan skal en code-server-opgradering testes?

Gendan den aktuelle code-server-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi extension compatibility og toolchains i base-imaget kan ændre sig, selv om code-server-UI'et stadig starter. Behold det tidligere code-server-image, indtil dets data-migration- og rollback-boundary er forstået.