WSL или VPS для разработки: что выбрать?

Стоит ли использовать WSL или VPS для разработки?

Выбор между WSL и VPS для разработки сводится к одному свойству: доступности. WSL (Windows Subsystem for Linux) запускает Ubuntu внутри виртуальной машины, которая существует только во время сеанса Windows. VPS (virtual private server) запускает ту же Ubuntu на публичном IP-адресе, который остается активным, даже когда ваш ноутбук закрыт. Большинство разработчиков в итоге используют оба варианта, где сервер выступает в роли постоянно доступной машины.

Операционная система не является существенным различием, так как в обоих случаях это Ubuntu. Разница заключается в аптайме, доступности из интернета, возможностях systemd, скорости работы с файлами, поведении сети и ответственности за резервное копирование. Каждый раздел ниже описывает различия, которые вы можете проверить на собственной машине.

Почему WSL останавливается при закрытии крышки ноутбука?

WSL 2 запускает полноценное ядро Linux внутри легковесной виртуальной машины, которую Windows активирует по требованию. Эта виртуальная машина существует только во время работы дистрибутива, а дистрибутив работает лишь до тех пор, пока его кто-то использует. Проверьте состояние из PowerShell:

wsl --version
wsl --list --running

Закройте все терминалы WSL, подождите минуту, а затем снова выполните wsl --list --running. Когда команда сообщит, что запущенных дистрибутивов нет, это означает, что оболочка, которую вы запустили, завершила работу, как и всё, что в ней выполнялось. wsl --shutdown делает то же самое немедленно; это полезный способ проверить, как ваша конфигурация ведет себя после перезагрузки.

Спящий режим и гибернация также останавливают виртуальную машину. Таймер, настроенный на выгрузку базы данных в 03:00, не сработает, пока крышка ноутбука закрыта, так как ядро, которое должно было выполнить задачу, не работает. Ошибки при этом не логируются, поэтому кажется, что задание вообще не было запланировано. Именно из-за этого поведения пользователи переходят на вторую машину: очередь сборки, чат-бот, ночное резервное копирование или обработчик вебхуков требуют компьютера, который остается включенным.

Работает ли systemd в WSL?

Да. Поддержка появилась в WSL 0.67.6, но в старых установках она отключена по умолчанию. Без неё systemctl status ssh выводит:

System has not been booted with systemd as init system (PID 1). Can't operate.

Сначала прочитайте файл конфигурации, так как он уже может существовать. Если в нём нет секции [boot], добавьте её; если она есть, добавьте единственную строку в уже существующую секцию.

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

Выполните wsl --shutdown в PowerShell, откройте новую оболочку Ubuntu, затем проверьте статус с помощью systemctl list-units --type=service --state=running. Список юнитов означает, что systemd является PID 1, и с этого момента journalctl -b работает корректно.

Нюанс заключается в том, что именно enable гарантирует на каждой машине. На VPS sudo systemctl enable --now caddy означает, что сервис запускается при загрузке системы, поэтому он возобновляет работу после перезагрузки или обновления ядра, даже если никто не вошёл в систему. В WSL это означает, что сервис запускается при старте дистрибутива, а дистрибутив запускается при открытии терминала. Таким образом, сервис работает только пока вы работаете, что противоречит самой цели существования сервисов. Контейнеры наследуют ту же проблему, поэтому автозапуск сервисов Docker Compose зависит от загрузки, которую WSL выполняет только по вашему запросу.

Может ли вебхук обратиться к серверу, запущенному в WSL?

Напрямую нет, и причина кроется в сетевой архитектуре. В режиме по умолчанию WSL 2 помещает виртуальную машину за NAT (трансляцию сетевых адресов) на собственном виртуальном адаптере. Посмотрите на адрес:

ip -4 addr show eth0
ip route show default

Этот адрес является частным и назначается заново при каждом запуске виртуальной машины, поэтому он меняется. Windows по-прежнему может обращаться к localhost:3000, так как WSL перенаправляет соединения с localhost внутрь дистрибутива. Другая машина в вашей сети не сможет этого сделать, если вы не добавите правило проксирования из PowerShell с правами администратора:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

Это правило привязано к конкретному адресу, поэтому оно перестанет работать, как только адрес изменится. Зеркальное сетевое взаимодействие (mirrored networking) — более подходящий вариант: дистрибутив получает те же интерфейсы и адреса, что и Windows. По состоянию на октябрь 2026 года для этого требуется Windows 11 22H2 или новее. Добавьте это в %UserProfile%\.wslconfig и выполните wsl --shutdown:

[wsl2]
networkingMode=mirrored

Зеркальный режим решает проблему локальной сети. Он не предоставляет публичный адрес. Ваш роутер снова использует NAT, большинство домашних подключений не имеют входящих портов, которыми вы управляете, а многие провайдеры добавляют еще один уровень NAT поверх этого. Поэтому GitHub не может отправить POST-запрос с событием на ваш ноутбук, а коллега не может открыть вашу демонстрационную ссылку. Сервис туннелирования позволяет обойти это ограничение, но клиент туннеля работает на ноутбуке, а значит, ноутбук должен оставаться включенным.

VPS решает эту проблему с другой стороны. У него есть публичный IPv4-адрес и обычно публичный IPv6-адрес, открыты только те порты, которые вы разрешили. Укажите на него A-запись, откройте 80 и 443 порты, и он будет отвечать из любой точки. Это также является условием для стандартного получения публичного сертификата, так как проверка HTTP-01 требует, чтобы Let's Encrypt получил файл через 80 порт по публичному доменному имени. Получение сертификата Let's Encrypt с помощью Certbot и nginx на сервере занимает пять минут, а используемый там метод HTTP-01 не работает в WSL без открытого входящего 80 порта. Получение публично доверенного сертификата внутри WSL возможно через проверку DNS-01, которая подтверждает владение доменом с помощью TXT-записи, а не через соединение с вашей машиной, поэтому публичный IP и открытый порт не требуются. Certbot выполняет это с помощью DNS-плагина или --manual --preferred-challenges dns, а руководство по Certbot DNS-01 описывает все шаги. Однако сертификат не делает ноутбук доступным извне; другие люди по-прежнему не смогут открыть сайт. Для локальной работы вы также можете получить HTTPS, которому доверяет браузер, внутри WSL, добавив собственный CA в хранилище доверенных сертификатов Ubuntu.

Почему git работает медленно в /mnt/c?

Файлы находятся не в файловой системе Linux. WSL предоставляет две области хранения с существенно разной производительностью. Ваш домашний каталог расположен в файловой системе ext4 внутри виртуального диска и работает как обычный диск Linux. /mnt/c — это диск Windows, доступ к которому осуществляется по протоколу 9P (протокол файловой системы Plan 9) через компонент на стороне Windows, поэтому каждое открытие файла и каждый вызов stat пересекают эту границу.

Один файл — это нормально. git status в большом репозитории вызывает тысячи обращений stat, и каждое из них требует пересечения границы. Измерьте производительность самостоятельно, вместо того чтобы доверять цифрам из любых источников, включая эту страницу:

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

Запустите каждую команду дважды и сравните результаты вторых запусков, чтобы кэши были прогреты. Антивирусное сканирование в реальном времени в Windows добавляет дополнительные задержки на стороне /mnt/c, поэтому один и тот же репозиторий может работать медленнее на рабочем ноутбуке, чем на личном.

Решение внутри WSL заключается в том, чтобы хранить рабочую копию в ~ и открывать её через режим удаленной работы (remote mode) вашего редактора, который запускает сервер редактора внутри дистрибутива, а не обращается к файлам через границу. Проводник Windows по-прежнему может просматривать эти файлы по пути \\wsl.localhost\Ubuntu\home\you. На VPS этой проблемы нет, так как там используется одна файловая система, и это Linux. Там вы платите задержками сети при редактировании, поэтому пользователи работают в терминальном мультиплексоре или сессии удаленного редактора. Общий процессор — это существенное ограничение на небольшом сервере, и время ожидания из-за соседей по серверу отображается в top в столбце st.

В чем WSL выигрывает безоговорочно

• Это бесплатно и уже есть на компьютере. Включите функцию, установите Ubuntu, и через минуту вы готовы к работе. Никаких затрат и никакой внешней поверхности атаки, которую нужно защищать.
• Это решение проще удалить, чем сервер. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar записывает весь дистрибутив в один файл, а wsl --import восстанавливает его или клонирует под другим именем. Тестирование нового релиза Ubuntu здесь сводится к клонированию и откату, в то время как обновление VPS с 24.04 до 26.04 — это необратимый процесс, который нужно планировать с учетом работающих сервисов.
• Прямая работа с GPU. С актуальным драйвером Windows GPU видеокарта NVIDIA доступна внутри дистрибутива, поэтому рабочие нагрузки CUDA выполняются на оборудовании, которое у вас уже есть. ROCm работает аналогично, но только на картах Radeon из списка поддержки AMD для WSL, поэтому сначала проверьте свою модель там. Аренда GPU такого же класса стоит реальных денег.
• Цикл редактирования короче. Ваши файлы и браузер находятся локально, поэтому сервер разработки на localhost:5173 открывается в браузере, в который вы уже вошли.

Это реальные преимущества, и именно поэтому обычно используют обе машины, а не одну.

Кто владеет резервными копиями?

Вы владеете ими на обеих машинах, и в случае с WSL это часто становится неожиданностью. Дистрибутив представляет собой файл виртуального диска (ext4.vhdx) внутри вашего профиля пользователя Windows. Ни один провайдер не делает его снимки автоматически. wsl --unregister Ubuntu удаляет его без возможности отмены, а переустановка Windows уничтожает его вместе со всем остальным. Выполняйте экспорт по расписанию, которое вы действительно сможете соблюдать:

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

На VPS снимок от провайдера защищает вас от выхода из строя физического сервера. Он не защищает от rm -rf в неверном каталоге, а снимок, хранящийся в той же учетной записи, что и сервер, исчезнет вместе с ним при компрометации одного логина. Выгружайте резервные копии на уровне файлов за пределы сервера и выполняйте восстановление до того, как возникнет реальная необходимость. В обоих случаях ответственность лежит на вас. Практическая разница заключается в том, что сервер может самостоятельно отправить свою резервную копию в 03:00, не требуя, чтобы кто-то оставлял ноутбук включенным.

Мост: SSH из WSL на VPS

Вторая машина кажется обузой только до тех пор, пока соединение не настроено должным образом. Выполните это один раз внутри WSL.

Создайте ключ в дистрибутиве, а не на стороне Windows, чтобы закрытый ключ оставался в файловой системе ext4 с правами доступа Unix, которые принимает ssh:

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ключи Ed25519 коротки и быстры, а ssh-copy-id добавляет открытый ключ в ~/.ssh/authorized_keys на сервере с правильными правами доступа. В основах управления SSH-ключами описаны их ротация и отзыв в будущем.

Дайте серверу имя в ~/.ssh/config:

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

Теперь ssh dev устанавливает соединение. IdentitiesOnly yes запрещает клиенту предлагать все имеющиеся у него ключи, что вызывает Too many authentication failures, если в агенте загружено несколько ключей. ServerAliveInterval 30 предотвращает разрыв сессии при домашнем интернет-соединении без вывода сообщений.

ForwardAgent yes — это строка, которая делает рабочий процесс удобным. Когда ваш ключ загружен в агент на ноутбуке, git clone git@github.com:you/app.git работает на сервере без необходимости копировать туда закрытый ключ. Проверьте это с помощью ssh -T git@github.com на VPS, который должен ответить Hi you! You've successfully authenticated. Перенаправляйте агента только на те серверы, которым вы доверяете, так как пользователь root на этой машине может использовать сокет вашего агента, пока вы подключены. На сервере, который вы делите с другими людьми, более безопасным выбором будет ключ развертывания (deploy key) для конкретного репозитория.

WSL не поддерживает работу агента между сессиями оболочки, поэтому каждый новый терминал снова запрашивает ключ. keychain решает эту проблему:

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

Откройте новую оболочку и выполните ssh-add -l. Она должна вывести отпечаток ключа. Error connecting to agent означает, что строка не считывается, поэтому убедитесь, что ваша оболочка действительно выполняет ~/.bashrc.

Запускайте работу на сервере внутри терминального мультиплексора, чтобы разрыв соединения не прерывал её:

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

Сборка продолжается, даже если вы закроете ноутбук, что и является основной причиной использования второй машины. По этой же схеме люди запускают Claude Code на VPS в tmux и возобновляют сессию с другого устройства.

Укрепите систему перед тем, как размещать на ней что-либо. В руководстве Первые десять минут на новом VPS описаны создание пользователя без прав root, SSH только по ключам, настройка брандмауэра и автоматические обновления безопасности в порядке, который не заблокирует вам доступ.

Какую машину выбрать для какой задачи?

Используйте WSL, когда работа происходит непосредственно на вашем экране. Редактирование кода, запуск наборов тестов, dev-сервер на localhost, ноутбуки, эксперименты с GPU — всё, что вы запускаете и за чем наблюдаете в процессе.

Используйте VPS, когда работа должна быть доступна извне или должна продолжаться после завершения вашего сеанса. Это может быть staging-URL, который может открыть клиент, endpoint для вебхуков, cron-задача с реальным системным временем, бот, небольшая база данных, к которой обращается другой сервис, или процесс импорта, запущенный в пятницу вечером.

Если вы всё ещё решаете, для чего нужна вторая машина, список того, что люди реально запускают на VPS будет полезнее, чем сравнение технических характеристик, а статья о том, что такое VPS объясняет принципы виртуализации, лежащие в её основе. Если ваш инструментарий работает только на Windows, это отдельный вопрос, и для него предназначена страница сравнение Linux и Windows Server.

Одна привычка поможет избежать ситуации, когда у вас оказываются две наполовину настроенные машины: код должен храниться в git, а обе машины должны быть клиентами репозитория. Ничего важного не должно существовать только на одной из них.

FAQ

Могу ли я разместить сайт с реальным доменом на WSL?

Ненадежно. WSL 2 находится за NAT внутри вашего компьютера, ваш роутер также использует NAT, а большинство домашних интернет-провайдеров не предоставляют входящих портов для проброса. Сервис-туннель может открыть локальный порт, но клиент туннеля работает на ноутбуке, поэтому сайт будет недоступен, когда ноутбук переходит в спящий режим. Сертификаты усложняют задачу, так как проверка HTTP-01 требует, чтобы Let's Encrypt получил файл через 80 порт по публичному имени. Проверка DNS-01 позволяет выпустить сертификат без входящего соединения, но это не решает проблему доступности. VPS с публичным IP-адресом и A-записью удовлетворяет обоим условиям без дополнительных обходных путей.

Работает ли systemctl enable в WSL?

Он работает, если включен systemd, что означает systemd=true в секции [boot] файла /etc/wsl.conf с последующим wsl --shutdown. Без этого systemctl отвечает System has not been booted with systemd as init system (PID 1). Can't operate.. Даже при запущенном systemd команда enable запускает сервис при старте дистрибутива, а дистрибутив запускается при открытии оболочки. На сервере та же команда означает, что сервис возобновит работу после перезагрузки без необходимости входа пользователя в систему.

Почему мой IP-адрес в WSL постоянно меняется?

В режиме NAT по умолчанию виртуальная машина получает новый частный адрес от виртуального адаптера WSL при каждом запуске. Любое правило netsh interface portproxy или жестко заданный адрес перестают работать после wsl --shutdown. Проверьте текущий адрес с помощью ip -4 addr show eth0. Режим зеркалирования сети в Windows 11 устраняет отдельный адрес, предоставляя дистрибутиву те же интерфейсы, что и у Windows: установите networkingMode=mirrored в секции [wsl2] файла %UserProfile%\.wslconfig.

Действительно ли /mnt/c работает медленнее или это миф?

Это медленнее, и минута тестирования докажет это на вашем компьютере. Файлы в ~ находятся на виртуальном диске ext4. Файлы в /mnt/c передаются по протоколу 9P компонентом на стороне Windows, поэтому каждый вызов stat пересекает границу, а git status по большому дереву каталогов совершает их тысячи. Скопируйте репозиторий в ~, выполните time git status дважды в каждом расположении и сравните результаты повторных запусков. Храните рабочие копии в ~ и используйте режим WSL remote в вашем редакторе.

Нужен ли мне WSL, если у меня есть VPS?

Большинство людей используют и то, и другое. WSL бесплатен и запускается мгновенно, поэтому он остается местом для редактирования и тестирования, там же удобнее работать с GPU. Сервер — это машина, которая работает постоянно: она имеет публичное имя и выполняет задачи, которые должны продолжаться при закрытом ноутбуке. Храните код в git и используйте оба окружения как клиенты репозитория, тогда перенос работы между ними не потребует усилий.