Попытка запустить сразу несколько веб-сервисов на рабочем компьютере часто превращается в перекличку портов: нужно помнить, что фронтенд слушает порт 3000, бэкенд занял 8080, а аналитика переместилась на 5173. Браузер ругается на небезопасный HTTP-канал, cookie сбрасываются из-за несовпадения доменов, а мобильные устройства в той же Wi-Fi сети не могут открыть проект без ручной правки сетевых шлюзов.
Экспериментальная команда Vercel Labs предложила инструмент Portless, который избавляет разработчика от запоминания числовых портов. Утилита перехватывает запуск dev-серверов и выдает каждому проекту персональный постоянный адрес вида https://myapp.localhost с автоматическим локальным TLS-шифрованием и поддержкой протокола HTTP/2.
Доменная спецификация стандарта RFC 6761
Вместо сложной ручной правки системного файла /etc/hosts Portless опирается на стандарт RFC 6761. Комитет IANA зарезервировал доменную зону верхнего уровня .localhost как гарантированно локальную. Любая операционная система и все браузеры по умолчанию замыкают запросы к .localhost на внутренний петлевой интерфейс (127.0.0.1 и ::1), никогда не отправляя DNS-запросы во внешнюю сеть.
Portless слушает стандартные порты 80 (HTTP) и 443 (HTTPS) в роли фонового диспетчера. При запуске проекта утилита выделяет процессу свободный эфемерный порт (из пула 4000–4999), передает его фреймворку через переменную PORT или CLI-аргументы (--port, --host для Vite, Astro и Expo) и регистрирует имя хоста. Обращение по адресу https://myapp.localhost моментально маршрутизируется на нужный внутренний порт.
Зеленый замок без предупреждений безопасности
Браузеры блокируют современные веб-возможности (сервисные воркеры, Web Crypto, буфер обмена), если соединение не защищено доверенным сертификатом. Portless решает проблему на уровне операционной системы: при первом старте создается локальный удостоверяющий центр (Local Root CA) и регистрируется в хранилище системы через portless trust. Поддерживаются update-ca-certificates в Linux, Keychain в macOS и certutil в Windows и WSL2.
Трафик проксируется по протоколу HTTP/2, что снимает браузерное ограничение на 6 параллельных TCP-соединений — ключевое преимущество для сборщиков на базе ESM-модулей. Для горячей перезагрузки модулей (HMR) встроена поддержка WebSockets поверх HTTP/2 по спецификации RFC 8441 Extended CONNECT.
Сквозной сценарий: от манифеста к изолированным веткам
Подключение утилиты не требует изменения бизнес-логики. Достаточно зафиксировать сервис в манифесте package.json:
{
"name": "@company/web",
"scripts": {
"dev": "portless",
"dev:app": "next dev"
},
"portless": {
"name": "myapp",
"script": "dev:app"
}
}
Дальнейшее управление проектом и изолированными рабочими деревьями Git Worktree выполняется через CLI:
# Стандартный запуск dev-сервера под персональным именем
portless myapp next dev
# Сервис доступен по адресу: https://myapp.localhost
# Запуск в изолированном дереве git worktree для ветки fix-ui
portless run next dev
# Автоматический субдомен: https://fix-ui.myapp.localhost
# Привязка статического сервиса или контейнера
portless alias db-admin 8080
# Доступ к интерфейсу: https://db-admin.localhost
Флаг --lan включает трансляцию mDNS (<name>.local) для мобильных проверок в Wi-Fi сети, а флаги --tailscale и --ngrok создают безопасный туннель для демонстрации клиентам.
Границы применения и инженерный вердикт
Portless идеально подходит для монорепозиториев (поддерживает pnpm-workspace.yaml и Turborepo) и микросервисов. Однако инструмент избыточен для проектов, чья сетевая топология уже инкапсулирована в Docker Compose или Kubernetes. На Unix-системах первичный биндинг к порту 443 требует прав суперпользователя (хотя предусмотрен запуск на непривилегированном порту). Для фронтенд-команд утилита снимает ежедневное трение, делая локальное окружение неотличимым от боевого домена.