Коротко
Кейс от 28.09.2026: платформа «Верный путь» начала пилот по переносу своей инфраструктуры со зарубежных облаков (Vercel, Supabase) на собственное железо — под сервер не покупали ничего, а переоборудовали старый ноутбук с разбитой Windows. Поставили на него Ubuntu и Docker, системный диск расширили с 57 до 115 ГБ без переустановки, старый жёсткий диск на 750 ГБ отдали под данные (687 ГБ свободных) и резервные копии. Это пока не замена прода, а стенд-полигон: проверяем, умеем ли жить на своём железе. Кейс полезен тем, у кого в шкафу пылился ноутбук, и всем, кто задумывается о резервном плане для данных вместо полной зависимости от облаков.
Что получилось: за вечер сервер подняли — SSH из домашней сети, Docker, размеченные диски; дальше по плану копия Supabase и регулярные проверки.
Ключевые грабли: старый BIOS не видит флешки от 32 ГБ; пункт установщика «Use entire disk» чуть не стёр диск с данными; длинные команды, набранные руками, дважды уехали с опечатками — их теперь гоняют файлом через
curl … | sh.Нюанс: почти всю черновую работу сделали ИИ-агенты, человек ставил флажки на опасных развилках — но это стенд, а не прод, и решение по переносу ещё впереди.
У нас есть платформа «Верный путь», и она живёт в облаке: Vercel для сайта, Supabase для базы данных и файлов. Это удобно и до сих пор работало без сбоев. Но у этой схемы есть тихий риск, о котором вспоминают, когда уже поздно: вся инфраструктура стоит на зарубежных сервисах. Доступность, тарифы, правила игры — не наши. Так родилась идея пилота: поднять копию инфраструктуры на своём железе, внутри страны. Покупать для этого сервер мы не стали — в шкафу пылился старый ноутбук с разбитой Windows, и мы решили дать ему вторую жизнь.
Сразу договоримся о честности: это не замена прода. Это стенд — «полигон», где мы проверяем, умеем ли вообще жить на своём железе. Если через пару месяцев пилот покажет, что всё работает, — решим, что делать дальше. А пока вот история, как это было, со всеми граблями.

Шаг первый: старый ноут и флешка
Ноут — обычный, не игровой: SSD на 120 ГБ и второй, старый жёсткий диск на 750 ГБ, на котором раньше стояла Windows. Windows давно сдохла, машина пылилась. Ставим Ubuntu — бесплатную операционную систему, стандарт для серверов. Записываем её образ на флешку, грузимся с неё, идём по установщику. Грабля номер ноль, ещё до установки: старые BIOS не распознают большие флешки (начиная примерно с 32 ГБ) — ноутбук просто не видит загрузочный носитель. Спасает либо маленькая флешка на 8–16 ГБ (Ubuntu туда влезает с запасом), либо запись образа в режиме совместимости со старым BIOS (утилиты вроде Rufus умеют это одной галочкой).
И тут первая ловушка, самая коварная из всех, потому что выглядит как помощь. В установщике есть пункт «Use entire disk» — «использовать весь диск». Звучит как удобное автопилот-решение, но он выбрал не тот диск: целится в большой старый HDD, где мы как раз хотели хранить данные, а не систему. Мы остановились за один шаг до подтверждения и вручную указали SSD. Если бы не остановились — стёрли бы диск, который ещё пригодился бы. Урок, который теперь у нас записан как правило: в установщиках никогда не жать «Done» вслепую — читать, куда именно пишется.

Шаг второй: проблема не техническая, а «руками»
Дальше нужно было настроить вход на сервер с моего рабочего компьютера по SSH — это способ управлять другим компьютером по сети через зашифрованный канал. Вместо пароля — ключ: длинная строка-подпись, которую нужно аккуратно перенести на ноутбук. И тут выяснилось, что главный источник ошибок — не сервер, а человек с клавиатурой: длинную команду дважды набрали с опечатками.
Решение было до смешного простым. Подняли на рабочем компьютере временный локальный веб-сервер, выложили туда скрипт, а на ноутбуке выполнили одну короткую команду: «скачай отсюда и запусти» (в Linux это классическое curl … | sh). Длинное должно ехать файлом — это теперь тоже правило проекта. Клавиатура человека — самое ненадёжное устройство в цепочке.
Шаг третий: диски
Система встала, но оказалось, что штатный раздел под неё отведён впритык — 57 ГБ, для системы и растущего стека мало. Хорошая новость: в Linux (точнее, в технологии LVM — «менеджер логических томов», она позволяет менять размеры разделов «на лету») мы расширили системный диск до 115 ГБ прямо на работающем сервере, без переустановки. Когда-то такая операция требовала переезда и ночи простоя; сейчас — одна команда, сервер даже не выключали.
Старый HDD на 750 ГБ выбросить руки не поднялись — и правильно: затёрли остатки Windows, отдали его под данные, смонтировали как /data (получилось 687 ГБ свободных). Получилась красивая схема: система живёт на быстром маленьком SSD, тяжёлое — на большом медленном диске. Туда же поедут и резервные копии платформы — сейчас они раз в неделю снимаются автоматически, и вторая копия будет лежать уже не только в облаке.
Шаг четвёртый: Docker и что дальше
Чтобы поднять на стенде копию нашей базы и файлового хранилища, мы поставили Docker. Если коротко: Docker — это способ запускать программы в изолированных «контейнерах», как в коробках. Внутри каждой коробки — своя программа со всеми зависимостями, и они не мешают друг другу и не ломают систему. Одна команда поднимает целый стек.

Что уже работает: ноутбук виден в домашней сети по SSH, Docker установлен, диски размечены, образы Supabase докачивались в фоне. Что дальше по плану: поднять саму копию Supabase, залить туда резервную копию с прода, повторить настройку почты — и посмотреть, как это всё ведёт себя в реальной работе несколько дней. Потом — регулярные проверки агентов, те же, что мы прогоняли по API прода.
Зачем вам, эта история
Во-первых, если у вас в шкафу лежит старый ноутбук — это не хлам, а потенциальный домашний сервер для экспериментов, бэкапов или личного сайта. Порог входа сегодня низкий: час на установку Ubuntu и вечер на Docker.
Во-вторых, это наглядный урок про зависимость от чужих сервисов. Облако — хорошо и правильно, но резервный план у данных должен быть. Мы свои копии теперь держим в трёх местах: облако, диск рабочего компьютера и отдельный ноутбук-стенд.
А в-третьих — и это главный слой для нашей платформы — почти всю черновую работу здесь сделали ИИ-агенты: они готовили команды, скрипты, проверки. Человек ставил флажки на опасных развилках (например, «не тот диск») и принимал решения. Это ровно та модель работы, которую мы считаем правильной: не «ИИ вместо человека», а человек, который понимает, что происходит, и поручает машине механику.
Если вы ментор и хотите научиться так же спокойно распоряжаться ИИ-инструментами в своей работе — посмотрите раздел «Менторы»: мы собираем практиков, которые учат не «нейросетям вообще», а осмысленной работе с ними и с собой.



