Comment auto-héberger code-server en 2026 : WebSockets, espaces de travail et contrôle des accès

Un déploiement code-server en échec ne plante pas toujours. Il peut afficher une page de connexion alors que le proxy bloque les WebSockets ou que les droits sur les fichiers empêchent l’installation d’extensions. Commencez plutôt par une vérification de bout en bout : connectez-vous, ouvrez un dépôt monté, créez un fichier, exécutez une commande dans le terminal, installez une extension et reconnectez le WebSocket de l’éditeur.

Cette vérification correspond à la finalité répertoriée de code-server : VS Code exécuté dans le navigateur sur une machine distante. Elle révèle également les dépendances manquantes, les hypothèses incorrectes concernant le proxy et les données éphémères plus tôt qu’une sonde de disponibilité.

Ce dont dépend code-server

Délimitez trois zones autour de code-server : l’entrée vers le port 8080, l’état durable et les exigences de support. Le conteneur est remplaçable, mais les deux autres éléments doivent avoir des responsables explicites. L’exigence d’exécution locale est un montage d’espace de travail contenant uniquement les projets auxquels l’éditeur doit pouvoir accéder. Testez cette limite avant la mise à disposition, puis à nouveau après le remplacement d’un conteneur.

Le schéma est complet lorsqu’un client vierge peut se connecter, ouvrir un dépôt monté, créer un fichier, exécuter une commande dans le terminal, installer une extension et reconnecter le WebSocket de l’éditeur. Collectez les données de durée et de ressources pour la mémoire et le CPU utilisés par les language servers, les builds, les extension hosts et les terminaux, plutôt que par le shell web de code-server. Si la transaction échoue, la première limite qui ne se comporte pas comme indiqué permet de déterminer s’il faut examiner le routage, la capacité locale ou un service de support.

Transformer la commande locale en service inspectable

Un lancement adapté à la production est volontairement sobre : un état nommé, un port explicite et aucun secret dans l’image.

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 .

L’exemple constitue une base, et non une stack de support complète. Confirmez l’exigence locale avant toute exposition : un montage d’espace de travail contenant uniquement les projets auxquels l’éditeur doit pouvoir accéder. Vérifiez les montages effectifs et le processus en écoute, puis essayez de vous connecter, d’ouvrir un dépôt monté, de créer un fichier, d’exécuter une commande dans le terminal, d’installer une extension et de reconnecter le WebSocket de l’éditeur. Épinglez l’image fonctionnelle avant le prochain redémarrage.

Rendre l’origine publique non ambiguë

Placez l’éditeur derrière HTTPS et préservez les upgrades WebSocket. Envoyez le hostname choisi vers le port 8080 du conteneur, transmettez l’hôte d’origine et le schéma HTTPS, et évitez de publier une seconde origine directe.

Testez code-server depuis un client externe vierge. Séparez l’échec de l’entrée de l’application de la limite connue de l’application — le proxy bloque les WebSockets ou les droits sur les fichiers empêchent l’installation d’extensions. Une erreur de certificat, de DNS ou de type 502 relève du routage ; une requête qui atteint code-server puis échoue relève de l’état de l’application, de la capacité ou de son exigence de support. Le guide TLS pour les domaines personnalisés couvre le premier groupe.

Sauvegarder l’état que code-server ne peut pas recréer

Une image de conteneur peut être téléchargée à nouveau ; la configuration, les extensions et les répertoires de projets explicitement montés, eux, ne le peuvent pas. Montez /home/coder avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Inspectez le montage effectif au lieu de faire confiance à un nom de fichier Compose, et vérifiez que l’utilisateur d’exécution peut écrire là où code-server l’attend.

Choisissez une durée de rétention et une destination externe, puis répétez la procédure de restauration sans toucher à la production. L’exercice n’est réussi que lorsque les paramètres, les extensions et les fichiers de l’espace de travail sont restaurés avec les bons droits et que le terminal démarre sous l’utilisateur prévu. Pour les états adossés à une base de données, associez les snapshots du stockage à des exports cohérents du point de vue de l’application, comme indiqué dans récupération à un instant donné ou snapshots.

Sécuriser code-server après le bootstrap

Pour code-server, la surface importante n’est pas nécessairement la page d’accueil. L’erreur principale consiste à accorder négligemment au conteneur l’accès au socket Docker ou à l’ensemble du système de fichiers de l’hôte. Corrigez cela de manière délibérée : montez uniquement les espaces de travail prévus, évitez le socket Docker de l’hôte et placez l’éditeur derrière HTTPS ainsi qu’une authentification forte.

Remplacez immédiatement le PASSWORD d’exemple, stockez-le en dehors de l’image et faites-le tourner comme un identifiant d’administrateur s’il est exposé. Utilisez un utilisateur de conteneur non privilégié lorsque l’image le permet et ne montez aucun identifiant sans rapport. Appliquez des limites de débit ou de taille à l’entrée lorsque des tâches non fiables peuvent consommer de la mémoire et du CPU utilisés par les language servers, les builds, les extension hosts et les terminaux, plutôt que par le shell web de code-server.

Diagnostiquer un code-server qui semble sain

Observez le travail effectué par code-server : la mémoire et le CPU utilisés par les language servers, les builds, les extension hosts et les terminaux, plutôt que par le shell web de code-server. Définissez des limites avec une marge suffisante pour ce travail et évitez une sonde de vivacité qui entre en concurrence avec lui. La vérification opérateur doit malgré tout tenter, selon une planification définie, de se connecter, d’ouvrir un dépôt monté, de créer un fichier, d’exécuter une commande dans le terminal, d’installer une extension et de reconnecter le WebSocket de l’éditeur.

Pour les mises à jour, gardez à l’esprit que la compatibilité des extensions et les toolchains de l’image de base peuvent changer même lorsque l’interface de code-server démarre toujours. Déployez la version candidate sur une copie restaurée et répétez le test connu. Si le proxy bloque les WebSockets ou que les droits sur les fichiers empêchent l’installation d’extensions, utilisez les logs d’exécution et la requête réseau réelle pour déterminer quelle hypothèse a changé.

Éléments à réunir avant la mise en production de code-server

Créez un petit dispositif code-server jetable et conservez-le pour chaque release. Il doit reproduire le workflow réel : se connecter, ouvrir un dépôt monté, créer un fichier, exécuter une commande dans le terminal, installer une extension et reconnecter le WebSocket de l’éditeur. Notez le digest de l’image, le hostname externe, l’adresse de la dépendance et le résultat attendu afin qu’un autre opérateur puisse répéter le test ultérieurement sans devoir interpréter ce guide.

Exécutez le dispositif trois fois. Commencez par le déploiement vierge. Remplacez ensuite le conteneur sans toucher à l’état durable. Enfin, restaurez la sauvegarde dans un environnement vide. La troisième exécution n’est réussie que lorsque les paramètres, les extensions et les fichiers de l’espace de travail sont restaurés avec les bons droits et que le terminal démarre sous l’utilisateur prévu. À chaque exécution, collectez la latence et l’utilisation des ressources autour de la mémoire et du CPU utilisés par les language servers, les builds, les extension hosts et les terminaux, plutôt que par le shell web de code-server ; cela devient la référence pour les alertes, au lieu d’un pourcentage de CPU arbitraire.

Enfin, testez délibérément le chemin négatif : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette limite : le proxy bloque les WebSockets ou les droits sur les fichiers empêchent l’installation d’extensions. Vérifiez que code-server échoue de manière visible sans corrompre l’état, rétablissez la condition correcte, puis répétez la transaction réussie. Un compte rendu de release contenant ces quatre résultats constitue une preuve plus solide que des captures d’écran d’un dashboard ou qu’une réponse curl ponctuelle.

Déplacer le travail d’infrastructure répétable vers Dockup

Dockup peut prendre en charge les éléments remplaçables de la plateforme : acheminer le trafic vers le port 8080, émettre le domaine et le certificat, injecter les secrets, associer le stockage persistant et connecter code-server à des services gérés ou attachés de manière privée. Il peut le faire sur l’infrastructure Dockup ou sur un serveur que vous rattachez.

Le travail d’acceptation de code-server reste explicite. Après le déploiement en un clic, placez l’éditeur derrière HTTPS et préservez les upgrades WebSocket, confirmez l’exigence locale — un montage d’espace de travail contenant uniquement les projets auxquels l’éditeur doit pouvoir accéder — puis exécutez ce scénario : connectez-vous, ouvrez un dépôt monté, créez un fichier, exécutez une commande dans le terminal, installez une extension et reconnectez le WebSocket de l’éditeur. Cette division est intentionnelle : Dockup élimine la configuration répétitive de l’infrastructure sans prétendre que les rôles applicatifs, les identifiants des fournisseurs ou la stratégie de restauration se choisissent seuls.

Foire aux questions

De quoi code-server a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur code-server sur le port 8080 via une seule origine HTTPS. L’exigence d’exécution locale est un montage d’espace de travail contenant uniquement les projets auxquels l’éditeur doit pouvoir accéder. Ne considérez pas code-server comme prêt tant que vous ne pouvez pas vous connecter, ouvrir un dépôt monté, créer un fichier, exécuter une commande dans le terminal, installer une extension et reconnecter le WebSocket de l’éditeur.

Quelles données de code-server faut-il inclure dans une sauvegarde ?

Rendez /home/coder persistant et incluez la configuration, les extensions et les répertoires de projets explicitement montés dans le même manifeste de restauration. Une restauration code-server vierge n’est réussie que lorsque les paramètres, les extensions et les fichiers de l’espace de travail sont restaurés avec les bons droits et que le terminal démarre sous l’utilisateur prévu.

code-server nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de code-server et conservez le port 8080 sur la route interne. Appliquez correctement le paramètre code-server : placez l’éditeur derrière HTTPS et préservez les upgrades WebSocket. Pour code-server, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent du client qui dépend de l’origine.

Comment tester une mise à niveau de code-server ?

Restaurez l’état actuel de code-server dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car la compatibilité des extensions et les toolchains de l’image de base peuvent changer même lorsque l’interface de code-server démarre toujours. Conservez l’image code-server précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.