code-server в браузере: что перестаёт работать без локальной машины

MAATRIX

code-server открывает VS Code в любом браузере — редактор выглядит и в основном ведёт себя точно так же, как на ноутбуке, только код, терминал и расширения живут на сервере. Идея заманчивая: слабый клиент, тяжёлая работа на удалённой машине, доступ с любого устройства. Но «в основном так же» — не «точно так же»: часть возможностей локальной разработки завязана на физическое железо под рукой, и без него они просто отваливаются, иногда без внятного сообщения об ошибке. Разберём, что в code-server работает честно, а что стоит проверить до того, как вы перенесёте на него единственную рабочую среду.

Что такое code-server и как он устроен

code-server — это open-source сборка Code-OSS (открытый код VS Code без части проприетарных компонентов Microsoft), запакованная в веб-сервер. На стороне сервера крутится процесс, который держит файловую систему проекта, интегрированный терминал, языковые серверы и расширения; в браузере рисуется интерфейс через веб-сокет, визуально почти неотличимый от десктопного VS Code. Разработчик — Coder (компания, а не одноимённый отдельный продукт для командных рабочих сред), проект живёт на GitHub и обновляется вслед за апстримом Code-OSS.

Ключевое отличие от привычного VS Code с расширением Remote-SSH: там редактор остаётся локальным приложением, а на сервер тянется только бэкенд для конкретного проекта. В code-server наоборот — сам интерфейс отрисовывается в браузере, локально не установлено вообще ничего, кроме браузера. Отсюда и вся разница в возможностях: браузер — куда более узкая песочница, чем нативное приложение с прямым доступом к операционной системе.

Здесь же стоит сразу развести два похожих по звучанию, но разных по масштабу инструмента. code-server — это один редактор на одном сервере: просто, быстро разворачивается, минимум движущихся частей. Coder (платформа с тем же названием, что и компания-разработчик code-server) — это оркестрация десятков изолированных рабочих сред для команды: шаблоны окружений, автоматическое пересоздание, биллинг по простою, интеграция с Kubernetes или облаком. Если нужен один персональный «ноутбук в браузере» — берите code-server. Если нужно раздать одинаковые воспроизводимые окружения десяти разработчикам с контролем доступа — это уже совсем другой уровень инфраструктуры, и обычным docker-compose здесь не обойтись.

Установка: минимальный рабочий стенд

Проще всего поднять code-server в Docker — так проще обновлять и не тащить зависимости в систему. Базовый docker-compose.yml:

services:
  code-server:
    image: codercom/code-server:latest
    container_name: code-server
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
      - PASSWORD=${CODE_SERVER_PASSWORD}
    volumes:
      - ./config:/home/coder/.config
      - ./project:/home/coder/project
    ports:
      - "127.0.0.1:8080:8080"
    restart: unless-stopped

Обратите внимание на 127.0.0.1:8080:8080 — порт сознательно не публикуется наружу, только на loopback хоста. Наружу его отдаёт nginx как reverse proxy с TLS, это подробно разобрано в статье про nginx как reverse proxy на VPS. Пароль лучше не хранить в переменной окружения в открытом виде — code-server поддерживает HASHED_PASSWORD (SHA-256 хеш), это не даёт паролю светиться в docker inspect и логах.

После первого запуска конфиг сохраняется в ~/.config/code-server/config.yaml:

bind-addr: 0.0.0.0:8080
auth: password
password: ваш-пароль-или-хеш
cert: false

Если сервер стоит за VPN или доступен только через SSH-туннель, cert: false — нормально, TLS в этом случае терминируется либо на самом туннеле, либо на reverse proxy перед code-server. Пробрасывать порт напрямую в интернет без прокси и без ограничения по IP не стоит — веб-интерфейс редактора с доступом к файловой системе и терминалу сервера это ровно та цель, которую боты сканируют в первую очередь.

Что действительно работает как в десктопном VS Code

Здесь хорошая новость: базовый рабочий цикл разработчика воспроизводится почти один в один. Редактирование, подсветка синтаксиса, автодополнение, go-to-definition через языковые серверы (TypeScript, Python, Go, Rust и другие) — всё это выполняется на сервере, и задержка обычно ограничивается только сетью между вами и сервером, а не мощностью локальной машины. На сервере с нормальным CPU и SSD индексация крупного монорепозитория часто идёт быстрее, чем на среднем ноутбуке, — особенно если ноутбук уже был не самым свежим.

Встроенный терминал — полноценный шелл на сервере, с тем же bash/zsh, что был бы при SSH-подключении. Git интегрирован через встроенное расширение и работает штатно: коммиты, диффы, staging по кускам, история. Debugger для большинства языков (Node.js, Python, Go) подключается через стандартный протокол отладки и разворачивается прямо на сервере — не нужно ничего пробрасывать локально.

Что особенно ценно для нестабильного интернета или частых переключений между устройствами: сессия редактора живёт на сервере независимо от браузерной вкладки. Закрыли ноутбук в кафе, открыли планшет дома — вкладка терминала с фоновым процессом (например, npm run dev или долгий тест) продолжает работать, как будто вы просто отключились от tmux-сессии, а не выключили компьютер: сам принцип «сессия не умирает вместе с соединением» тот же, просто здесь его дал браузерный интерфейс, а не отдельный мультиплексор терминала.

Расширения из marketplace тоже ставятся и работают — с важной оговоркой, которая разбирается ниже.

Периферия: то, что физически не долетает до сервера

Вот где начинается честная часть статьи. Браузер — песочница на вашем локальном устройстве, а редактор работает на удалённом сервере; между ними — только веб-сокет с текстом, курсором и содержимым файлов. Отсюда простое правило: если возможность требует прямого доступа к устройству, подключённому к ноутбуку, а не к серверу, — она не работает, и обходных путей немного.

Конкретные примеры, которые ломаются регулярно:

• USB-устройства для встраиваемой разработки. Расширения вроде PlatformIO IDE или Arduino ждут serial-порт (/dev/ttyUSB0, /dev/ttyACM0) — а физический USB-кабель воткнут в ваш ноутбук, а не в сервер за тысячи километров. Прошить плату через code-server напрямую нельзя: сервер просто не видит устройство, которого физически рядом с ним нет.
• Отладка мобильных приложений по USB. adb для Android или Xcode-инструменты для iOS ожидают устройство, подключённое кабелем к машине, где выполняется отладка. Через code-server теоретически можно поднять adb по Wi-Fi (adb tcpip), но это отдельная настройка с известными проблемами стабильности, а не то, что «просто работает из коробки».
• Веб-камера и микрофон для локальных расширений. Сам браузер может запросить доступ к камере (например, для видеозвонка в отдельной вкладке), но расширения VS Code, которым для работы нужен прямой доступ к устройствам через ОС (а не через браузерный API), эти устройства не увидят — они выполняются в контексте сервера.
• Смарт-карты и аппаратные токены для подписи коммитов. Если у вас YubiKey для GPG-подписи коммитов, он физически должен быть доступен там, где выполняется git commit — то есть на сервере, а не у вас на столе. Прокидывать USB-токен по сети в общем случае не стоит по соображениям безопасности.
• Печать и локальные принтеры. Экспорт в PDF из браузера работает, а вот отправить что-то на локальный принтер напрямую из терминала на сервере — нет, принтер просто не в его сетевом окружении.

Есть смежная тема — проброс периферии не в браузер, а в виртуальную машину или контейнер, если сервер у вас свой и вы управляете гипервизором. Это другой сценарий (вы физически рядом с сервером или с его консолью), и он подробно разобран в статье про проброс диска и USB в виртуалку — но к типичному облачному VPS с code-server это почти никогда не относится: устройство физически привязано к вашему рабочему месту, а не к дата-центру.

Расширения: что ставится честно, а что упирается в лицензию и архитектуру

Здесь есть менее очевидная, но важная граница — не физическая, а лицензионная. code-server по умолчанию использует Open VSX Registry, а не официальный Visual Studio Marketplace от Microsoft: лицензия Microsoft Marketplace прямо запрещает использовать его вне официальных сборок VS Code, и в Coder не могут (и не должны) это обходить. На практике это означает: большинство популярных open-source расширений (Python, ESLint, Prettier, GitLens и десятки других) в Open VSX есть и работают штатно, но у части проприетарных расширений Microsoft — в первую очередь C/C++ от Microsoft и некоторые их дебаггеры — либо нет версии в Open VSX, либо стоит юридическое ограничение на использование вне VS Code. Если ваш стек завязан на конкретное такое расширение — стоит проверить его наличие в Open VSX до переезда, а не после.

Отдельная категория — расширения с нативными зависимостями, компилируемыми под конкретную архитектуру и ОС. Некоторые языковые серверы и линтеры при установке скачивают или собирают нативный бинарник под платформу, на которой выполняются. Поскольку в code-server расширение реально выполняется на сервере (обычно linux/amd64 или linux/arm64), а не на вашем Mac или Windows-ноутбуке, иногда всплывают расхождения: расширение, годами стабильно работавшее локально на macOS, на Linux-сервере ведёт себя иначе или требует системных пакетов, которых нет в минимальном образе контейнера. Это не проблема самого code-server — та же история случилась бы при обычной разработке внутри Linux-контейнера, просто на локальной машине с GUI это обычно менее заметно.

Расширения для совместной работы вроде Live Share в целом функционируют, но их UX рассчитан на десктопный VS Code с нативными уведомлениями и интеграцией в ОС — в браузерной версии часть удобств (быстрые системные пуш-уведомления, глубокая интеграция с другими локальными приложениями) заметно беднее.

GPU-задачи: инференс и обучение моделей

Это самое частое ожидание, которое code-server не оправдывает без дополнительной настройки. Сам code-server — это просто веб-интерфейс редактора, у него нет собственного доступа к GPU. Если контейнер, в котором он запущен, не настроен с проброшенным GPU (через nvidia-container-toolkit и соответствующие флаги в docker-compose.yml), то любой процесс в интегрированном терминале — хоть Python-скрипт с PyTorch, хоть nvidia-smi — просто не увидит видеокарту, даже если физически на сервере она стоит.

Минимальная правка docker-compose.yml для проброса GPU в контейнер code-server:

services:
  code-server:
    image: codercom/code-server:latest
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    # остальные параметры как в базовом конфиге выше

Но проброс GPU в контейнер — это только половина дела: сам сервер должен физически иметь видеокарту, и не любую, а такую, у которой хватает видеопамяти под вашу модель. Развернуть code-server на дешёвом VPS без GPU и ждать, что обучение или инференс модели «просто заработает быстрее, чем на ноутбуке», — типичная ошибка ожиданий: без GPU на сервере вычисления пойдут на CPU сервера, что для многих ML-задач медленнее, чем локальная видеокарта среднего уровня. Если задача реально требует GPU, разумнее сразу смотреть в сторону сервера, спроектированного под это — например, сервера с GPU под обучение моделей, а code-server поверх такого сервера использовать просто как удобный интерфейс к уже правильно настроенному железу, а не как замену выбору сервера.

Безопасность: доступ только через туннель, не напрямую

code-server отдаёт в браузер полноценный терминал с правами того пользователя, под которым запущен процесс, — по сути, это удалённый шелл с графической обёрткой. Защищать его нужно строже, чем обычное веб-приложение.

Практический минимум:

• Не публиковать порт code-server напрямую в интернет — только через nginx с TLS и, желательно, дополнительной Basic Auth поверх встроенной авторизации code-server (двойной периметр не помешает).
• Использовать HASHED_PASSWORD вместо PASSWORD в открытом виде, чтобы пароль не светился в переменных окружения контейнера.
• Ограничить доступ по IP через firewall или, ещё надёжнее, держать code-server доступным только через SSH-туннель (ssh -L 8080:localhost:8080 user@server) или через VPN — тогда веб-интерфейс вообще не виден из публичного интернета, и даже угаданный пароль ничего не даёт без доступа к сети.
• Регулярно обновлять образ — code-server следует за апстримом Code-OSS, и в компонентах редактора время от времени закрывают уязвимости, как и в любом активно разрабатываемом ПО.

Отдельно стоит помнить: если вы работаете под пользователем с правами sudo или root внутри контейнера, любой, кто получил доступ к веб-интерфейсу, получил и терминал с этими правами. Изоляция на уровне контейнера — это гигиенический минимум, а не полноценная защита периметра.

Частые вопросы