Смартфон вместо VPS: CMF Phone 1 как Linux-сервер на Termux

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Кейс показывает, что лёгкие веб-сервисы можно перевести с платного VPS на уже купленный ARM-смартфон — ценой root-прав и ручной автоматизации через Ansible и runit.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Сервер, который уже куплен и лежит в ящике

Идея «смартфон вместо VPS» пахнет ютубом. Кейс, который разобрал автор под ником seg6 (перевод kmoseenk, блог OTUS на Хабре), устроен прозаичнее. У человека был CMF Phone 1 без дела и счёт за Hetzner, который раздражал каждый месяц.

Железо: 8 ARM-ядер, 8 ГБ оперативной памяти, 128 ГБ флеш-памяти, Wi-Fi 6, 5G-модем и аккумулятор, который при случае работает встроенным ИБП. Для лёгких веб-сервисов набор сопоставим с бюджетной виртуалкой. Разница в одном: виртуалку надо оплачивать, а телефон уже куплен и пылится.

Долгое время моя личная инфраструктура работала на небольшом VPS от Hetzner. Там крутились несколько веб-приложений, удалённый браузер Surf, Caddy и прочие вспомогательные сервисы.

Причина переезда конкретная. Удалённый браузер Surf с управляемым экземпляром Chrome упирался в ресурсы. Дешёвые виртуалки с общими ядрами держали нагрузку ровно до того момента, когда Chrome начинал делать что-то серьёзное. Виртуалки с выделенными ядрами работали, но платить столько за браузер для личных нужд становилось странно. Покупка отдельного компьютера тоже не выход: память подорожала, б/у мини-ПК — лотерея, а основной ПК занят работой.

Что в итоге собрали

Главное решение: Android остался на месте. Его не выпиливали и не меняли. Логика простая — драйверы Wi-Fi, модема, GPU, управления питанием и аккумулятором уже написаны и работают. Задача была не превратить телефон в Linux-машину, а запускать Linux-приложения поверх.

Хост-окружение — Termux. Внутри OpenSSH, Caddy, пакетный менеджер, привычный набор утилит, runit как супервизор процессов и Tailscale, дающий телефону постоянный приватный адрес в сети. С любого своего устройства автор заходит по ssh cmf и не думает о том, к какой сети телефон подключён сейчас.

Termux при этом не виртуалка. Процессы работают на том же ядре Linux, что и Android, а пользовательское пространство на Bionic отличается от Debian достаточно, чтобы готовые OCI-образы ARM64 не запускались в лоб. Разделение оказалось полезным: Termux остался тонким управляющим слоем, каждое приложение получило свою привычную файловую систему Linux.

Автозапуск после перезагрузки собран в цепочку:

1. Загружается Android.
2. Постоянно активный VPN поднимает Tailscale.
3. Termux:Boot стартует runit.
4. runit поднимает резидентные сервисы.
5. Health checks проверяют доступность локально и снаружи.

Телефон перезагружается без участия человека. Мелочь, но именно она отличает сервер от демонстрации.

Две неудачи, без которых ничего не вышло

Первый заход — поставить на телефон нормальный дистрибутив Linux. Для CMF Phone 1 есть порт postmarketOS, страница устройства пестрит зелёными галочками, и проникнуться оптимизмом легко. Автор проникся и не придал значения пунктам, помеченным как неработающие: Wi-Fi, Bluetooth, аппаратное ускорение и ещё десяток вещей, без которых телефон как сервер бесполезен. Заставка postmarketOS, следом чёрный экран. Ни сервера, ни телефона.

Восстановление штатной Nothing OS стало отдельным квестом. Утилита прошивки требовала Windows, попытка поднять её в QEMU с пробросом USB и драйверами MediaTek упёрлась в зависший прошивальщик, и только на реальной машине заводские образы встали обратно. Вывод очевидный: не надо отбирать у Android работу с железом, которую он делает нормально.

Второй заход — PRoot. Через proot-distro приложения из OCI-образов запустились почти без правок, и это выглядело решением. PRoot перехватывает обращения к файловой системе и процессам в пользовательском пространстве и создаёт процессу Termux иллюзию, что он внутри Debian. Для лёгких демонов схема рабочая. Для браузерной нагрузки — нет.

Пришлось разлочивать загрузчик, получать root и уходить в настоящий chroot с bind-монтированием и отдельным mount namespace.

Просто теперь приложения обращались к ядру Android через нативные системные вызовы (syscall), минуя PRoot. Разница в производительности оказалась огромной!

Развёртывание тоже не оставили на ручную сборку. На рабочем ПК экспортируется файловая система ARM64-образа по дайджесту, Ansible проверяет и устанавливает её на телефон. Повторяемо, без вопроса «а как я это собирал в прошлый раз».

Факт → что это значит

Смотрим на кейс глазами собственника, а не инженера:

• 8 ARM-ядер, 8 ГБ RAM, 128 ГБ. Уровень бюджетного VPS, только железо уже оплачено. SLA при этом нулевой: гарантию даёт производитель телефона, а не хостер.
• Android как хост, Termux сверху. Драйверы, модем, питание и GPU остаются заводскими. Меньше слоёв — меньше поводов получить кирпич.
• Нет systemd и привычного демона Docker. Автозапуск собирается руками: Termux:Boot плюс runit. Каждый сервис описывается отдельно.
• PRoot заменён на chroot с root-правами. Скорость браузерной нагрузки выросла настолько, что схема стала пригодной. Цена — разлоченный загрузчик и ручные обновления прошивки.
• Ansible плюс экспорт образа по дайджесту. Развёртывание повторяемо, но нужен рабочий ПК и ARM64-сборки приложений.
• Tailscale и Caddy. Доступ из любой сети без проброса портов на роутере.
• Аккумулятор вместо ИБП. Короткий сбой питания сервис переживёт. Долгий простой — нет.
• Профиль настроек Android-хоста в Ansible. Wake lock, отключение light и deep idle, снятие ограничений на фоновую работу, запрет спящего режима Wi-Fi. Половина работы по стабильности — это борьба с энергосбережением.

Кому это нужно из бизнеса

Считайте не «можно ли», а «что вы теряете при простое». Внутренняя админка, вебхук-приёмник, парсер, бот для отдела, мониторинг, тестовый стенд, страница статуса. Всё, где нагрузка измеряется единицами запросов в секунду, а час недоступности никому не стоит денег. Такие штуки годами висят на виртуалке за несколько сотен в месяц и жрут бюджет просто по привычке.

Второй сценарий — склад телефонов. После планового апгрейда парка остаются рабочие Android-устройства с приличным железом, которым не находится применения. Пара таких устройств закрывает внутренние мелкие сервисы без новых закупок.

Третий — площадка для проверки гипотез. Развернуть сервис на телефоне, погонять неделю, снять метрики. Если взлетело, переносите на нормальную инфраструктуру с бэкапами. Если нет, вы потеряли вечер, а не бюджет квартала.

Чего здесь точно не стоит делать: клиентский продакшн с обещанием аптайма, приём платежей, персональные данные, всё, где нужен аудит доступа. Root на устройстве, которое стоит в офисе, — отдельная строка риска, и не только техническая.

Где схема ломается

Ограничения лучше проговорить сразу, чтобы не ловить их в момент инцидента.

Автозапуск не бесплатный. В обычном Linux вы ставите unit-файл и забываете. Здесь порядок «Android → VPN → Termux:Boot → runit → сервис» надо собирать и поддерживать. Обновилась прошивка — проверьте, что цепочка жива.

Энергосбережение воюет с вами. Система управления питанием Android делает ровно то, для чего её писали: душит фоновые процессы. Каждое исключение из этого правила — ручная настройка. Забыли пункт — сервис тихо умер к утру.

Одна точка отказа.