Så driftar du code-server själv 2026: WebSockets, arbetsytor och åtkomstkontroll

En misslyckad code-server-deployment kraschar inte alltid. Den kan visa en inloggningssida samtidigt som proxyn blockerar WebSockets eller filägarskap förhindrar installation av extensions. Börja i stället med en kontroll från början till slut: logga in, öppna ett monterat repository, skapa en fil, kör ett terminalkommando, installera en extension och återanslut editorns WebSocket.

Den kontrollen motsvarar det dokumenterade syftet med code-server: VS Code som körs i webbläsaren på en fjärrdator. Den synliggör också saknade beroenden, felaktiga antaganden om proxyn och temporär data tidigare än vad en uptime-kontroll kan göra.

Vad code-server är beroende av

Dra tre gränser runt code-server: ingress till port 8080, persistent state och stödkrav. Containern kan ersättas, men de två andra behöver tydliga ägare. Det lokala runtime-kravet är en workspace-mount som endast innehåller de projekt som editorn ska kunna nå. Testa den gränsen innan publicering och igen efter att en container har ersatts.

Diagrammet är komplett när en ren klient kan logga in, öppna ett monterat repository, skapa en fil, köra ett terminalkommando, installera en extension och återansluta editorns WebSocket. Samla in tids- och resursdata för minne och CPU som används av language servers, builds, extension hosts och terminaler, inte av code-server-skalet i webbläsaren. Om transaktionen misslyckas visar den första gräns som inte fungerar enligt dokumentationen om du ska undersöka routing, lokal kapacitet eller en stödtjänst.

Gör det lokala kommandot till en tjänst som går att inspektera

En produktionslik start är medvetet odramatisk: namngiven state, explicit port och inga hemligheter i imagen.

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 .

Exemplet är en baslinje, inte en komplett stödstack. Bekräfta det lokala kravet innan exponering: en workspace-mount som endast innehåller de projekt som editorn ska kunna nå. Kontrollera de aktiva mountarna och lyssnaren och försök sedan logga in, öppna ett monterat repository, skapa en fil, köra ett terminalkommando, installera en extension och återansluta editorns WebSocket. Lås den fungerande imagen innan nästa omstart.

Gör den publika origin-URL:en entydig

Placera editorn bakom HTTPS och bevara WebSocket-uppgraderingar. Skicka det valda hostname:t till containerport 8080, vidarebefordra det ursprungliga host-värdet och HTTPS-schemat och undvik att publicera en andra direkt origin.

Testa code-server från en ren extern klient. Separera ingressproblem från den kända applikationsgränsen – proxyn blockerar WebSockets eller filägarskap förhindrar installation av extensions. Certifikat-, DNS- eller 502-fel hör till routing; en begäran som når code-server men misslyckas senare hör till applikationens state, kapacitet eller stödkrav. Guiden för TLS med egen domän täcker den första gruppen.

Säkerhetskopiera den state som code-server inte kan återskapa

En containerimage kan laddas ned igen, men konfigurationen, extensionerna och de uttryckligen monterade projektkatalogerna kan inte det. Montera /home/coder före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Inspektera den aktiva mounten i stället för att lita på ett Compose-filnamn och kontrollera att runtime-användaren kan skriva där code-server förväntar sig det.

Välj retention och en destination utanför hosten och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när inställningar, extensions och workspace-filer återkommer med korrekt ägarskap och terminalen startar under avsedd användare. För databasbaserad state kombinerar du storage snapshots med applikationskonsistenta exporter enligt beskrivningen i point-in-time recovery jämfört med snapshots.

Lås ned code-server efter bootstrap

För code-server är den värdefulla attackytan inte nödvändigtvis landningssidan. Det vanligaste misstaget är att utan eftertanke ge containern åtkomst till Docker-socketen eller hela hostens filsystem. Motverka det medvetet: montera endast avsedda workspaces, undvik hostens Docker-socket och placera editorn bakom både HTTPS och stark autentisering.

Byt ut exempelvärdet för PASSWORD omedelbart, lagra det utanför imagen och rotera det som en administratörscredential om det exponeras. Använd en unprivileged container-användare när imagen stöder det och montera inga orelaterade credentials. Tillämpa rate- eller storleksbegränsningar i ingressen där otillförlitligt arbete kan förbruka minne och CPU som används av language servers, builds, extension hosts och terminaler, snarare än av code-server-skalet i webbläsaren.

Felsök en code-server som ser frisk ut

Observera det arbete som code-server utför: minne och CPU som används av language servers, builds, extension hosts och terminaler, inte av code-server-skalet i webbläsaren. Sätt gränser med marginal för det arbetet och undvik en liveness probe som konkurrerar om resurserna. Operatörskontrollen bör fortfarande regelbundet försöka logga in, öppna ett monterat repository, skapa en fil, köra ett terminalkommando, installera en extension och återansluta editorns WebSocket.

Vid uppdateringar bör du komma ihåg att kompatibilitet för extensions och verktygskedjor i base-imagen kan förändras även när code-server-UI:t fortfarande startar. Driftsätt kandidaten mot en återställd kopia och upprepa det kända testet. Om proxyn blockerar WebSockets eller filägarskap förhindrar installation av extensions använder du runtime-loggar och den faktiska nätverksbegäran för att hitta vilket antagande som har ändrats.

Underlag att samla in innan code-server tas i drift

Skapa en liten, temporär code-server-fixture och behåll den för varje release. Fixturen ska testa det verkliga arbetsflödet: logga in, öppna ett monterat repository, skapa en fil, köra ett terminalkommando, installera en extension och återansluta editorns WebSocket. Dokumentera image-digest, externt hostname, beroendeadress och förväntat resultat så att en senare operatör kan upprepa testet utan att behöva tolka den här guiden.

Kör fixturen tre gånger. Använd först den nya deploymenten. Ersätt sedan containern utan att röra persistent state. Återställ till sist säkerhetskopian i en tom miljö. Den tredje körningen är godkänd först när inställningar, extensions och workspace-filer återkommer med korrekt ägarskap och terminalen startar under avsedd användare. Samla under varje körning in svarstid och resursanvändning för minne och CPU som används av language servers, builds, extension hosts och terminaler, snarare än av code-server-skalet i webbläsaren; detta blir baslinjen för larm i stället för en godtycklig CPU-procentsats.

Testa slutligen den negativa vägen medvetet: skicka ofarlig indata nära den resurs- eller formatgräns som hör till den här gränsen: proxyn blockerar WebSockets eller filägarskap förhindrar installation av extensions. Bekräfta att code-server misslyckas synligt utan att state blir korrupt, återställ det korrekta tillståndet och upprepa den lyckade transaktionen. En releasepost med dessa fyra resultat är starkare bevis än skärmbilder av en dashboard eller ett engångssvar från curl.

Flytta det upprepningsbara infrastrukturarbetet till Dockup

Dockup kan ansvara för de utbytbara plattformsdelarna: dirigera trafik till port 8080, utfärda domän och certifikat, injicera hemligheter, ansluta persistent storage och koppla code-server till hanterade eller privat anslutna tjänster. Detta kan göras på Dockup-infrastruktur eller på en server som du ansluter.

Acceptansarbetet för code-server förblir explicit. Efter one-click-deploymenten placerar du editorn bakom HTTPS och bevarar WebSocket-uppgraderingar, bekräftar det lokala kravet – en workspace-mount som endast innehåller de projekt som editorn ska kunna nå – och kör detta scenario: logga in, öppna ett monterat repository, skapa en fil, köra ett terminalkommando, installera en extension och återansluta editorns WebSocket. Den uppdelningen är avsiktlig: Dockup tar bort repetitiv setup av infrastrukturen utan att låtsas att applikationsroller, provider-credentials eller återställningspolicy väljer sig själva.

Vanliga frågor

Vad behöver code-server för en produktionsdeployment?

Dirigera code-server-containern på port 8080 genom en enda HTTPS-origin. Det lokala runtime-kravet är en workspace-mount som endast innehåller de projekt som editorn ska kunna nå. Anse inte code-server vara redo förrän du kan logga in, öppna ett monterat repository, skapa en fil, köra ett terminalkommando, installera en extension och återansluta editorns WebSocket.

Vilka code-server-data ska ingå i en säkerhetskopia?

Gör /home/coder persistent och inkludera konfigurationen, extensionerna och de uttryckligen monterade projektkatalogerna i samma återställningsmanifest. En ren code-server-återställning är godkänd först när inställningar, extensions och workspace-filer återkommer med korrekt ägarskap och terminalen startar under avsedd användare.

Kräver code-server HTTPS bakom en reverse proxy?

Använd HTTPS för den publika code-server-origin och behåll port 8080 i den interna routen. Tillämpa code-server-inställningen korrekt: placera editorn bakom HTTPS och bevara WebSocket-uppgraderingar. För code-server skyddar HTTPS credentials eller användarinnehåll under överföring och ser till att klientbeteende som är känsligt för origin förblir konsekvent.

Hur bör en code-server-uppgradering testas?

Återställ aktuell code-server-state till en isolerad deployment, använd kandidatversionen och upprepa dess acceptanstest. Var särskilt uppmärksam eftersom kompatibilitet för extensions och verktygskedjor i base-imagen kan förändras även när code-server-UI:t fortfarande startar. Behåll den tidigare code-server-imagen tills gränsen för datamigrering och rollback är förstådd.